Move an Azure VM to another virtual network (Vnet)

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Install Ansible on Windows - Thu, Jul 20 2023
• Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
• Azure Virtual Desktop: Getting started - Fri, Apr 14 2023

In Microsoft Azure, the virtual network (Vnet) is the fundamental communications boundary in an Azure subscription.

Migrate an Azure VM to another subnet

Within a virtual network, it is trivially easy to move a Windows Server or Linux VM between subnets. Let us count the ways:

• Azure portal
• Azure PowerShell
• Azure CLI v2.0
• Azure software development kits (SDKs)
• REST API

In the Azure portal, for example, browse to a virtual machine's virtual network interface card (vNIC) configuration blade. Once there, navigate to the IP configurations settings blade. As shown in the following screenshot, the Subnet drop-down list box makes it easy to move between subnets within a single Vnet.

Assign a VM to another subnet in the same Vnet

Migrate an Azure VM between VNets

However, the situation takes on a different difficulty level when we need to move a VM between Vnets. Now, of course you have options for linking Azure virtual networks:

1. Vnet-to-Vnet VPN
2. Vnet peering (now between regions!)

The reason for this complexity is the fact I mentioned earlier, that Vnets represent communication isolation boundaries in Azure. It's by design, in other words. That said, you may have a use case that requires you to perform the migration. How can you accomplish this goal?

The first thing to accept is that Microsoft does not support Vnet-to-Vnet VM migration, and you'll have to redeploy the VM regardless. So—you need to plan for some downtime.

Historically, the Vnet-to-Vnet migration process in Azure required the following steps:

1. Stop and deallocate the VM.
2. Delete the VM, but save its virtual hard disks (VHDs).
3. Recreate the VM in the target Vnet by specifying the original disk.

You can accomplish the preceding (tedious) procedure by using many different methods, including:

• Azure PowerShell
• Azure Resource Manager (ARM) templates

The main gotcha with this approach is that of dependencies. Remember that a VM consists of more than a configuration and one or more VHDs. The vNIC is, in turn, linked to one or more IP configurations. These IP configurations determine the Vnet and subnet to which the VM is linked.

The following idea isn't supported and doesn't work, but I wanted to give it to you for completeness' sake.

Imagine if you could hack a Vnet-to-Vnet VM migration by following this recipe (which requires Azure PowerShell):

1. Add a new vNIC in the target Vnet.
2. Associate the new vNIC to the target VM; the VM will therefore be multihomed.
3. Make the new secondary vNIC primary and the old primary vNIC secondary.
4. Detach the secondary interface.

As a commenter verified in this Azure docs article, attempting the previous procedure generates the following error:

ErrorCode: SubnetsNotInSameVnet

ErrorMessage: Subnet customer-subnet-01 referenced by resource {ipconfig_resource_id} is not in the same Virtual Network {vm_resource_} as the subnets of other VMs in the availability set.

Watch this space, however—the Azure product groups tinker with their features every single workday, and we may be able to do something like this in the future.

The Recovery Services method

It seems to me that using Azure VM Backup presents the path of least resistance to accomplish our goal of migrating a VM to another Vnet.

Here is the high-level overview of this recipe:

1. Create a Recovery Services vault in the same region as your VM.
2. Onboard the target VM to Recovery Services and initiate a manual backup.
3. Ensure your target Vnet is ready to receive the VM.
4. Stop and deprovision the target VM.
5. Restore the backed-up VM to the target Vnet.

In my environment, I have two Vnets, as shown in the next screenshot.

Multiple Vnets in Azure

My adVM Windows Server VM resides on the adVNET Vnet in the adSubnet subnet. Our goal is to move the VM to the infra subnet in the adVNET2 Vnet.

The VM before the migration

We need to shut down and deallocate the source VM so we don't get resource conflicts after restoring the backed-up copy. Let's do that with Azure PowerShell:

Stop-AzureRMVM -ResourceGroupName '4sysops' -Name 'adVM' -Force

Next, in the Azure portal we will browse to Recovery Services Vault > Your Vault Name > Backup Items > Azure Virtual Machine > adVM (whew, that's a long path!) and click Restore VM. I show you this in the following screenshot.

Starting the VM restore process

Select the most recent restore point, and then be sure to specify the destination Vnet and subnet in the Restore configuration blade, shown next.

The most important step in the migration process

Two important notes are worth mentioning:

• If you want to keep the VM's name the same, you need to restore the object into another resource group if the source VM hasn't already been removed.
• If you need more configuration flexibility than what is shown in the Azure portal, you'll need to invoke Azure PowerShell.

Wrap-up

Well, there you have it! I hope that you're in a better place now in terms of what's possible with VM network migration in Microsoft Azure.