When a business creates various compute, storage, and network resources, they have a choice between using the Classic deployment or the ARM deployment. Even though resources can be created using either deployment model the two portals are not compatible with one another.

It has been the case for many businesses that when an environment has been first created within Microsoft Azure, the resources were created using the Classic deployment method. This may be because the required feature was not available within ARM at the time of deployment.

As it is becoming more and more apparent that the Classic deployment method will not be updated with new functions and features, more and more businesses have been looking at ways to migrate to the ARM deployment method. This is because ARM is currently being updated on a regular basis and is the recommended deployment model to use as per Microsoft.

New features and functions are constantly being added and updated within ARM method, this gives the business an expanding base to utilise. The ever-expanding features and functions allow a business to create personalised and bigger environments for use.

Currently, depending on which deployment method a business decides to work with, there are two different portals available.

This blog has been created to describe the how a business can move their resources from a Classic deployment (ASM) to a new and constantly updated deployment (ARM) within Microsoft Azure.

       Azure Service Manger (Classic Deployment)

The Classic deployment is often known as Azure Service Management (ASM) and is effectively version one of the Azure Portal.

The Classic deployment method utilises cloud resources such as virtual machines, networks, cloud services, etc to enable a business to create a custom environment specific to their requirements.

With a classic deployment resources are managed individually, there is no way outline management groups or resource groups for different resources. Cloud services however can be utilised as containers to hold resources that require availability from load balancers etc.

The Classic deployment has a basic security model allowing for Admins and Co-Admins to be defined. The ability to set role based access within a classic portal is not available leading to a situation where a user has full permissions or no permissions. It is not possible to grant permissions to individual types of resource.

The Azure Service Management (ASM) portal can be accessed using the below link


       Azure Resource Manager (ARM)

The newer deployment method is known as Azure Resource Manager (ARM), it allows for a greater variety of features than its predecessor. Microsoft took what they had learnt from ASM and rebuilt the infrastructure making Azure significantly more flexible. The ARM portal is constantly being updated with the latest and greatest features, this unfortunately means it in incompatible with ASM.

ARM supports resource groups which enables the business to group together multiple resources under one group and easily maintain and manage the environment that is being created.

JSON templates are supported which can help with easier and more consistent resource creation, which is great for a test environment for example.

The security model has much more variety as the ability to grant role based access control (RBAC) is available within the new portal. The ability to create policies has been added to the New portal, and these policies can be set at the subscription, resource group or resource levels.

A few examples of what policies can achieve have been listed below;

  • Limit the creation of a specific resource within a resource group
  • Limit the creation of resources to a specific region
  • Require a tag (Key-value pair) to be set, to start an operation

The policies differ from RBAC in the sense that you aren’t defining who can perform an operation, instead you are putting scope around the operation itself.

One major benefit of moving to an ARM deployment is that a business will be future proofed, any features that will be released by Microsoft will be released for the ARM deployment, allowing a business to utilise new features as they are released. There are better management options that allow a business to keep control of billing and what resources they are using.

The Azure Resource Manager (ARM) portal can be accessed using the below link


        The Problem

With there currently being two deployment options for a business to choose from, it can be difficult to decide which method to build using. Microsoft recommend, a business should begin using the ARM deployment method to allow for future growth and the ability to have access to newly updated features.

There are businesses that have already begun building environments using the ASM deployment method. Although ASM is not going away anytime soon, using ASM means a business is unable to take advantage of the new features coming from Microsoft. Manually recreating each resource can lead to several difficulties, such as;

  • Resource misconfiguration caused by user error
  • Resources may be missed which can lead to vital resources not working
  • Significant downtime to migrate

This is where migration tools can help, instead of recreating a brand-new environment from the beginning and manually which can be complex and very time consuming, there are now solutions that can give a business the ability to migrate resources from the ASM deployment to the ARM deployment and begin future planning and using new features.

Being able to move to the ARM deployment method easily and without taking much time allows a business to begin exploring such features like DevTest labs.


