Converting Classic Azure Resources (ASM) to Azure Resource Manager (ARM) – Where to Start?

During a couple of recent client engagements, I realised there are still quite a few people using Azure Classic Resources. The simple reason for this is that they work and we all know in IT, if it ain’t broke…etc.

Now, if you only recently began working with Azure, you may never have even seen a Classic Resource. The change to Azure Resource Manager (ARM) started back in 2016. Classic Resources do have some similar objects now that they are fully in the “new” portal (yes there was an old portal, it was…odd) but the concepts are different. This is because the focus was on services, hence it being referred to as Azure Service Management (ASM). Now, Azure is focused on resources, therefore Azure Resource Manager (ARM).

Azure Cloud Services diagram
ASM Example

So if you discover, or own some classic resources and would like to move them to ARM, hopefully this blog post will help you make a start.

First, do you need to migrate away from ASM? So far, Microsoft has said no, they’re “not deprecating ASM in the near future”. However, if you note the use of “near” that could mean that as the Azure Roadmap progresses, ASM is eventually deemed redundant.

Updated 2020-02-28, Microsoft have announced deprecation of ASM VMs and dependent resources on March 1st, 2023.

The other reason for a migration may be that you want to avail of some of the features only supported in ARM or want to gain greater granular control of your individual resources. Whatever your reason, the approach is the same:

  • Plan
  • Validate
  • Prepare
  • Migrate
Plan

In this stage, you need to understand and most likely document all of the resources in scope for the migration. Once you have this, you can compare and contrast to options supported and changes required for migration to be successful. The following resources are supported for migration:

  • Virtual Machines
  • Availability Sets
  • Cloud Services with Virtual Machines
  • Storage Accounts
  • Virtual Networks
  • VPN Gateways
  • Express Route Gateways (in the same subscription as Virtual Network only)
  • Network Security Groups
  • Route Tables
  • Reserved IPs

The list for currently unsupported features is here.

While the migration operation for the most part takes place in the management plane, and there is therefore no downtime, you could proceed with a migration without impact to your users. However, I’d recommend either completing the migration out of business hours or planning a maintenance window to account for any unforeseen issues. I’d always rather have the window and not need it than the opposite!

It’s also important at this point to understand the order resources should be moved too. Microsoft have this flowchart, the lines are bit confusing but it’s accurate.

Screenshot that shows the migration steps

The most important point to take from the above is that if your VMs are all in the same vnet, well then you migrate the vnet, it will bring all dependent resources with it. Then your next step is any storage accounts.

Validate

Microsoft have provided a helpful validation operation within the portal and via Poweshell. This will give you a very quick look into your resources and their config to see if it’s compatible with a migration or not. However, it can not take into account all unsupported features, such as an issue on the ARM side, so ensure you complete your own checks!

Prepare

This is a key phase. The migration process occurs on the control plane, the data plane is unaffected at all times. The preparation operation allows you to create the ARM metadata while leaving your current ASM resources in place. This is represented in the graphic below:

Diagram of the prepare phase

Once the operation begins, the management plane is locked for the duration. This means you cannot make any changes to your resources. However, your users are unaffected. With one exception, if your VM is not in a vnet ( I know, crazy in ARM!) it will be stopped and started during Prepare.

If Prepare is successful, you can continue with the migration or, abort and fix any issues. The operation creates a non-editable Resource Group for each Cloud Service, copying the name and appending “-Migrated”. Nice and neat, relatively low impact and risk. Exactly what is useful during a migration! Remember, the management plane is locked, so if all is OK complete the migration to unlock. If not, abort to unlock.

Migrate

Once you’re good to go, the last step is to migrate. Again, this is only a control plane change. The operation is idempotent, so if it fails it can be retried. However, once complete you cannot rollback. Once complete, you will now be in the state represented below:

Diagram of commit step

The Classic Resources are removed and only the ARM versions remain. As the models are different certain services and aspects are renamed or incorporated in a different way, a full list of these mappings is here and is very useful during the Prepare phase and for future use once migrated.

All the steps required to migrate all VMs in the same vnet are documented and I’d recommend reviewing all steps before running any.

If you take your time and follow the recommended methods, you should be able to make your move from ASM to ARM pain free.

As always, if there are any questions comment or get in touch on Twitter!

Azure Migrate – Where to Start?

If you’re thinking about making a move to Azure, it’s important to first understand how to approach it. With the correct approach and sufficient planning, a migration can be straight forward, efficient and void of surprises.

Therefore, the place to start is the Microsoft Cloud Operating Model. This is a detailed white paper that allows you to create a strategy for migration. Covering cloud readiness, people strategy and technical analysis, it’s a comprehensive document. Once you have an understanding of your business strategy, read “Why am I moving to Azure?” and your people strategy, read “Who is moving us to Azure?” you can progress to the technical phase.

The vast majority of initial moves to Azure are often re-host migrations, or “lift and shift”, as these are most common, I will reference this scenario as an example. There are four stages:

The first step of the technical phase is to Assess. This means understanding what it is that you are moving and what the best process will be. This includes everything from involving the business stake holders, to cost calculation to application evaluation. This analysis should give you an output that not only details where the application could go but more importantly, where it can go.

Microsoft offer several tools to help with some of this. First up is Azure TCO. This allows you to estimate the cost savings you could make by migrating to Azure. Next is Azure Migrate, this is an assessment tool that is FREE and allows you to discover, document and assess your workloads and their dependencies. You can then create cost estimates for running them in Azure.

Azure Migrate Dependencies Example

Now that you have your environment discovered, grouped and sized correctly, you can begin to migrate your workloads. Microsoft provide a service for this also, Azure Site Recovery (ASR). This service allows you to replicate your servers from your on-premises environment. For most services it is application aware, meaning it can replicate services like SQL server without any data loss. Before you implement ASR it is important to use your data from Azure Migrate to capacity plan for your replication requirements. Taking this step allows for greater speed and efficiency during replication and migration of workloads.

Microsoft also provide a script repository for migrating large numbers of VMs at once. These can be from VMware, AWS, GCP or physical servers. There are some limitations, most restrictive is lack of support for Managed Disks, but you can always flip these manually later. The scripts and guide can be found here.

How long it takes to migrate your workloads is determined by your business requirements. However, once complete, it is vital that you revisit these workloads for optimisation. Azure Advisor can provide recommendations but the key areas to focus on are:

  • VM sizing – Ensure the VM is running on an appropriate size to gain maximum cost efficiency
  • Storage tier – Ensure the disks associated with the VM are using the correct tier to balance performance requirements against cost.
  • Reserved Instances – Once the VM is sized correctly, purchase Reserved Instances to achieve the maximum discount to run your workload for one to three years.

Now that your workloads are migrated and optimised, your final step is to ensure they’re secure and managed correctly. The best place to start with this process is Azure Security Center. This provides unified security management and allows you to take action to mitigate risk and implement actionable recommendations. This will include common requirements like disk encryption and anti virus. More advanced and platform specific features like Just In Time Access are also available.

So to recap, there is 1 prerequisite then 4 main steps:

  1. Understand and create your Cloud Operating Model
  2. Assess your current environment
  3. Migrate it!
  4. Optimise your utilisation
  5. Secure and Manage it

If all of the above is completed and optimisation and security are reviewed regularly you can be confident in the quality of your environment state. If you have any questions, feel free to tweet me @wedoAzure or leave a comment!