Lift and Shift Cloud Migration: What It Is, When to Use It, and How It Works
“`html
Lift and shift cloud migration moves your applications, data, and operating system from on-premises servers to the cloud without redesigning or recoding anything. You’ll also hear this called “rehosting.” It’s the fastest path to cloud infrastructure, and it’s the right choice for businesses facing hard deadlines or working with stable applications that don’t need a structural overhaul before moving.
Key Takeaways
- Lift and shift moves applications to the cloud with zero changes to application architecture.
- Cloud migration can reduce infrastructure costs by an average of 31%, per IDC and AWS research.
- Lift and shift is also called “rehosting” and sits within the broader 7 Rs migration framework.
- AWS, Azure, and IBM Cloud each offer dedicated tools to automate and support rehosting.
- Migrating an inefficient app as-is can replicate on-premises waste inside the cloud.
What Is Lift and Shift Cloud Migration?
Lift and shift cloud migration moves an application, its data, and its operating system configuration from on-premises infrastructure to a cloud environment without changing the application itself. The application runs in the cloud exactly as it ran on your physical servers.
The terms “lift and shift” and “rehosting” are used interchangeably across the industry. Both describe the same thing: picking up what you have and placing it in a cloud-hosted virtual machine, which is a software-based server that behaves like a physical one. The hosting environment changes. The application does not.
This separates lift and shift from two other common migration strategies. Replatforming moves an application to the cloud while making minor modifications, such as switching to a managed database service. Refactoring rebuilds the application from the ground up to take full advantage of cloud-native features like auto-scaling and serverless computing. Lift and shift does neither. It prioritizes speed and minimal disruption over long-term optimization.
What Is the Lift and Shift Cloud Migration Approach and How Does It Differ from Other Strategies?
The lift and shift approach keeps your application architecture completely intact. Only the physical hardware underneath it changes. Your application binaries, operating system configuration, databases, and file storage all move to virtual equivalents hosted in the cloud.
The trade-off is real. Applications migrated this way don’t automatically become cloud-efficient. Cloud billing is based on consumption, and if your on-premises workloads were oversized or poorly optimized, you’ll carry those inefficiencies into the cloud.
| Strategy | Definition | Time to Migrate | Best For |
|---|---|---|---|
| Rehost (Lift and Shift) | Move app to cloud with no changes | Fast (weeks) | Deadline-driven migrations, stable workloads |
| Replatform | Move with minor cloud optimizations | Moderate (months) | Apps that benefit from managed services |
| Refactor | Rebuild app using cloud-native architecture | Slow (6+ months) | Apps needing full cloud-native capabilities |
| Retire | Decommission the app entirely | Immediate | Legacy apps with no business value |
How Does Lift and Shift Cloud Migration Work as a Step-by-Step Process?
A lift and shift migration follows five structured phases. Skipping the first two is where most migration problems originate.
Step 1: Discovery and Inventory
Before migrating anything, audit every application, its dependencies, and its data stores. You need to know what talks to what. A legacy ERP system, for instance, may connect to file servers, email systems, and databases that all need to move together, or the application breaks. Tools like AWS Migration Hub help map these dependencies automatically.
Step 2: Assessment and Prioritization
Not every workload is a good lift and shift candidate. Assess each application against the criteria in the section below. Prioritize applications that are stable and well-understood. Flag those with complex hardware dependencies or tight performance requirements for a separate strategy review.
Step 3: Environment Setup
Provision the cloud infrastructure that mirrors your on-premises setup. This means configuring virtual machines (VMs), storage volumes, and networking settings that match what your application expects. Get this wrong and your application will behave unpredictably after cutover.
Step 4: Data Migration
Transfer databases and file storage to the cloud environment using dedicated migration tools. AWS Database Migration Service (DMS) handles this for AWS-hosted migrations, replicating data continuously so you can cut over with minimal downtime.
Step 5: Cutover and Validation
Redirect traffic from your on-premises servers to the cloud-hosted version. Run validation checks to confirm performance and functionality before decommissioning physical servers. Keep on-premises servers live for a short rollback window until you’re confident the cloud environment is stable.
How Does Lift and Shift Cloud Migration Work on AWS?
AWS calls lift and shift “rehosting” and provides two dedicated services to support it. AWS Application Migration Service (AWS MGN) automates the replication of your on-premises servers to AWS without requiring any application changes. It continuously syncs your source servers to AWS in the background, then cuts over with minimal downtime when you’re ready.
AWS Database Migration Service (DMS) handles database transfers, supporting migrations between different database engines if needed. Once migrated, your workloads run on Amazon EC2 instances, which are virtual servers you can size and configure to match your original on-premises specs.
Research published by IDC and Amazon Web Services found that organizations migrating to the cloud saw an average 31% reduction in infrastructure costs and a 62% boost in IT staff productivity (IDC and AWS, 2020). These gains apply even to rehosted workloads, because eliminating on-premises hardware maintenance frees your IT team from routine physical infrastructure tasks.
Azure offers Azure Migrate for equivalent rehosting functionality, and IBM Cloud provides IBM Cloud Migration Services for businesses not committed to AWS.
When Should Your Business Use Lift and Shift, and When Should You Avoid It?
Lift and shift is the right choice when speed matters more than optimization. Use it when your business faces a hard deadline, such as a data center lease expiration or hardware reaching end-of-life. Use it when your applications are stable, well-understood, and don’t require cloud-native features to function.
Lift and shift also makes sense as a deliberate Phase 1 strategy. You move workloads to the cloud first, stop the clock on aging hardware costs, and then modernize applications at a controlled pace once they’re running in the cloud.
Avoid lift and shift when your applications are tightly coupled to on-premises hardware in ways that won’t translate to virtual environments. Physical GPU dependencies, proprietary storage appliances, and applications requiring bare-metal performance are common examples. If your IT team isn’t sure whether your hardware qualifies, that uncertainty is a signal to assess before committing to rehosting.
Cost reduction is a separate concern. If your primary goal is to cut cloud spend significantly, lift and shift may disappoint. An on-premises workload that’s already inefficient carries the same inefficiency into the cloud, often at a higher per-unit cost than a properly optimized workload would.
What Are the Benefits and Limitations of Lift and Shift Migration?
Lift and shift delivers immediate, concrete benefits. Your migration timeline is measured in weeks rather than months or years. You avoid the risk of application failure that comes with large-scale code changes. And you gain immediate access to cloud infrastructure benefits like scalability and built-in disaster recovery, which on-premises hardware can’t match at the same cost point.
The limitations are concrete. Migrated applications don’t automatically access cloud-native capabilities like auto-scaling, managed databases, or serverless functions. Cost management requires attention post-migration. An oversized VM costs more than necessary, and cloud bills reflect actual consumption in a way that a fixed data center lease does not. Right-sizing your instances after migration is a standard follow-up step, not an optional one.
Lift and shift is Phase 1, not the final destination. Most businesses follow rehosting with selective replatforming or refactoring for the applications that will benefit most from cloud-native modernization.
Cloud Migration Strategy Fit: Where Lift and Shift Belongs
Lift and shift sits within the 7 Rs framework, a widely used model for categorizing cloud migration strategies. The seven options are: Rehost, Replatform, Repurchase, Refactor, Relocate, Retain, and Retire. Lift and shift is “Rehost,” the most direct path to the cloud with the least application change.
Your application portfolio will likely include candidates for several of these strategies. The goal of the assessment phase is to match each application to the right approach, not to force everything through a single migration path.
Frequently Asked Questions
What is the difference between lift and shift and replatforming?
Lift and shift moves an application to the cloud with zero changes to its architecture or code. Replatforming makes minor modifications during migration, such as switching from a self-managed database to a cloud-managed database service like Amazon RDS. Replatforming takes more time and planning but can reduce operational overhead and costs after migration.
Is lift and shift cheaper than refactoring?
Lift and shift has a lower upfront cost than refactoring because it requires no development work. Refactoring, which rebuilds applications using cloud-native architecture, requires significant engineering time and investment. Lift and shift can result in higher ongoing cloud costs if workloads aren’t right-sized after migration, while refactored applications often run more efficiently at scale.
What AWS tools support lift and shift migration?
AWS supports lift and shift migrations through AWS Application Migration Service (AWS MGN), which automates server replication, and AWS Database Migration Service (DMS), which handles database transfers. AWS Migration Hub provides a central dashboard for tracking migration progress across multiple applications. Migrated workloads typically run on Amazon EC2 virtual machine instances.
How long does a lift and shift migration take?
Timelines vary based on the number of applications, data volume, and complexity of dependencies. A single, well-documented application can migrate in a matter of days using automated tools like AWS MGN. Larger portfolios with multiple interconnected systems typically take several weeks to migrate and validate, making lift and shift the fastest available migration strategy.
Can you modernize applications after a lift and shift migration?
Yes, and this is the most common approach. Lift and shift gets your workloads into the cloud quickly, stopping costs on aging hardware. From there, you can selectively replatform or refactor applications that will benefit most from cloud-native features, on a timeline that fits your budget and capacity. Most cloud migration roadmaps treat rehosting as Phase 1 of a longer modernization plan.
“`