There are now multiple methods that will allow a business to migrate their resources from a classic deployment (ASM) to a new deployment (ARM). Each solution will offer a business different abilities, from migrating a single virtual machine to migrating a full ready to go environment without downtime. It all depends on a business’s individual requirements.

Each solution can require knowledge and understanding in differing areas, such as PowerShell or JavaScript Object Notation (JSON)  scripts.

The sections below will outline a selection of the solutions available and details their capabilities:

  1. MigAz
  2. ASM2ARM
  3. Platform Supported


MigAz has adopted the Microsoft Open Source of Conduct, with this solution being an open source project it is possible to add features to it if required and the business will be able to get support from the OSS community. It allows a business to migrate ASM resources to ARM using JSON templates.

The solution outputs a JSON template, meaning if a business wishes to edit the name of a resource or slightly alter a resource configuration, they can edit the JSON template and then deploy using the ARM deployment.

The files for the MigAZ solution can be found by clicking here


  • The MigAz solution gives a business the ability to migrate a full set of ASM resources to ASM in one session.
  • The subscription used within ARM can be different to the subscription used in the source ASM environment.


  • An understanding of JSON is required for this method.
  • Some downtime required

       Platform Supported Manual Migration.

This solution uses PowerShell to migrate resources from a classic deployment to a new ARM deployment. ARM has built in migration functionality and gives the business the ability to plan and test before finalising a migration. The best practice path for a migration is to follow the below path:

  • Prepare
  • Plan
  • Commit / Abort
  • Validate

Utilising the Azure PowerShell commands to connect to an Azure subscription and give a business the ability to migrate resources as required.

A classic deployment migration can be achieved by defining an Azure Subscription and selecting the resources that are to be migrated, validating the migration and starting the migration.

This method take a copy of a virtual machines meta data (information about the virtual machine), and does not do anything to the virtual hard drive (VHD). This allows for a live migration, the ASM machine can still function whilst the new machine to being configured. Therefore, this method is quick and no downtime is required while migrating using this method.

A guide on how to migrate from an ASM deployment to and ARM deployment using Platform supported method can be found by clicking here

  • The PowerShell method can be easier to understand than other methods.
  • It is possible to migrate a virtual network in one session as opposed to a single VM
  • Can be rolled back if required
  • Lots of documentation available
  • A rollback option is available
  • No downtime and can be fast


  • ExpressRoute and Application gateways are currently not supported for migration, this should be achieved by removing the gateway first, then migrating and manually reconnecting / recreating the gateway in ARM.
  • An understanding of PowerShell is required to migrate using this method
  • Single virtual machines cannot be migrated at once.


The solution utilises PowerShell scripts for migrating a single Virtual Machine (VM) from a classic deployment (ASM) into a new deployment (ARM). Originally created by Microsoft, they decided to make this solution an open source solution, therefore allowing users to contribute to improvements.

This method clones a VM and will copy it to an ARM environment, when migrating a virtual machine the machine must be powered down for the migration to succeed.

The files and guide can be found on GitHub by clicking here.


  • The ability to migrate a single VM
  • Ability to perform a dry run of the migration to test


  • Load balanced virtual machines cannot be migrated.
  • Only one virtual machine can be migrated at once, multiple virtual machines are cloned / migrated using this solution in a short space of time, a DNS conflict could occur within the business. This is due to the DNS cache refresh time
  • Solution is prone to manual error
  • Requires downtime to complete migration and can be slow

  Final thoughts…

Deciding which Azure deployment model to use when building an environment can be a tough decision for a business. It is starting to become a requirement for some businesses to begin migrating their resources from an ASM deployment to the newer ARM model. This is to ensure they are future proof and can have access to the latest features that are constantly being updated. This document has given a brief overview on a few of the solutions available to achieve that.

ASM2ARM is a fully scripted solution it can be slow and requires downtime.

MigAz requires the business to have knowledge and understanding of JSON templates and can potentially completed without downtime.

The Platform Supported Migration can give a business the ability to perform a live migration that does not require any downtime and can be quick to complete

Each method of migration that has been discussed has multiple benefits and drawbacks and they can perform a variety of different tasks for a business, but ultimately it will be down to a business’s specific requirements as to which method is suitable.