End to End Migration of Linux VMs to Azure Using Azure Migrate

In the era of digital transformation, cloud migration is no longer just a trend; it has become a business imperative. Enterprises around the world are modernizing their IT infrastructure by shifting from traditional on premises data centers to cloud platforms, such as Microsoft Azure, to achieve agility, cost savings, scalability, and enhanced security. Whether you're running a startup or a global enterprise, moving your critical workloads to the cloud can provide a competitive edge.

But how do you ensure a smooth and intelligent migration process that minimizes downtime and maximizes performance?

Azure Migrate is Microsoft’s centralized, unified platform that simplifies the discovery, assessment, and migration of a wide range of IT assets, including:

• Virtual machines (Windows/Linux)

• SQL and other databases

• Web applications

• File shares and NFS workloads

• Virtual desktops

This blog captures a complete E2E real world Linux workload migration scenario using Azure Migrate. We'll be walking through every stage of the process from preparing the environment to running assessments, replicating VMs, performing migrations, and validating the post migration setup.

Real World Use Case

In our scenario, we’re tasked with migrating three Linux-based virtual machines from an on premises VMware vSphere environment to Microsoft Azure. These VMs host:

• A Database Server (S003-DB01)

• A Web Server (S003-Web01)

• A File Server with NFS services (S003-NFS01)

Such a setup is very common in real-world deployments where:

• The web server hosts dynamic PHP or HTML-based web apps

• The database server supports MySQL or PostgreSQL backends

• The NFS server manages shared storage, often used in clustered or hybrid workloads

Through this comprehensive hands-on migration lab, you'll learn how to

• Set up the Azure Migrate project and appliance to initiate discovery

• Build and analyze a business case to justify cloud costs

• Conduct a compatibility and performance assessment

• Replicate onpremises Linux VMs in Azure securely and efficiently

• Perform a production level migration with minimum downtime

• Configure post-migration networking and public access

• Validate that the Linux based web application works flawlessly post migration

Types of Migration Covered

This blog primarily focuses on infrastructure migration (IaaS), specifically:-

• Cloud to cloud (VMware on premises to Azure)

• Linux VM migration

• Database and application migration (within those VMs)

• NFS based file server migration

Unlike platform migrations (PaaS), this approach maintains your OS and application layer, allowing for a “lift and shift” (rehost) strategy. This is ideal when:

• You don’t want to modify your application code

• You need to quickly move to the cloud

• You want to maintain your existing toolchain or configurations

Step 1:- Azure Migrate Project Initialization

I navigated to Azure Migrate and created a new migration project.
This project acts as the central hub for managing discovery, assessment, replication, and migration. All tasks and configurations are tracked here, ensuring consistency and manageability throughout the migration lifecycle.

Step 2:- Deploy and Configure the Azure Migrate Appliance

After initializing the Azure Migrate project, the next and most critical technical step is setting up the Azure Migrate Appliance. This appliance acts as the bridge between your onpremises infrastructure (like VMware or Hyper-V) and Azure.

Without the appliance, Azure Migrate can't see or analyze your local environment. This appliance is responsible for securely discovering servers, collecting metadata like CPU usage, memory, disk I/O, and sending that information to Azure for accurate assessment and cost estimation.

Used the Azure portal to download a pre configured OVA template for VMware (you can also use a VHD for Hyper-V or a script for physical machines). This virtual machine is preloaded with everything needed to connect securely to Azure.

logged into vSphere, deployed the appliance, and assigned the necessary network configurations (static IP, DNS, and gateway). Once booted, it provided me with a browser based interface known as Appliance Configuration Manager.

In the Azure portal, under the migration project, generate a registration key, copy it, and use it within the Appliance Configuration Manager. This securely links the onprem environment to my Azure Migrate project.

The appliance serves as a bridge between on-premises infrastructure and Azure.

Discover onpremises VMs, collect performance metadata, and send that data securely to Azure. This is foundational for accurate assessment and planning.

Inside the Configuration Manager, enter the vCenter Server IP and read only credentials to allow the appliance to connect and enumerate all the VMs present.

After verifying connectivity and authentication, I enabled discovery, which started collecting metadata (such as CPU usage, memory utilization, OS type, network adapters, and disk details) for the Linux VMs that needed migration.

Step 3:- Build a Business Case and Run a Migration Assessment

