5.5 Move VMs Across Resource Groups, Subscriptions, and Regions

What Moving Means

Azure uses the word move in more than one way. Moving a VM to another resource group or subscription is a control plane operation when the source and target are in the same tenant and the resource types support the move. Moving a VM to another region is not the same operation. Region migration requires replication, redeployment, restore, image copy, or a service such as Azure Resource Mover or Azure Site Recovery.

A VM is a dependency graph. The VM resource references NICs. NICs reference subnets, NSGs, public IPs, application security groups, and load balancer backend pools. The VM also references managed disks, availability sets or zones, extensions, identities, backup protection, and diagnostic settings. A move plan must include the resources that cannot be separated.

Same-Region Resource Moves

The portal path is Resource group > Move > Move to another resource group or Move to another subscription. Azure validates the selected resources. You should move the VM and dependent resources together unless the dependency is intentionally staying behind and supports that relationship. A common mistake is selecting only the VM and not the NIC or disks.

CLI example:

vmId=$(az vm show -g rg-old-compute -n vm-app-01 --query id -o tsv)
nicId=$(az network nic show -g rg-old-compute -n vm-app-01-nic --query id -o tsv)
osDiskId=$(az vm show -g rg-old-compute -n vm-app-01 --query storageProfile.osDisk.managedDisk.id -o tsv)

az resource move \
  --destination-group rg-new-compute \
  --ids $vmId $nicId $osDiskId

In practice, collect all IDs including data disks, public IP, NSG if in the same resource group and tied to the design, load balancer pieces if required, and availability set if used. Some associated resources may not be movable or may need to be detached first. Always use validation and read the error details.

Pre-Move Checklist

Moving resources changes resource IDs when the resource group or subscription changes. Anything that stores the old resource ID, such as scripts, dashboards, alert scopes, role assignments, backup items, or external CMDB records, may need updates. DNS names and public IP addresses may or may not remain depending on what moves and what is recreated.

Subscription Moves

A subscription move can be blocked by policies, locks, marketplace plan terms, unsupported resource types, or missing providers. If the VM uses a marketplace image with plan information, ensure the target subscription can accept the plan. If the VM has managed identities, role assignments may need to be recreated at the new scope. If the VM is protected by backup, check support and whether protection must be stopped and reconfigured.

CLI can move resources to another subscription by using the destination group ID:

targetGroupId=$(az group show --subscription SUBSCRIPTION-B --name rg-prod-compute --query id -o tsv)
az resource move --destination-group $targetGroupId --ids $vmId $nicId $osDiskId

You must be operating with permissions in both subscriptions. The source and destination subscriptions must meet Azure move requirements. Do not assume every resource supports every move.

Region Moves

You cannot simply edit a VM location from East US to West US. For regional moves, choose the method based on downtime, data consistency, and repeatability requirements.

Azure Resource Mover can assess dependencies, prepare resources, initiate move, and commit or discard staged resources for supported scenarios. Azure Site Recovery replicates VMs to a recovery region and can be used for migration-like failover, but networking, IP addressing, DNS, and testing still require planning.

Troubleshooting Scenarios

Scenario 1: Move validation fails because a dependent resource is missing. Re-run dependency discovery. Include the NIC, OS disk, data disks, public IP, availability set, and related network resources that must move. If a dependency is intentionally shared, verify Azure supports leaving it in the source scope.

Scenario 2: The target subscription denies the move with policy. Check allowed locations, required tags, public IP restrictions, allowed VM SKUs, disk encryption requirements, and naming policies. Fix the resource configuration or use an approved target scope.

Scenario 3: A VM works after a resource group move but alerts no longer fire. Check alert rule scopes, action groups, diagnostic settings, workbooks, automation scripts, and backup reports. The resource ID may have changed, and monitoring configuration may still point to the old scope.

Scenario 4: A regional migration completes but users still connect to the old VM. Update DNS records, Traffic Manager or Front Door endpoints if used, firewall rules, private DNS zones, route tables, and application configuration. Migration does not automatically update every external reference.

Exam Decision Logic

If the question says move to another resource group in the same subscription, select Move or az resource move and include dependencies. If it says move to another subscription, also check permissions, provider support, policy, marketplace terms, and quota. If it says move to another region, reject the idea of changing the location property and choose Resource Mover, Site Recovery, backup restore, snapshots, images, or redeployment. If the VM is stateless and built from Bicep, redeployment may be simpler than a resource move.