Today, the Azure portal allows you to create 2 types of VMs. These types refer mainly to the platform atop which your VMs run. Before I continue with this post, it may be handy establishing what the terminology means:
Classic/ASM
Classic or v1 VMs run on top of the older Azure Service Management (ASM) technology. ASM infrastructures can be managed through both the old and the new portals and Azure PowerShell/CLI. However, some of the v1 features are not yet, and may never be, available on the new Azure Portal.
New/ARM
Resource Manager or v2 VMs run on top of the new Azure Resource Management (ARM) technology. V2 infrastructure is only available through the new portal and offers significant benefits over its predecessor, mainly in the automation and DevOps domain. ARM templates allow you to export/import your infrastructure and enable high degrees of automation.
Creating new resources on Azure should be done against the v2 infrastructure. However, today, there are plenty of customers that still run their existing VMs on the “old”, ASM platform. This post will explain the 4 options for migrating v1 VMs to v2.
Option 1 – ASM2ARM
[ASM2ARM](https://github.com/fullscale180/asm2arm" target="_blank) is 3rd party PowerShell library that contains a set of commands that allow the migration of individual v1 VMs to v2. I wrote an earlier blog post about how to use this tool for migrations [here](GHOST_URL/migrate-your-azure-vms-to-azure-resource-management-arm-stack/" target="_blank).
Pros:
This option is fully scripted. It doesn’t require to touch the portal (UI) and includes a ‘dry run’ step that you can use to verify that the auto-generated commands will produce the desired results. You can take this a step further and use PowerShell to loop through all your v1 VMs and generate the necessary migration commands in one go, so it’s perfect for batching and fine tuning your migrations. You also have full control of the target regions and topology so it’s a good choice if you want to migrate to an already established network topology (vNETs, Resource Groups etc).
Cons:
It’s too manual and prone to error, especially if you mistype any of the parameters. It also auto-adds prefixes to the names of the migrated resources so it’s far from ideal if you want to use meaningful names without ‘migrated-‘ on the front. Finally, it requires a shutdown of the v1 VM for the duration of the migration. This means downtime. In addition, since the tool migrates VMs by copying the primary and attached VHDs, the process can be slow.
Conclusion:
Although I would consider it a great choice due to its scripting capabilities, it’s slow and requires downtime
Option 2 – Azure PowerShell
With the release of Azure SDK v2.9, there’s built in support for migrating resources. You can read all about it [here](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-ps-migration-classic-resource-manager/" target="_blank). These commands are still in the first iteration and a lot more support and flexibility will be added in subsequent releases. The post contains a rough roadmap and supported scenarios so that you can thoroughly investigate whether this option is applicable to you.
Pros:
Built-in support and fully scriptable. The documentation is good and, even though it’s still early days, the commands cover most of the basic scenarios. The biggest benefit is that migration can happen on the fly with no downtime. Since the migration process only copies the VM metadata without touching the VHDs, it’s lightning fast and it’s seamless. The team is hard-at-work developing the tooling to extend it’s capabilities, as the goal is to move as many resources as possible to the new, improved platform.
Cons:
The currently supported scenarios are limited. Right now, only classic VMs in a Cloud Service (VMs older than 2 years) or whole vNETs can be migrated. You cannot pick and choose VMs within an existing vNET to migrate to a new v2 resource group. As such, if you already have a v2 infrastructure (Resource Groups, vNETs, subnets, NSGs etc) then the current version of the tool cannot migrate individual vNETS.
Conclusion:
No downtime, very fast and fully baked in the Azure PowerShell tooling. It’s fully scripted and allows a rollback in case there’s an error in the migration execution. However, the supported scenarios are limited and you cannot migrate into an existing network topology if migrating whole vNETs. Make sure you read the supported scenarios before committing to this option
Option 3 – Azure Site Recovery (ASR)
[This Azure service](https://azure.microsoft.com/en-gb/documentation/services/site-recovery/" target="_blank) is not primarily designed for migrating from v1 to v2. ASR allows migrating from on-premises or other cloud providers to Azure or for backing up VMs for disaster recovery purposes. ASR can either replicate or backup VMs and the idea is to have a cold standby that can be used to either manually or automatically fail over, in case of a serious problem on the primary site. Consequently, we can hijack this service and migrate to v1 VMs to v2 from one Azure ‘site’ to another.
Pros:
The process can be fully managed through the UI and supports batch migration of multiple VMs at a time. Setting up and running ASR is also supported through PowerShell using [these cmdlets](https://azure.microsoft.com/en-gb/documentation/articles/site-recovery-vmm-to-azure-powershell-resource-manager/" target="_blank). Once the setup is complete, spinning up the secondary (v2) VMs takes only a few minutes and has the added benefit that the original VMs remain intact in case we need to fall back due to unexpected problems. The migration progress is visible through the portal so it’s easy to monitor the process and detect any issues early on.
Cons:
The ASR setup is complicated and takes time. Surely, this only needs to happen once and there are setup instructions, however, not everything is covered. This is because, in this instance, ASR is used for a migration scenario that's out with the original service’s design. Some instructions, specific to this scenario, are missing and will need to be manually configured. Furthermore, once a VM is added to the replication process, it takes time for the sync to take place. The VM VHDs are copied across and are prepared for migration. This syncing process may be slow and depends on the number of disks affected. Migrated VMs have no public IPs assigned by default. This will need to be a separate step once the secondary VMs become available. In addition, if you rely on the public IP to be available, a DNS switch will need to take place to ensure that the IP address resolves to the right VM/Service. Finally, there are some configuration changes required in order for VMs to be added to ASR. These include the creation of a local admin account and opening 2 ports on the firewall to allow the remote agents to communicate with the “Process Server”.
Option 4 - MigAz (Migrate Azure?)
[MigAz](https://github.com/Azure/classic-iaas-resourcemanager-migration/tree/master/migaz" target="_blank) is the newest tool in the series that allows you to migrate IaaS workloads from a v1 to v2 both within the same or different subscription. It's the complete solution and also comes with a great GUI to help you make the job better. Ok, it makes the first part of selecting the resources you want to migrate easier, but you'll still need to run a couple of scripts to complete the job.
Pros:
The tool is quite refined and there's ample documentation and a few walkthroughs ([example 1](http://www.aidanfinn.com/?p=19762" target="_blank), [example 2](https://www.petri.com/migrating-azure-vms-armcsp-using-migaz" target="_blank), [example3](https://blogs.msdn.microsoft.com/tomholl/2016/07/16/migrating-azure-iaas-solutions-from-asm-to-arm-using-migaz/" target="_blank) )to help you get started. It covers a wide range of scenarios as well and depending on the most appropriate scenario for your case, you may be able to migrate without any downtime. This means that you'll be able to keep both the v1 and v2 sites running side by side. This won't come without a cost though, as you'll need to sync the data between the 2 environments, if you decide to go down this route. Below I've got a list with the currently supported scenarios:
- Migration using new virtual network with different address space
- Migration using new virtual network with same address space
- Clone environment for testing
- Clone environment with new virtual machines and data disks
Cons:
I couldn't find many faults with this tool/service. It's quite powerful and uses the existing Azure REST API to perform the different operations so there's nothing magic happening behind the scenes. One aspect that you need to be aware is that you cannot fully automate the migration with this tool (the 1st part anyway), there may be some manual file editing to change names and destinations if you wish to and keeping both environments, old and new, live is not easy without extra steps for data syncing. Finally, this is an OSS project and, if you come across any issues, you'll be able to get support from the developers and the community. Being OSS, you can help add more features or even help fix bugs (if you find any along the way)! Win-win, if you ask me.
Conclusion
I really like this tool as it gives you the best of both worlds. A nice GUI to pick and choose your resources and a script to run the migration. It only uses 2 files to store the JSON templates and properties so nothing in comparison to the output of ASM2ARM. The luck of official support may be an issue for some so you need to ensure that this is a know factor before you embark on a migration using AzMig.
Conclusion:
This is probably the easiest way to migrate and manage the overall process, as long as you’re happy to take the initial hit and set up the service. There’s a downtime associated with this option but most migrations require a bit of downtime anyway. In the end, it’s all about managing expectations and figuring out the best time to take services offline for the migration.
Migration option feature matrix
With 4 options to choose from, I hope that this post helps you decide on the best approach when it comes to migrating your Azure v1 resources.