Rehost with Azure Migrate (Lift and Shift)

Rehost — commonly called Lift and Shift — is the migration strategy where you move a VM from on-premises to Azure with no changes to the operating system, application binaries, or data. Azure Migrate's Migration and Modernisation tool (formerly Server Migration) automates this process by replicating disk data to Azure and then cutting over with minimal downtime. Lift and shift is ideal for applications that cannot be easily refactored or have tight migration deadlines.

Before starting replication you must: complete discovery and assessment so you have target VM SKU recommendations, create the target Azure resources (resource group, virtual network, and subnet), and ensure the Azure Migrate appliance is healthy. For VMware sources, the appliance must have vCenter read permissions and the guest VM must be reachable via network from the appliance. Download and register the Replication Provider software if you are migrating from Hyper-V or physical servers.

Replication copies all disk data from the source VM to an Azure-managed cache storage account, then asynchronously stages the data in Azure. In the Azure Migrate portal, navigate to Replicate, select your source VMs, map them to the recommended Azure VM SKU, and choose the target virtual network. Initial replication time depends on disk size and bandwidth — a 100 GB disk over a 100 Mbps connection takes approximately 2 hours for the initial sync.

After the initial disk image is copied, Azure Migrate switches to delta replication — only changed disk blocks are sent, keeping the Azure copy in near-real-time sync with the on-premises source. The VM continues running on-premises during this phase. You can monitor replication health, RPO lag, and data transfer rates in the portal. Delta replication typically settles to only a few minutes of lag within 24 hours of initial sync completing.

Before cutting over production traffic, always run a test migration. This spins up the replicated VM in Azure on an isolated test virtual network that has no connectivity to production systems. You validate that the OS boots, services start, and application functionality works as expected. Test migrations do not interrupt on-premises replication — the source VM keeps running. After the test, clean up test resources in the portal to avoid unnecessary charges.

The cutover is the final step that moves production traffic from on-premises to Azure. During cutover: the source VM is quiesced (or you manually shut it down), any remaining delta changes are applied to the Azure replica, and the new Azure VM is started. Because this is a storage-level migration, cutover is typically very fast — under 10 minutes for most VMs. Schedule the cutover during a maintenance window and communicate it to application stakeholders in advance.

In the Azure Migrate portal, click Migrate for the selected server. You are asked whether you want to shut down the on-premises VM before migration (recommended to avoid data loss). Azure applies the final delta, creates the Azure VM, and marks the migration as complete. You must then update DNS records, load balancer backends, or application connection strings to point to the new Azure private IP or FQDN so that clients start using the Azure VM.

After cutover, run these post-migration checks: application health (load all application pages, run smoke tests), connectivity (verify the Azure VM can reach dependent databases and services), monitoring (install the Azure Monitor agent and enable diagnostics), and backup (enrol the VM in Azure Backup). If issues are found, the on-premises source VM can be restarted — it is still intact until you explicitly decommission it.

Once the migrated VM is stable in Azure and stakeholders sign off, you can decommission the on-premises source VM. In Azure Migrate, select Complete Migration to close replication. This does not automatically shut down the on-premises VM — you must power it off and reclaim the hardware through your normal IT asset management process. Decommissioning reduces on-premises infrastructure costs and moves you closer to a pure-cloud operational model.

For large migrations involving hundreds of VMs, Azure Migrate supports bulk operations via CSV import. You prepare a CSV listing each source VM, its target SKU, target resource group, and virtual network, then upload it to start replication for all VMs simultaneously. Migration groups let you sequence replication and cutover so that dependent application tiers (database, application, web) migrate in the correct order within the same maintenance window.

Watch for these common Lift and Shift issues: boot disk encryption on Linux VMs may prevent Azure from booting them (use Azure Disk Encryption post-migration); static IP addresses hardcoded in app configs must be updated to Azure private IPs or DNS names; firewall rules on-premises that reference the server's IP may need to be replicated in an Azure NSG; and time zone settings on Windows VMs may cause application behaviour changes in Azure's UTC environment.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: the Rehost migration flow goes from replication to delta sync to test migration to cutover, test migration validates the VM in an isolated network before going live, and post-migration steps (monitoring, backup, DNS update) are essential before decommissioning on-premises resources. Next up we cover best practices for migrating databases to Azure.