Moving a Windows Server or Linux virtual machine (VM) in Azure between virtual networks isn't as easy as you might think at first glance.
Latest posts by Timothy Warner (see all)

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)

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

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:

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

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

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

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

The most important step in the migration process

Two important notes are worth mentioning:

Subscribe to 4sysops newsletter!

  • 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.


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.

  1. Avatar
    Oleksiy Pavlenko 6 years ago

    So there is no way of achieving the same with attaching/detaching network cards for Resource Group Deployment model?

    • Avatar
      Chris neale 6 years ago

      No. You can’t detach the last NIC and you can’t add a new NIC that is connected to a subnet that is in a different VNet.

  2. Avatar
    Ganesh 6 years ago

    I tested this(Playing around with NIC’s to switch between VNET’s) and failed 🙂

  3. Avatar
    Richard 6 years ago

    I wanted to change a VM that was assigned to a VNET with address space to a VNET with a smaller address space e.g. so I basically added the new address space, created a new network interface.  Now you have 2 NIC’s in same VNET so you can add one then remove the other.  Then you need to go through a disassociate/delete/reassociate process (note VM must be stopped (deallocated).  So yes you can’t move VM between VNET easily but can restructure existing VNET with scary backup/restore & now global VNET peering is GA getting VM’s where you need them is much easier/cheaper.

  4. Avatar
    Richard 6 years ago

    *meant to say “without scary backup/restore”

  5. Avatar
    Isaac 5 years ago

    great suggestion. I’ve done the redeploy method a couple of times and found it to be tedious. I have a vm that has multiple NICs and encryption(as well as the temp drive changed to a different letter), so I have my work cut out for me. I believe just doing a restore will be key here. Its already backing up anyway, so doing the restore will likely save me some time


  6. Avatar
    Luis Simões 5 years ago

    What if you want to move the VM to a different subscription with a different Vnet and you cannot move the old Vnet because it will still be supporting other things on the source subscription?

    • Avatar
      praful 3 years ago

      The only way & Easy way
      Take a snapshot of the OS disk, move it to a new subscription and then create a new disk from this moved snapshot. Now, re-create same configured VM to have it in a new sub and new VNET.

  7. Avatar
    Graham Allen 4 years ago

    Hi, I found this article when searching for a way to move an Azure VM to another vnet. I tried the Azure backup and restore but found it was a long process waiting for the VMs to be restored. After much googling I found there were other ways to move a VM, mainly be deleting and re-creating it. These steps were quicker but riskier due to lots of manual steps and if you made a mistake you could permanently lose your VM! Long story short I decided to automate it all with PS script and noticed there was nothing like on the net so finally decided to write my own blog post and share it.

    Just thought I'd mention it here as an alternative to the backup and restore method if that's ok with you? Might help some others out like me!


  8. Avatar
    AzureEnthusiast 4 years ago

    Easy way is to delete the VM which stores the disk. Then go to the disk and create a New VM under new VNET.

  9. Avatar
    Raphael Büchi 2 years ago

    Take a look at this script which I created:

    You can just use the “-newSubnetId” parameter

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account