Lift-and-Shift (Rehosting): Definition
Lift-and-shift, also called rehosting, is moving an application from its current infrastructure to new infrastructure, usually the cloud, with little or no change to its code or architecture. It is the fastest of the modernization options and the least transformative: the application runs in a new place but is essentially the same application.
Lift-and-shift is the most literal of the modernization moves. You take an application running in one place, typically an on-premises data center, and move it, more or less unchanged, to another, usually a cloud provider. The formal name is rehosting. The application lands in a new home but is recognizably the same application.
What it is
The defining feature is minimal change to the application itself. The operating system, runtime, and code travel together. What changes is the infrastructure underneath. Virtual machines are recreated in the cloud, storage and networking are remapped, and the application is pointed at its new surroundings. Because so little of the application is touched, rehosting is fast and comparatively low-risk to execute.
Why it matters
Lift-and-shift exists because the trigger is often a deadline, not a desire for new features. A data center lease is ending, hardware is failing, a licensing model is changing, or a runtime is reaching end of life. In those cases the immediate need is to get off the old footing quickly, and relocating the application as-is is the most direct way to do it.
Lift-and-shift vs the other modernization moves
Rehosting is one point on a spectrum, and understanding the definition means understanding what sits on either side of it. The moves run from leaving a system alone to rewriting it from scratch, and the right one depends on why you are moving and what you need afterward.
| Move | What changes | Relative effort | Choose it when |
|---|---|---|---|
| Retain / Retire | Nothing, or the app is switched off | Minimal | It is stable and worth leaving, or redundant and worth killing |
| Rehost (lift-and-shift) | Infrastructure only, code untouched | Low, fast | You need off the old footing quickly and the app can wait |
| Replatform | Minor changes to fit a managed runtime | Low to moderate | A small tweak gets you a managed service or cuts ops toil |
| Repurchase | Swap the custom app for a SaaS product | Varies | A packaged product covers the need better than your build |
| Refactor / Re-architect | Internal structure or design reshaped | Moderate to high | The app is worth keeping but its structure blocks change |
| Rebuild | Rewritten from scratch | Highest | Nothing is worth preserving, or requirements fully changed |
Lift-and-shift is deliberately near the low-effort end. That is its appeal and its ceiling. A fuller treatment of how to choose per slice lives in Rehost, Replatform, Refactor or Rebuild.
When it is the right call, and when it is not
The definition only becomes useful when you can tell whether it applies to your situation. Rehosting is the right move when:
- A data center lease or hardware refresh forces a move on a fixed date.
- A runtime or operating system is reaching end of life and you need a supported footing fast.
- The application is stable and is not the thing holding the business back.
- You want a safer position to modernize from later, rather than instead of modernizing.
Look past it when:
- The application itself is the bottleneck. Relocating it changes nothing about that.
- You are moving specifically for cloud-native scaling or managed services. That needs at least replatforming.
- The app was never designed for cloud economics and would run always-on and over-provisioned. The bill can rise, not fall.
- Success is being measured by whether the next change is cheaper and safer. Rehosting alone does not move that number.
The cloud cost reality
The most common surprise with lift-and-shift is the bill. A rehosted application usually runs as the same virtual machines it ran on-premises, sized the way they were always sized, running around the clock. The cloud charges for that directly. Without autoscaling, managed services, or right-sizing, a lift-and-shift can cost more than the data center it left. The savings people expect from “the cloud” come from cloud-native patterns the application does not yet use.
This is why rehosting is best understood as a relocation with a cost profile to manage, not an automatic saving. Teams that treat it as step one, then right-size and adopt managed services slice by slice, capture the savings the raw move does not. Teams that treat the shift as the finish line often spend the next budget cycle wondering why the cloud got more expensive, not less.
How it relates to modernization
Rehosting is the least invasive point on the modernization spectrum, the first of the “Rs,” ahead of replatforming, refactoring, re-architecting, and rebuilding. It is genuinely useful as a first step: get off the burning platform, then modernize from a safer position. The honest caveat is that it changes location, not character. A monolith you lift and shift is still a monolith, and one not designed for cloud economics can cost more to run there. Lift-and-shift moves technical debt. It does not pay it down.
Common confusion
“We moved to the cloud” is often described as modernization when what happened was rehosting. The cloud bill is new, but the application’s ability to change is not. Real modernization is measured by whether the next change is cheaper and safer, and on that test, lift-and-shift alone usually scores zero. That is not a criticism of the move. It is a reason to be clear about what it does and does not buy. Choosing the right move per slice is the subject of the Rs of modernization.
Frequently asked questions
- Is lift-and-shift the same as rehosting?
- Yes. Rehosting is the formal term in the "Rs" of modernization, and lift-and-shift is the common name for the same move, relocating an application to new infrastructure without rewriting it.
- When is lift-and-shift the right choice?
- When the priority is exiting a data center, hitting a hardware or licensing deadline, or reducing operational risk quickly, and the application itself does not yet need to change. It buys time and a new runtime, not new capability. Sometimes that is exactly the right trade.
- Does lift-and-shift save money?
- Not automatically, and sometimes the opposite. A rehosted application usually runs as the same always-on virtual machines it used on-premises, sized the same way, so without right-sizing, autoscaling, or managed services the cloud can bill more than the data center did. The savings people associate with the cloud come from cloud-native patterns a lift-and-shift does not adopt. Treated as step one and followed by optimization, it can save money. Treated as the finish line, it often does not.
- What is the difference between lift-and-shift and replatforming?
- Lift-and-shift moves the application with no meaningful change to its code. Replatforming makes small, targeted changes so the application can use a managed service, such as swapping a self-managed database for a managed one, without a full rewrite. Rehosting is faster and lower-risk. Replatforming does a little more work up front to unlock a little more benefit. Both stop well short of refactoring or re-architecting.
- What are the limits of lift-and-shift?
- It moves the application without fixing it. A monolith rehosted to the cloud is still a monolith, and can cost more to run there than on-prem if it was never designed for cloud economics. Lift-and-shift relocates technical debt. It does not pay it down.