When the destination is a different virtual network, Azure VM relocation has one documented path. The Virtual Network overview states: to move a virtual machine from one virtual network to another, you must delete and recreate the virtual machine in the new virtual network. The virtual machine’s disks can be retained for use in the new virtual machine (Azure Virtual Network overview). That sentence is the whole platform contract for VNet-to-VNet moves; everything else the operator needs to reason about is inference.
What the documentation explicitly guarantees
The Virtual Network overview describes Azure Virtual Network as the fundamental building block for your private network in Azure, delivering the scale, availability, and isolation benefits of Azure infrastructure while keeping the familiar networking concepts used in traditional datacenters (Azure Virtual Network overview). Resources listed as deployable inside a virtual network include virtual machines, App Service Environments, Azure Kubernetes Service, and Virtual Machine Scale Sets.
The move constraint and the disk-retention exception are the only guarantees the documentation makes. The silence on every other detail is itself an operational signal: if something is not the disk, the documented path is to rebuild it.
What the default VM set actually contains
The VM overview lists the default resources the platform provisions alongside a new VM: a virtual network, a NIC, a private IP address and possibly a public IP, an NSG, an OS disk, and in some cases a license for the OS. The same source notes that all new virtual machines have an operating system disk and a local disk (Azure VMs overview). A separate data disk is described as a best practice for separating data from the operating system, not as part of the default set.
Managed disks are stored as page blobs, which the Storage introduction describes as a random IO storage object in Azure; Azure treats a managed disk as an abstraction over page blobs, blob containers, and Azure storage accounts (Azure Storage introduction). That abstraction is what lets the disk layer outlive the VM object: the disk is a storage primitive with its own identity.
Inferences an engineer must reason about (design judgments)
The items below are design judgments inferred from the move constraint and from how the default resources are described. They are not separately documented guarantees.
- Because the VM is deleted, identities attached to that VM object must be re-established on the new VM before dependent services will accept its tokens.
- Because the NIC does not survive, any private IP allocation, any public IP, and any NSG associations are part of the deleted object and must be rebuilt for the new VM.
- Because Azure Hybrid Benefit license cost is described as tied to the VM’s cores, the new VM inherits a fresh license posture rather than carrying the old one forward.
- Because data disks are a separate best-practice artifact rather than part of the default set, they are the documented survival path for application state.
Planning shape, not a vendor procedure
The following sequence is a hypothetical planning shape, not a vendor-validated procedure:
- Inventory state outside the VM object: NSG rules, route tables, private endpoints, custom DNS, certificate bindings, and any IP allow-lists tied to the current addresses.
- Decide whether retained data disks are sufficient, or whether a fresh image with a known baseline is the safer path.
- Decide whether the new VM reuses the same managed identity, a new system-assigned identity, or a different user-assigned identity.
- Validate the recreated VM’s network reachability, identity, and extension state before decommissioning the source.
Topology discipline that reduces the need to move
The cleanest answer to a VNet-move problem is to avoid needing one. The VNet itself carries no charge: there’s no charge for using Azure Virtual Network, and standard charges apply only to the resources placed inside it (Azure Virtual Network overview). That pricing structure makes it cheap to over-provision VNet boundaries correctly at the start: place a workload in the network where its governance, peering, and routing requirements will continue to fit for its lifetime.
The platform gives you one documented escape hatch when the original choice was wrong: rebuild the VM in the right VNet, keeping the disks. Everything else in the move must be reasoned about and rebuilt by the operator.