Plan workload movement separately from scale-set zone expansion

Source facts

Adding zones to a scale set does not migrate its original instances or data. New instances created during scale-out use the expanded zone selection, and subsequent scale-in removes regional instances first. Added zones cannot later be removed or replaced. Expansion requires API 2023-03-01 or later and fault-domain count 1 or 5; capacity reservations during expansion, Dedicated Host deployments, Service Fabric RP, and AKS scale sets are excluded. Microsoft Learn.

Applicability

Review the source’s full eligibility and zone-availability checks before planning this transition. Identify which existing instances hold state and how the application will transfer or replicate it to new instances.

DSE recommendation

Create a workload-transition plan in addition to the scale set’s zone-property change. Have the workload owner define when a new zonal instance is ready to serve and when an original instance can be retired. Coordinate capacity increases, data movement, and removals explicitly. Do not describe the property update as an in-place migration or promise to reverse it by removing a zone.

Verification

Inspect instance locations before and after an authorized staged expansion. Verify that intended new instances are serving the correct data before approving scale-in, and check which original instances remain. Preserve the instance-to-zone inventory with application results. If the control-plane update succeeds but the workload has not moved, report the transition as incomplete and leave the original service path protected.

Official references

Microsoft Learn: Customer-selected availability zones for Virtual Machine Scale Sets. Source reviewed September 9, 2026.