Planning an Azure VM migration process: The fundamentals

April 29 2021

Worldwide, Azure customers are considering ways to migrate more software into Azure VMs and to transition workloads into Azure services. While moving an application to a new VM may seem straightforward, IT organizations need to prepare for several critical facets of an on-prem to Azure VM migration, from security to networking to governance, and even some critical organizational challenges.

While cloud migration is not simple, the last year has helped Microsoft, their partners, and their customers to improve and streamline adoption of Azure VMs and other services. Let's look at the most important ways that IT organizations can prepare for a successful transition.

Generally, customers need to start by educating themselves. What I've discovered is that many customers think in terms of on-prem concepts they already understand. But cloud is different. You don't need to take care of your servers as much or worry about bandwidth, depending on the migration model. Microsoft will take care of that. Instead, customers need to determine what services are going to moved and what services will require a VM. Many legacy apps can be moved, particularly if they can be used in a PaaS model. For instance, on-prem SQL databases can often go to Azure SQL.

Databases often fit the bill. Even open-source ones like MongoDB and Postgres are good to move into PaaS. If you have a lot of data, think about storage accounts. Web apps are good candidates to move into web app services and Functions. But keep in mind that some things aren't good candidates, like legacy apps with older APIs or dependencies on other servers. These might not be good to move to a service model. Instead, you can move the whole server as a VM.

The migration process usually goes pretty well. "Gotchas" come up if programs are not written for cloud services. In databases, a connection string might have to be rewritten for Azure SQL services instead of a regular database. You will have to remember that there are no plain text passwords in configuration files. A lot of customers have their accounts, server names and passwords all hardcoded, and those must be rewritten to use Azure Key Vault services. This isn't a code shift, but more of an implementation. Instead of using actual passwords, you call a GUI of the key. Key Vault will know what that is and pass it back down to the app. Customers also need to set up service accounts instead of user accounts. Lots of older apps have user accounts to give the correct permissions, whereas Azure doesn't allow that and steers customers into Service Principal, which means a different implementation.

Because you are moving to the cloud, every item on the server now becomes a service. You have to build out the network card, connect it to a subnet, and network the firewall and region. Every item is a separate service you need to account for, whereas with a traditional server you basically take it for granted. Everything from users and networks to firewall and Azure AD has to be taken into account.

Migrations into Azure VMs and services depends a lot on human factors in your organization. Different parts of the IT team have different roles to play in a cloud-focused team. Disaster recovery (DR) is a priority, particularly if you have members of your team already specializing in on-prem best practices.. You can rethink DR and business recovery. In Azure, you automatically get high reliability, different regions, and different datacenters where if something goes down it will automatically switch over to a backup site seamlessly.

IT teams should also expect changes to their security planning. What you have on-prem isn't going to transfer over directly because of firewalls, app security, and network groups. You need to be specific with what you allow through your network. The governance team needs to look at who is responsible for what. As big as Microsoft is, they probably have only 10 security admins with access to the highest level permissions. If you give someone access to your whole tenant they can do a lot of damage. At every step, consider how your security model plays out. Additionally, networking team needs to look at how each server is communicating to the others. Network traffic will be restricted. If not specifically allowed, Azure will block it.

With the pandemic receding, the pace of digital transformation is still picking up speed. As more organizations embrace cloud VM migration, we continue to improve our understanding of the techniques and skills required for a successful deployment. There has never been a better time to start migration planning with your team.


Photo by Ryan Quintal on Unsplash

FREE Membership Required to View Full Content:

Become a MemberLogin
Joining gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also have the option to receive periodic email newsletters with the latest relevant articles and content updates. Learn more about us here
About Jeff Christman

Jeff Christman is a Navy Veteran with over 20 years of experience in the IT field. Specializing in cloud migrations, he has worked for companies such as Raytheon, AT&T, and NASA. Currently, he is a Sr. Cloud Security Consultant at a large consulting firm. In addition to his daytime job, he also has published content and courses for,, and 

In his off time, he loves fantasy football, everything tech, and embarrassing his teenage daughters.

More about Jeff Christman