Moving an Azure virtual machine

What it is

“Moving a VM” refers to relocating an existing Azure VM — either to a different resource group / subscription within the same region, or to a different region / availability target — and to changing its size (resizing). The technique you use depends on where you’re going and what you can keep.

Why it exists

Workloads change: orgs restructure subscriptions/resource groups, want to consolidate billing, move disaster-recovery (DR) targets, or scale a VM up/down — all without rebuilding from scratch where possible.

Key ideas

1. Move within the same region (“ARM move”)

  • Use the Resource Manager move operation to place a VM (and its resources) into another resource group or subscription in the same region.
  • Properties are preserved (IDs, IPs in place, attached managed disks move along with the VM). A move to a different RG changes the resource IDs, so scripts/references that hard-code IDs break.
  • Constraints: target RG/subscription must exist and be compatible; the VM must be stopped/powered off (deallocated) or you must handle the move of managed resources (NIC, managed disk) first — many managed resources (OS disk, NIC) are moved automatically.
  • Moving a subscription requires it to already be in a state that supports move (moved from a different/other management hierarchy correctly, no conflicting endpoint locks), and the target subscription must be in the same Azure AD (Entra ID) tenant.

2. Move across regions (“Azure Resource Mover”)

  • This is a different, purpose-built service: Azure Resource Mover orchestrates moving VMs, disks, NICs, and dependent resources from one region to another (or between availability zones).
  • It copies resources to the target region, verifies, and lets you commit the move (deleting source) or abandon it. It handles dependencies (disks, NICs, IPs, VNETs) for you.
  • Useful for DR, consolidation into one region, or moving workloads to a geographically better location.

3. Resizing a VM

  • Change the VM to a larger or smaller size (e.g. Standard_D2s → D4s_v3).
  • Resize triggers a VM restart; the desired size must fit the available capacity in the VM’s current region/availability set — if capacity is short, stop/deallocate the VM, resize, then restart.
  • If the VM is in an availability set, all VMs in the set must be the same size family, so you may need to resize the whole set. (Some VMs in an availability set can resize freely; verify current limits — the exam’s focus is that resizing may require a restart.)

Exam notes

  • Same region → different RG/subscription = arm/move-resource-group-and-subscription operation; across regions = Azure Resource Mover.
  • Moving changes resource IDs — update references.
  • Deallocate the VM before moving/consolidating where required.
  • Resizing needs restart and must fit regional + availability-set capacity; an availability set forces a common size family.

azure-vm · resource-group · subscription · vm-move · availability-set · managed-disks

📘 Source: Microsoft Learn — Move resources to a new resource group or subscription