Freigeben über

Migrating Azure IaaS solutions from ASM to ARM using MigAz

  • Artikel

Anyone who has previously deployed Azure IaaS solutions using the older Azure Service Management (ASM) model should be thinking about how and when to migrate it to Azure Resouce Manager (ARM). While ASM will continue to be supported, ARM provides a number of benefits such as template-based deployment, Role-Based Access Control and Tagging. There are a number of tools that can help with this migration, and today I'm going to describe a new tool called MigAz.

Note : Azure’s capabilities and APIs change rapidly. This information is current as of July 2016. If you’re reading this in the distant future, you may want to check with other sources on current capabilities and best practices.

ASM to ARM Migration Options

At the time of writing, there are three main approaches you can use to migrate Azure IaaS resources (i.e. Compute, Networking and Storage) from ASM to ARM:

  1. ASM2ARM
  2. Platform Supported Migration
  3. MigAz

Each of these tools has their place, and it's great to have a few options available. ASM2ARM is PowerShell based, and I've seen a few cases where people have used it as the basis for their own custom migration solutions to meet unique requirements. The Platform Supported Migration is cool because it actually converts running resources from ASM to ARM, rather than creating new ARM resources that are copies of the original. However this tool requires a one-way "big bang" migration per VNET and doesn't give you a chance to clean things up on the way, so it's not ideal in all situations.

MigAz is the new kid on the block, and I like it because it provides a great balance between simplicity and flexibility.

What is MigAz?

MigAz is a tool created by Paulo Ramos that is based on a simple but powerful idea. Rather than migrate your ASM resources, MigAz builds a shiny new ARM Template that represents the ARM equivalent for your chosen ASM resources. This is cool a few reasons.

First, you can select whatever combination of ASM resources you want, and since they get represented in a single ARM Template that means they will ultimately become a single ARM Resource Group. This gives you an opportunity to create meaningful Resources Groups as you migrate, which will simplify management and deployment in the future. You can also leave out resources that you no longer want.

Second, since the output is just a JSON file, you're free to customise it as little or much as you want before you deploy. Don't like the name of your resource? Change it. Want to change the way your Cloud Services are represented with ARM concepts like Load Balancers and Availability Sets? Change it. And because ARM Templates can be redeployed over existing Resource Groups, you can improve things iteratively.

Finally, since MigAz creates an ARM template, you've got an artefact that you can check in to source control to start your "configuration as code" DevOps journey. This means you'll be able to deploy your solution to multiple environments without manual effort or risk of inconsistencies or errors. (To get the most out of this approach, you'll want to evolve your template to include environment-specific Parameters files).

Using MigAz

To install and learn how to use MigAz, go to https://aka.ms/migaz where you'll find the latest release and documentation. I won't try to replicate the full set of instructions, but the basic migration approach is as follows:

  1. Run MigAz.exe on a Windows PC or server.
  2. Sign into your Azure account.
  3. Select the ASM resources that you want to export.
  4. Export the resources to an ARM template.
  5. Use Azure PowerShell to deploy the ARM template to a new Resource Group. If the template includes Virtual Machines, you'll get errors the first time you deploy. Don't worry, this is normal as you haven't yet copied the VHDs from the ASM storage account to the new ARM one.
  6. Run the BlobCopy.ps1 PowerShell script included with MigAz to copy the VHDs into the new storage account.
  7. Redeploy the ARM template to the same Resource Group. With the VHDs in place, everything should be ready to go.
  8. Test the ARM deployment and edit/redeploy the template as needed.
  9. Decommission the ASM resources at the appropriate time.

Contributing to MigAz

Is there something you don't like about the tool? Found a bug? Well, MigAz is a community-supported open source project on GitHub, so you can submit issues, fork the repository and even update the code and submit pull requests. Come on, give it a go! (I did :-).