Public Preview: Migrate your regional virtual machines to availability zones

This new capability enables you to move your existing regional (nonzonal) VMs and VMSS Flex deployments into specific availability zones while preserving the VM names, data disks, and other stateful properties.

We're excited to announce the public preview of regional to zonal migration for Azure Virtual Machines and for VMs in Virtual Machine Scale Sets with Flexible orchestration. With a small number of API calls, you can take a VM that was originally deployed without a zone and assign it to availability zone 1, 2, or 3—keeping the same VM resource ID, name, OS and data disks, NICs, IP addresses, and scale set membership.

For detailed instructions, see:

• Migrate a regional virtual machine to an availability zone
• Migrate from regional to a zonal Virtual Machine Scale Sets

Why migrate from regional to zonal?

Availability zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking. Placing your VMs into zones gives you a meaningfully higher availability profile and protects you from datacenter-level failures.

Until now, moving an existing regional VM into a zone meant rebuilding the VM: snapshot the disks, recreate the resource in the target zone, reattach NICs, update DNS, and so on. With this preview you can do it while preserving the resource IDs and all its dependencies.

How it works

The migration is a deliberate, in-place flow that you control end-to-end:

1. Register the preview feature Microsoft.Compute/RegionalToZonalVMMigrationForDeallocatedVM on your subscription.
2. Deallocate the VM. The VM must be in Stopped (deallocated) state—plan for downtime.
3. Assign the zone. Update the VM's zones property to ["1"], ["2"], or ["3"].
4. Start the VM. It boots in the new zone immediately, even while background data migration of the disks is still completing.
5. (Optional) Attach to a Flexible scale set for autoscaling, rolling upgrades, and instance protection.

A few important properties of the flow:

• In place. The VM keeps its resource ID, name, NICs, private/public IPs, OS and data disks, tags, and extensions.
• Background data movement. Disk data is migrated transparently after the zone is assigned. You don't have to wait for it before starting the VM.
• One-way. A zonal VM can't be migrated back to a regional deployment.
• Per-VM granularity. For scale sets, you migrate one VM at a time so you can stagger the change across instances and validate between batches.

Two migration paths

Path 1: Single regional VM → zonal VM

For standalone VMs (or VMs you want to leave standalone). Once the VM is zonal, you can optionally attach it to a Flexible scale set in the same region.

# 1. Deallocate
 az vm deallocate -g <rg> -n <vm>

# 2. Assign zone az vm update -g <rg> -n <vm> --set zones='["1"]' 

# 3. Start 
az vm start -g <rg> -n <vm>

If the VM is in a Proximity Placement Group, remove the PPG association in the same update by adding --ppg "".

Path 2: Regional VMSS Flex → zonal VMSS Flex

For VMs running in a Flexible scale set, you first update the scale set model to include the target zones, then migrate each VM in place. VMs keep their names, disks, network configuration, and scale set membership.

# 1. Add zones to the scale set model (no impact on running VMs) 
az vmss update -g <rg> -n <vmss> --set zones='["1","2","3"]' 

# 2. For each VM in the scale set: 
az vm deallocate -g <rg> -n <vm-instance> 
az vm update -g <rg> -n <vm-instance> --set zones='["1"]' 
az vm start -g <rg> -n <vm-instance>

We recommend migrating in batches—for example, a third of the instances at a time—so the application stays healthy throughout the migration window. Spreading the instances across all three zones.

Supported configurations

Not supported in this preview

You'll need to address these before migrating:

• Basic SKU public IP addresses — upgrade to Standard SKU.
• Basic SKU Load Balancer — upgrade to Standard Load Balancer.
• Unmanaged disks — convert to managed disks.

The target zone must also support the VM's current size. You can check with:

az vm list-skus --location <region> --zone --resource-type virtualMachines -o table

How to get started

1. Register the preview feature on your subscription: az feature register --namespace Microsoft.Compute \ --name RegionalToZonalVMMigrationForDeallocatedVM. 
2. Pick a non-production VM or scale set first. Walk through deallocate → assign zone → start, and confirm the VM comes up healthy in the new zone.
3. Plan your zone strategy. For multi-VM workloads, distribute instances across zones 1, 2, and 3 so a single zone failure minimally impacts your workload.
4. Roll out in batches for production scale sets, validating application health between batches.