Moving an Azure VM to another virtual network

Introduction

This is a rewrite of an article I wrote back in 2020 that gained some popularity. With this rehaul, I'd like to make things more clear.

Problem & Scenarios

You want to attach the VM to a different subnet that is in the same virtual network as the original one.
You want to attach the VM to a subnet that is in a different virtual network than the original one.

Solution Scenario 1

This can be solved quite easily. All that must be done is to attach the network interface to another subnet.

Azure Portal

Virtual machine > Networking > Network Interface > IP configurations

Azure PowerShell

# Get network interface
$nic = Get-AzNetworkInterface -Name "vm-nic-foo"

# Get virtual network 
$vnet = Get-AzVirtualNetwork -Name "vnet-bar"

# Get a subnet from vnet 
$subnet = Get-AzVirtualNetworkSubnetConfig -Name "snet-bar-1 -VirtualNetwork $vnet

# Change subnet of network interface 
$nic.IpConfigurations[0].Subnet.Id = $subnet.Id

# Finally write back to Azure 
$nic | Set-AzNetworkInterface

Azure CLI

# Get ip configuration name
az network nic show --name vm-demo661 --resource-group vm-demo --query ipConfigurations[0].name

# Get target subnet id
az network vnet subnet show --vnet-name vnet-demo --name snet-destination --resource-group rg-infrastructure --query id

# Change subnet of network interface
az network nic ip-config update --name ipconfig1 --nic-name vm-demo661 --resource-group vm-demo_group --set subnet.id=<target-subnet-id>

Solution Scenario 2

First, some words of disappointment! Microsoft doesn't support migrations of virtual machines into other virtual networks. That means you can't just create a new network interface in a different virtual network and attach that to the virtual machine.

Instead, you'll have to redeploy your VM in some or the other way and, therefore, will face downtime!

☝🏻 A word of warning! As the suggested solution implies touching the virtual disk, ensure you have a proper (and tested) backup in place! Make sure you understand the impact of your actions!

There are two ways to achieve the desired goal. Either by leveraging a recovery service vault or by manually recreating the virtual machine from the original disk (recommended).

Recreating the virtual machine from the original disk

🔎 When following this procedure, remember that you'll have to recreate every configurational aspect of the virtual machine manually. This includes NSGs, public IPs, and any other configuration from the source machine!

First, you'll have to delete the accidentally placed VM. You'll want to make sure not to delete the disk!

Make sure the associated disk doesn't get deleted

Next, we can recreate a new virtual machine from the disk and choose the right virtual network this time.

Using a recovery service vault

🔎 When following this procedure, remember that it won't restore NSGs and any other resource that might be attached to the source machine. Also, the public IP address will change. So you might prefer the beforementioned option.

This solution requires a general purpose v2 storage account and recovery service vault in the same region as the virtual machine. So go ahead and create a recovery service vault and storage account in the same region and create an initial backup of your virtual machine.

After the backup has been completed, navigate to Virtual machine > Backup and click on Restore VM. Here, we don't want to replace the existing virtual machine as it won't give us the option to change the network configuration. Instead, we will choose Create new and select the proper target virtual network/subnet.

Optionally, you can delete the original VM (including its associated objects) beforehand, so the original VM name can be reused.

Conclusions

As demonstrated, changing a virtual machine's subnet on the same virtual network is easy as cake. However, changing the virtual network requires more work to be done. Here are some further notes that might help you!

All resources attached to a virtual machine must be in the same region (virtual network, network interface, public IP, managed disk)
A network interface must be in the same region as the virtual network/subnet it is going to be attached to
A network security group must be in the same region as the network interface/subnet it is going to be associated with
You can associate multiple NICs on a VM to multiple subnets, but those subnets must all reside in the same virtual network

Thanks for reading!