As a continuation of my AZGateway migration scripts I entered the scripting world again for the migration of VMs. As anything worth doing is worth doing twice I actually wrote the entire script and then found out the Microsoft Azure SAP team already had something lined up. While their script did migrate VM’s there were a few things I did not like about their script, for example the lack of Public IP support when migrating VM’s and some cosmetic stuff in the backend.

So, I present today, 2 ways of migrating your existing VM’s, VMSS’s, Managed Disks and Network Cards (or actually Public IP’s on a Network card) from zone-to-zone or from regional-to-zone.

Github

The scripts (and modules) are available on GitHub.. if you want something improved.. do the pull/merge whatever thing..

The “Azure Blog Script”

First is my attempt to write a nice “Azure Blog script” with all the fancy outputs, exporting objects and much more.

Run it like:

.\Change-RegionToZoneARM.ps1 -VMName MyVM -TargetZone 3 -ResourceGroup MyResourceGroup

And optionally you can enable the -SkipAZcheck $True and -Login $true -VMsize to resize the VM on move.

The SAP based Module

The second script can be used a bit differently, as it is a full PSM1 Powershell Module so you’d need to import the module first and then run the exposed Move-AZVMToAzureZoneAndOrProximi…-{just hit tab}..

Import-Module .\ARMChange.psm1
Move-AzVMToAzureZoneAndOrProximityPlacementGroup -VMResourceGroupName MyResourceGroup  -VirtualMachineName MyVM -AzureZone 1

And optionally you have:

-PPGResourceGroupName – the name in which your Proximity Placement Group exists

- ProximityPlacementGroup – tha name of the proximity placement group

-AzureInternalLoadBalancerResourceGroupName – the load balancer resource group name

-AzureInternalLoadBalancerName – the load balancer name

-DoNotCopyTags – to avoid copying tags

-NewVMSize – to resize the VM

-KeepSameDiskNames -to delete the old disks and use the same names

-Force – to not ask for start/stop/delete but just run

The inner workings of the scripts

Now, while both scripts require different input, their innerworkings are actually the same (pfiew, my first attempt was inline with what others are thinking about cross zonal moves). Essentially there is some preparations that needs to be done to deploy a new VM, but the core is in Snapshotting the existing disks, then creating a new Zonal disk from the snapshot and build a new VM based on those new disks. Obviously while trying to keep as much configuration as possible.

Note that if you have a Public IP address assigned to the VM – this might change (under certain conditions).

 The first script keeps a full tracking log and makes backup copies of everything (my scripting mentor will be proud of me…) but the second script only takes a rudimentary copy of the original VM.

And so…

See if you like it.. provide feedback how it could be improved and as always.. test before you touch production