Lift and Shift: New Infrastructure, Same Logic
Move healthy code onto new infrastructure without rewriting it.
A lift and shift moves a working system onto new infrastructure without rewriting the business logic. The classic cases are a runtime upgrade, a move from on-prem to cloud, or a shift from virtual machines to containers. The code is fine; the ground it stands on is not.
When to use this play#
Reach for a lift and shift when both of these are true: there is a real infrastructure reason to move, and the code is healthy enough that you would leave it alone otherwise.
Good infrastructure reasons include:
- An end-of-life runtime, operating system, or host.
- Platform costs that are no longer sustainable.
- A compliance requirement that demands a different deployment surface.
The second condition matters as much as the first. If the code is sick, moving it just relocates the problem. Fix the code with a different sub-play, or fix it separately, but do not pretend a move is a cure.
How to run it#
1. Inventory the runtime. Catalog exactly what the system needs to run: language and framework versions, OS-level dependencies, drivers, environment configuration, scheduled jobs, and data stores. Surprises here are the ones that bite during cutover.
2. Build a parallel environment. Stand up the new platform alongside the old one. Do not modify the old environment to get there.
3. Adapt only what is needed to run. Touch configuration, drivers, and deploy scripts as required to get the same code running on the new platform. Adapt; do not improve. Every "while we are here" change is scope you did not sign up for.
4. Test load and behavior parity. Confirm the system behaves the same on the new platform and that it holds up under realistic load. Skipping load testing is how a clean migration becomes an outage.
5. Cut over with a tested rollback. Move production traffic only after you have a rollback you have actually exercised, not one you assume works.
6. Decommission the old platform. Once the new one is proven and stable, retire the old environment so you are not paying to run and secure two of everything.
Planning the data migration#
Data is usually the part that turns a tidy migration into a long night, so plan it as its own workstream from the start. A few decisions shape everything else:
- Cutover style. Decide early between a single bulk migration with a brief freeze, or an ongoing sync that keeps old and new in step until you flip. The right answer depends on how much downtime the business can tolerate.
- Validation. Define how you will prove the data arrived intact: row counts, checksums, or spot comparisons of records that exercise the tricky cases. Do this before cutover, not after a user reports a discrepancy.
- Rollback for data, not just code. A rollback that restores the old application but leaves the data behind is not a rollback. Make sure you can get both back to a consistent state together.
Rehearse the migration against a realistic copy of production before you do it for real, so the live run is a repeat of something that already worked rather than a first attempt under pressure.
Common traps#
- Scope creep into a rewrite. "While we are moving it, let us just..." is how a two-week lift and shift becomes a six-month rebuild. Hold the line: same logic, new infrastructure.
- Skipping load testing. Parity under no load tells you almost nothing about behavior under real traffic.
- Assuming the new platform fixes code-level problems. New infrastructure does not repair bad code; it just runs it somewhere else.
- Underestimating data migration. Moving the data is frequently the hardest part and the easiest to under-plan. Treat it as a first-class workstream.
Signals it's working#
- Behavior on the new platform matches the old one under realistic load.
- The diff is limited to configuration, drivers, and deploy scripts, with business logic untouched.
- The rollback path has been tested, not just written down.
How it ends#
A lift and shift ends when production runs on the new infrastructure, parity and load are verified, and the old platform is decommissioned. The business logic that came in is the business logic that goes out, now standing on ground that will last.