Introduction
If you have been working with Microsoft Azure for a while, you have probably come across two deployment models, Azure Classic and Azure Resource Manager, commonly known as ARM. At first glance, they might seem like two ways to do the same thing. But once you dig a little deeper, the differences between them are significant, and those differences have real consequences for how you manage your cloud infrastructure.
Azure Classic, also known as Azure Service Management, was the original deployment model. It was the only way to deploy resources on Azure before 2014. Then ARM came along and changed everything. It introduced a smarter, more structured way to handle resources, and it quickly became the recommended approach for almost every workload.
In this article, we will walk you through the primary differences between Azure Classic and Azure Resource Manager, explain why those differences matter, and help you understand what migrating from one to the other actually involves. Whether you are a cloud architect, a developer, or an IT professional just trying to make sense of your Azure setup, this guide is for you.
What Are the Differences Between Azure Resource Manager (ARM) and Azure Classic?
The primary difference between Azure Classic and Azure Resource Manager (ARM) comes down to one concept: how resources are managed. In Classic, every resource, a virtual machine, a storage account, a virtual network, lives on its own. They are independent units, and you deal with each one separately. In ARM, you can group related resources together and manage them as a single unit called a resource group. That shift in approach is the foundation of everything else that follows.
Deployment and Automation
With Classic deployment, you create and configure resources one by one or write custom scripts to deploy them in a particular order. There is no native template system, so automation is limited and harder to maintain. ARM, on the other hand, introduces ARM templates, JSON-based files that define your entire infrastructure. You can use these templates to deploy, update, and replicate environments consistently. Combined with tools like PowerShell, Azure CLI, and Azure DevOps, ARM turns infrastructure management into a repeatable, automated process.
Resource Grouping and Lifecycle Management
In the Classic model, you track each resource manually because there is no concept of a shared lifecycle. If you want to clean up after a project, you need to delete each resource individually, and it is easy to leave something running by mistake, which costs you money. ARM solves this cleanly. When resources share a group, you can delete the entire group at once, apply policies to the group, and track costs at the group level. It is a much more organized way to work.
Access Control
Azure Classic requires you to set access control policies on each resource individually. With ARM, you apply Role-Based Access Control (RBAC) at the resource group level, and those permissions automatically extend to every resource inside the group, including new ones added later. That is a significant time saver in environments where teams and resources are constantly changing.
Tagging
Classic deployment does not support tagging. ARM does. This means in ARM, you can attach metadata tags to your resources, things like project name, environment type, or cost center, and use those tags for billing analysis, automated policies, and resource tracking. It sounds simple, but for organizations managing dozens or hundreds of resources, tagging is invaluable.
Virtual Machines and Networking
In the Azure Classic vs. Azure Resource Manager comparison, one key difference is how virtual machines interact with networking. In Classic, a virtual machine does not necessarily require a virtual network, it is optional. In ARM, every virtual machine must be deployed within a virtual network. While this adds a step, it actually enforces better network architecture from the start. Teams that want to get this right from day one often choose to hire Azure developers who are already comfortable designing ARM-compliant network topologies, so nothing gets misconfigured when it matters most.
Load Balancing
Classic deployment handles load balancing automatically across VMs that are part of an Azure Cloud Service. ARM gives you more control, you explicitly create an Azure Load Balancer and configure it to distribute traffic across multiple VMs. It requires a bit more setup, but the flexibility and visibility you gain are worth it.
Dependencies Between Resources
One of the more practical advantages of ARM is that it lets you define dependencies between resources. You can specify that Resource B should only be deployed after Resource A is ready. Classic deployment has no such mechanism, you have to manage deployment order manually or through custom scripting. ARM makes orchestration far less error-prone.
Integration with Modern Tooling
ARM integrates natively with Docker, Terraform, Kubernetes, and Ruby, tools that are central to modern DevOps workflows. Classic has no such integration. If you are building a cloud-native application or following infrastructure-as-code principles, ARM is the only model that makes sense.
Migrate from Azure Classic to ARM
If you are still running workloads on the Classic deployment model, migration is not just a recommendation anymore, it is a necessity. Microsoft officially retired Azure Classic IaaS resources, and classic VMs that were still active after March 2023 were deallocated. In other words, the window to act has largely closed, and if you have not migrated yet, addressing it should be a top priority.
Here is what you need to know before and during the migration process.
Plan Before You Migrate
Microsoft recommends thorough planning and a lab test before moving production workloads. The complexity of your architecture will directly affect how long the migration takes. Simple setups can be done in an hour; large-scale deployments will take longer. You should set up a staging environment and test your migration plan before touching production. For organizations dealing with complex, multi-layered environments, working with professional Azure consulting services at the planning stage can save weeks of back-and-forth.
Registration Is Required
Before you begin, you need to register your subscription for migration. Without registration, the process cannot start. This is a simple but easy-to-miss step that catches many people off guard.
Migration Paths Available
There are four main scenarios for migration:
- VMs not in a virtual network: These will need to be placed in a virtual network during migration. A restart is required.
- VMs already in a virtual network: Only the metadata moves. The underlying VMs keep running on the same hardware with no downtime.
- Storage accounts: You can deploy ARM VMs in a classic storage account first, then migrate compute and network resources independently before migrating storage.
- Unattached resources: Network security groups, route tables, and reserved IPs with no VM attachments can be migrated independently.
Migration Tools
- You have a few options when it comes to tooling:
- The Azure Classic CLI (note: you must use the classic CLI specifically, not the newer Azure CLI, to migrate classic resources)
- Azure PowerShell
- Open-source tools like AsmMetadataParser and migAz
Things to Watch Out For
A few migration gotchas worth knowing:
- Backups taken of Classic VMs before migration will not be accessible in ARM after the move.
- User images created under the Classic model cannot be used to create VMs in ARM.
- Role-based access control policies need to be redefined after migration.
- There is a character limit when renaming VMs during migration.
- Rollback is only available while resources are in the "prepared" state. Once migration completes, there is no going back.
- If you hit a quota error during migration, abort the process and resolve the issue before retrying.
After Migration
Once you are on ARM, you will need to redefine your access control policies and update any automation scripts that were originally written for Azure Service Management. The good news is that once updated, those scripts will work seamlessly in the ARM environment.
Conclusion
The differences between Azure Classic and Azure Resource Manager are not just technical; they reflect a fundamentally different philosophy about how cloud infrastructure should be managed. Classic treats every resource as a standalone entity. ARM treats your infrastructure as a connected, manageable whole.
For anyone comparing Azure deployment models, Azure Classic vs. Azure Resource Manager, the answer is clear: ARM wins on almost every dimension. It gives you better automation, cleaner access control, smarter cost management, and native integration with the tools your teams are already using.
If you are still running Classic workloads, the urgency to migrate is real. Microsoft has already begun decommissioning Classic resources, and continuing on that path means operating outside of the modern Azure ecosystem, with no access to new services, limited third-party tool support, and growing security exposure.
The bottom line: ARM is not just the newer option, it is the right option. Moving to it is not just a technical upgrade. It is an investment in a more reliable, more scalable, and more manageable cloud environment.
Top comments (0)