After successfully discovering 3 onpremises Linux servers S003-Web01, S003-DB01, and S003-NFS01Using the Azure Migrate appliance, I initiated two critical processes that lay the groundwork for a smart, cost-effective, and technically sound cloud migration:

1. Created a Business Case (bc-52148082)

2. Ran a Performance Based Assessment (as-52148082) for the discovered servers

Before any migration, it’s essential to ask: "Is moving to the cloud worth it?" That’s where the Azure Migrate Business Case tool comes into play. It evaluates the cost effectiveness, readiness, and long term savings of moving workloads to Azure.

Select the Azure recommended migration strategy and apply Reserved Instances + Azure Savings Plan to understand potential financial benefits. The business case included:

• Cost projections (compute, storage, network)

• Comparison between onprem and Azure pricing

• Readiness scores for each server

Insight Gained:-

• I could justify migration to leadership based on real ROI.

• It showed how long it would take to break even after the move.

• Helped identify which VMs were ready and which might require changes.

Next,

I ran a performance based assessment to map onprem resources to their ideal Azure equivalents. This wasn’t just a guess; it was based on actual usage data collected over time.

Step 4:- Build Azure Resources & Configure Replication

After establishing a solid business and technical foundation through assessment, the next logical phase of the migration journey is preparing the Azure infrastructure and initiating replication of the source Linux virtual machines. These two steps ensure that the cloud environment is ready to receive the workloads and that data remains continuously up-to-date until final migration.

Crated the essential networking and public access infrastructure in Azure:-

• Virtual Network:- migration-vnet-52148082 In the East US region

• Public IP Address:- ip52148082 With a custom DNS label linux-web-52148082 to expose the migrated web server publicly

These resources were created inside the resource group AZMigrateRG, which acts as a container for all related assets.

With the infrastructure in place, I moved to the Migration and Modernization section in Azure Migrate and initiated replication for the 3 Linux VMs:-

• Group Used:- Linux-Servers (created during the assessment step)

• Assessment Reference:- as-52148082 to auto-import sizing and performance settings

• VMs Replicated:-

  • S003-Web01 (Web Server)

  • S003-DB01 (Database Server)

  • S003-NFS01 (File Server)

All target configurations were mapped to the VNet migration-vnet-52148082, under the same region and subscription used in earlier steps.

Step 5:- Execute Final Migration & Configure Post Migration Networking

Now that replication was active and our landing zone in Azure was prepped, it was time to take the final and most crucial leap, migrating the live Linux workloads into Azure and ensuring they’re correctly configured for both internal networking and public access.

Using the Azure Migrate Replications blade, I performed the final migration of all three VMs. Importantly, I selected - Shutdown machines before migration = Yes

The 3 VMs migrated were:-

• S003-Web01 (Web Server)

• S003-DB01 (Database Server)

• S003-NFS01 (NFS File Server)

During this process, the migration status moved through the following states:-

• Queued → In Progress → Completed

After migration, I completed essential networking tasks to ensure the workloads were accessible and behaved as expected:-

1. Assigned Static Private IPs to all 3 VMs

   • S003-Web01:- 10.10.10.37

   • S003-DB01:- 10.10.10.27

   • S003-NFS01:- 10.10.10.25

2. Associated with the Public IP (ip52148082) to the Web Server (S003-Web01) - Added the DNS label linux-web-52148082

With this configuration in place, I was able to access the migrated web server using the public DNS

Migrated Web Server using the Public DNS

I successfully migrated a set of three on-premises Linux VMs S003-Web01, S003-DB01, and S003-NFS01 to Microsoft Azure using the Azure Migrate platform. What began as raw infrastructure running locally has now transformed into resilient, cloud native workloads running in eastus, powered by premium managed disks and secure, networked Azure services.

What This Migration Achieved

• Modernization:- By lifting and shifting our Linux workloads to Azure, we laid the foundation for modern cloud native development, monitoring, scalability, and integration.

• Cost Clarity:- The business case provided a clear cost model with reserved instances, savings plan insights, and a readiness score, helping justify cloud migration to stakeholders.

• Performance Assurance:- The assessment phase gave us confidence that our VMs were sized appropriately, minimizing overprovisioning or future scaling surprises.

• Continuity:- Continuous replication ensured that we didn’t miss a single byte of data during cutover. Controlled shutdowns meant zero data inconsistency.

• Security and Accessibility:- With virtual networking, static IPs, and a public IP for the web server, our environment is now secure yet accessible, exactly as it should be.