Lift and shift is a migration approach in which an application and its data are moved from one environment to another, most often from an on-premises data center to a public or private cloud, with few or no changes to the application itself. The servers, usually as virtual machines, are copied or rebuilt on the new platform and keep running much as they did before. It is the fastest and least disruptive way to move, and also the one that captures the fewest of the cloud’s benefits on day one.
At a glance
- Also called rehosting: the application’s code and design stay largely the same, and the main change is the infrastructure underneath.
- Commonly used when a deadline drives the move, such as a data center lease ending or hardware going out of support.
- Usually moves servers onto infrastructure as a service (IaaS) or a virtualized private cloud.
- Fast and lower-risk to execute, but costs and performance can disappoint if servers are moved without being resized.
- Often the first step of a longer plan, with selected applications modernized after the move.
What problem it solves
Many organizations want out of their own server rooms or data centers but cannot afford to redesign every application first. Rewriting software for the cloud takes developers, testing and time, and some applications are vendor products the organization cannot change at all. Meanwhile, a lease is ending, hardware support contracts are expiring, or a merger requires consolidating two environments by a fixed date.
Lift and shift separates the move from the redesign. It gets workloads onto new infrastructure quickly, with the least change to how users and applications behave, so the organization can stop investing in old facilities and hardware. Modernization can then be done application by application, on a schedule driven by business value rather than by the deadline.
How it works
Discovery and assessment. The team inventories servers, applications, data volumes and the dependencies between them, often with discovery tools that watch network traffic. Applications that talk to each other heavily are usually moved together to avoid slow connections across environments.
Choosing the target. Each server is matched to a target size and type on the new platform. This is where many lift-and-shift projects go wrong: copying the old server’s size, even though it was sized for peak load on hardware bought years ago, produces an oversized and expensive cloud instance.
Replication and cutover. Migration tools replicate server disks to the target platform while the original keeps running. At cutover, the source is stopped, a final sync is taken, and the copy is started and tested. Network addresses, DNS records and firewall rules are updated so users reach the new location.
Post-move tuning. After the move, teams typically resize instances based on real usage, schedule non-production servers to shut down out of hours and buy commitment discounts for steady workloads. This rightsizing step is often where the business case is won or lost.
Lift and shift is one of several common strategies. Replatforming makes targeted changes during the move, such as switching to a managed database. Refactoring redesigns the application to be cloud-native. Other options include replacing an application with SaaS, retiring it or leaving it where it is.
To weigh where moved workloads should run, see our public cloud and private cloud pages.
When it matters for buyers
- Facing a hard deadline. Data center exits, end-of-support hardware and post-merger consolidation are common triggers.
- Building the business case. Compare costs after rightsizing, not server-for-server; a lift and shift that skips tuning often costs more than expected and can contribute to later cloud repatriation.
- Licensing reviews. Some software licenses are tied to physical cores or specific hosts and may cost more, or be restricted, in a public cloud. Check before you move.
- Choosing a migration partner. Partners differ in tooling, testing and whether they help with post-move optimization.
- Planning what comes next. Rehosting can carry over technology debt; decide which applications will be modernized and when.
Questions to ask vendors
- How will you size each server on the new platform, and will you use measured utilization rather than current specifications?
- Which applications do you recommend rehosting, and which should be replatformed, replaced or left in place?
- How do you map dependencies so that applications that talk to each other move together?
- What downtime should we expect at cutover for each application, and what is the rollback plan?
- Have you checked our software licenses for restrictions or extra costs in the target environment?
- What does the projected monthly cost look like after rightsizing and commitment discounts?
- Do you help optimize cost and performance after the move, and for how long?
How it differs from cloud migration
Cloud migration is the whole process of moving applications, data and workloads to cloud infrastructure, from assessment and planning through cutover and optimization. Lift and shift is one strategy within it: the one that moves applications with the least change. A single cloud migration program often uses several strategies at once, rehosting some applications, replatforming or refactoring others, and replacing some with SaaS. When someone says “we’re doing a lift and shift,” they are describing how a set of applications will move, not the full scope of the migration.