Lift and Shift Migration: When It Works and When It Doesn't
Lift and shift migration — also called rehosting — moves applications and workloads from an on-premises environment to cloud infrastructure without modifying the application code, architecture, or runtime dependencies. This page covers the definition and operational scope of the approach, the mechanics of how a migration executes, the scenarios where rehosting is the appropriate strategy, and the decision boundaries that separate it from refactoring or replatforming. Understanding those boundaries is essential before committing infrastructure spending to a migration wave that may not deliver expected outcomes.
Definition and scope
Lift and shift migration is one of the canonical migration strategies defined in Gartner's "5 Rs" framework (rehost, refactor, revise, rebuild, replace), later expanded by AWS and other cloud providers into variations including a "6 Rs" or "7 Rs" model. The AWS Migration & Modernization program defines rehosting as moving an application to the cloud with no changes to the application itself — the compute instance, operating system image, storage volumes, and network configuration are replicated in a cloud-hosted form.
The scope of lift and shift typically includes:
- Virtual machine (VM) images or physical-to-virtual conversions
- Block and file storage volumes attached to those VMs
- Network topology replication (subnets, security group rules, firewall policies)
- Licensing state of the operating system and installed software
What lift and shift does not include: re-architecting for cloud-native services, containerizing applications, switching database engines, or enabling auto-scaling. Those changes cross into replatforming or refactoring territory, which carry different cost, risk, and timeline profiles.
The National Institute of Standards and Technology (NIST SP 800-145) defines cloud infrastructure as a service (IaaS) as the delivery model where the consumer provisions processing, storage, networks, and other fundamental computing resources. Lift and shift targets IaaS almost exclusively, since the application remains in control of its own runtime stack rather than delegating that responsibility to a managed platform.
How it works
A lift and shift migration proceeds through four discrete phases regardless of the cloud provider involved:
-
Discovery and dependency mapping. Tools such as AWS Application Discovery Service or Azure Migrate scan on-premises environments to enumerate running processes, open ports, network connections, and storage consumption. The output is a dependency map that identifies which servers must move together to preserve application function. A cloud readiness assessment at this stage surfaces licensing conflicts, unsupported OS versions, and hardware-bound workloads before replication begins.
-
Replication. Agent-based or agentless replication software continuously copies disk blocks from the source environment to a staging area in the target cloud region. AWS MGN (Application Migration Service) and Azure Site Recovery are the two dominant native replication engines for this phase. Replication runs in the background with minimal production impact, typically achieving replication lag under 1 second for most block-storage workloads.
-
Test cutover. A non-destructive test instance launches in the cloud using replicated data. Teams validate connectivity, application startup, authentication paths, and basic transaction processing without interrupting production traffic. The cloud migration testing strategies applied at this stage include smoke tests, regression suites, and latency benchmarks comparing on-premises baseline performance against cloud target metrics.
-
Production cutover. DNS records, load balancer targets, or network routes redirect live traffic to the cloud instance. The source environment typically remains available in a read-only or standby state for a defined rollback window — commonly 24 to 72 hours — before decommissioning.
The Microsoft Cloud Adoption Framework (CAF), maintained at learn.microsoft.com, maps this sequence to its Migrate methodology and identifies the rehost pattern as the lowest-complexity migration motion within its five-phase model.
Common scenarios
Lift and shift is the operationally correct choice in four recurring scenarios:
Data center exit under deadline. When a data center lease expires or a hardware refresh would otherwise be required, rehosting allows infrastructure to move before a contractual or capital deadline without requiring application development resources. This is the most frequent driver of large-scale lift and shift programs in enterprise settings.
Disaster recovery and business continuity. Organizations with on-premises disaster recovery (DR) infrastructure use lift and shift to replicate production workloads into a cloud DR environment at lower cost than maintaining a secondary physical site. The disaster recovery cloud migration use case is well-established because rehosting preserves the identical application stack that DR runbooks were written to recover.
Legacy applications with no active development. Applications that are no longer under active development — line-of-business tools from the early 2000s, acquired-company systems still running Windows Server 2012, or regulatory-archive workloads — cannot be refactored because no team has the source code or institutional knowledge to modify them safely. Rehosting is the only viable cloud path for legacy system cloud migration in this category.
Short-term compliance scope reduction. Organizations that need to remove on-premises infrastructure from a compliance boundary (such as PCI DSS cardholder data environment scope) before a formal re-architecture is complete use lift and shift as a temporary measure that narrows the physical audit scope.
Rehosting does not deliver the performance improvements, cost reductions, or scalability gains associated with cloud-native architectures. A VM running on an IaaS instance incurs the same licensing costs, has the same single-instance failure profile, and cannot leverage managed auto-scaling unless additional engineering work follows the migration.
Decision boundaries
The decision to rehost rather than refactor or replatform maps to four measurable criteria:
| Criterion | Rehost (Lift and Shift) | Replatform / Refactor |
|---|---|---|
| Application modification budget | Zero to minimal | Moderate to high |
| Migration timeline | Weeks to 3 months | 3 months to 2+ years |
| Development team availability | Not required | Required |
| Expected cloud optimization | Low | High |
Where lift and shift fails: Applications with architecture patterns that are fundamentally incompatible with shared cloud infrastructure — including those relying on hardware dongles, specialized kernel modules, or multicast networking — cannot be rehosted without significant remediation that negates the speed advantage. Similarly, workloads that will immediately require cloud cost management post-migration intervention to control spend are poor rehost candidates; an oversized VM migrated as-is continues to generate oversized costs in the cloud.
Comparison with replatforming: Replatforming modifies one layer of the stack — typically swapping a self-managed database engine for a managed service like Amazon RDS or Azure SQL Database — while leaving application code intact. This adds 20–40% more migration effort (by time estimate, not a cited statistic) but delivers ongoing operational savings by eliminating database administration overhead. Teams should evaluate replatforming when the workload has a clear managed-service equivalent and the database team has capacity during the migration window. The replatforming vs. refactoring comparison covers those boundaries in full.
Governance checkpoint: The cloud migration governance frameworks that apply during a rehost decision should include a documented rationale for why refactoring was evaluated and rejected. Without that record, organizations risk repeating the lift and shift pattern indefinitely, accumulating cloud-hosted technical debt that is structurally identical to on-premises technical debt — just billed by the hour.
The workload prioritization step that precedes any migration wave is where rehost candidates are formally separated from refactor candidates. The workload prioritization cloud migration process assigns each application to a migration pattern based on business criticality, technical complexity, and the availability of engineering capacity — making the rehost/refactor boundary an explicit, documented decision rather than a default.
References
- NIST SP 800-145: The NIST Definition of Cloud Computing — National Institute of Standards and Technology
- Microsoft Cloud Adoption Framework for Azure — Microsoft Docs
- AWS Cloud Migration & Modernization — Amazon Web Services
- AWS Application Migration Service (MGN) Documentation — Amazon Web Services
- Azure Migrate Documentation — Microsoft Docs
- Azure Site Recovery Documentation — Microsoft Docs
- ISACA COBIT 2019 Framework — ISACA (referenced for governance decision context)