Cloud Lift and Shift: When It Makes Sense and How to Do It Right

Lift and shift gets a bad reputation in cloud-native circles. But for many organizations, it's exactly the right first step toward cloud adoption. Here's when to use it—and how to execute it properly.

What Is Lift and Shift?

Lift and shift (also called "rehosting") means moving your applications and data to the cloud with minimal changes. You're essentially taking what runs in your data center and running it on cloud infrastructure instead.

This is in contrast to:

• Replatforming: Making some optimizations during migration (e.g., moving to managed databases)
• Refactoring: Rebuilding applications to be cloud-native (containers, serverless, etc.)
• Replacing: Switching to SaaS alternatives entirely

When Lift and Shift Makes Sense

1. Data Center Exit Deadline

If your lease is ending, your hardware is aging out, or you need to vacate a facility, lift and shift is often the only option that fits the timeline. You can always optimize later—the priority is getting out.

2. Legacy Applications With Limited Documentation

Some applications are black boxes. The original developers are gone, documentation is sparse, and nobody wants to touch the code. Lift and shift lets you move without understanding every detail of how it works.

3. Stable Workloads That Don't Need Optimization

Not everything needs to be cloud-native. If an application is stable, performs well, and doesn't need to scale dynamically, there's little benefit to rebuilding it. Move it, run it, focus your engineering effort elsewhere.

4. First Step in a Longer Journey

Many organizations use lift and shift as Phase 1 of a multi-phase cloud strategy. Get everything to the cloud first, then modernize incrementally based on business priority.

When Lift and Shift Is the Wrong Choice

• Applications that need to scale: Lifting a monolith to the cloud doesn't make it scalable.
• Workloads with extreme performance requirements: Cloud VMs may not match bare-metal performance for all use cases.
• Applications with heavy licensing costs: Some software licenses charge per-core, and cloud can be expensive at scale.
• When you're trying to cut costs immediately: Lift and shift often increases costs short-term. Optimization comes later.

The 6 Rs of Cloud Migration

AWS popularized this framework for categorizing migration strategies. Understanding where lift and shift fits helps you make better decisions:

Strategy	Description	Effort	Cloud Benefit
Rehost (Lift & Shift)	Move as-is to cloud VMs	Low	Low-Medium
Replatform	Make minor optimizations	Medium	Medium
Refactor	Rebuild cloud-native	High	High
Repurchase	Move to SaaS	Medium	High
Retire	Decommission	Low	N/A
Retain	Keep on-premises	None	None

How to Execute a Lift and Shift Migration

Step 1: Inventory and Assessment

Document everything that's moving:

• Servers (physical and virtual)
• Operating systems and versions
• Applications and dependencies
• Storage requirements
• Network configuration
• Current resource utilization

Step 2: Right-Size Target Infrastructure

Use utilization data to select appropriate cloud instance types. Most on-premises servers are over-provisioned—don't just match specs 1:1.

We typically see 30-40% cost savings just from right-sizing during migration. The old "better safe than sorry" server provisioning doesn't apply in the cloud where you can scale up in minutes.

Step 3: Network Planning

Design your cloud network to mirror critical on-premises connectivity:

• VPC/VNet structure
• Subnet design
• Security groups and firewall rules
• VPN or Direct Connect for hybrid connectivity
• DNS strategy

Step 4: Migration Execution

Use cloud-native migration tools when possible:

• AWS: Application Migration Service (MGN), Database Migration Service (DMS)
• Azure: Azure Migrate, Database Migration Service
• GCP: Migrate for Compute Engine, Database Migration Service

These tools handle the heavy lifting of replicating VMs and databases with minimal downtime.

Step 5: Testing and Validation

Before cutover:

• Run applications in the cloud environment
• Test all integrations and dependencies
• Validate performance against baselines
• Confirm backup and recovery procedures
• Test rollback procedures

Step 6: Cutover and Optimization

After successful migration:

• Update DNS and routing
• Monitor closely for 1-2 weeks
• Decommission source systems (after validation period)
• Implement cloud cost management tools
• Plan Phase 2 optimization

Common Mistakes to Avoid

• Ignoring licensing: Some software licenses don't allow cloud deployment or charge differently. Check before you move.
• Forgetting about latency: Applications that communicated over a local network may struggle with cloud latency. Test thoroughly.
• No cost governance: Cloud costs can spiral quickly. Implement tagging, budgets, and alerts from day one.
• Skipping security review: Your on-premises security model doesn't translate directly. Review IAM, network security, and encryption.

What Comes After Lift and Shift?

Once you're in the cloud, you can optimize incrementally:

• Quick wins: Move to managed databases, implement auto-scaling, use reserved instances for predictable workloads.
• Medium-term: Containerize applications, implement CI/CD, improve monitoring and observability.
• Long-term: Refactor to microservices, adopt serverless where appropriate, implement infrastructure as code.

The key is to not let perfect be the enemy of good. Lift and shift gets you to the cloud, where you have options. Sitting in an aging data center doesn't.