Lift and shift gets a bad name for the wrong reasons
Moving as-is is a poor destination and frequently an excellent first move. The failure is stopping there and calling it a migration.
Lift and shift has become shorthand for doing cloud badly: virtual machines relocated to rented infrastructure, none of the benefits, all of the bill. The criticism is fair as far as it goes, and it has produced an overcorrection that costs organisations more than the practice it was meant to discourage.
The overcorrection is the belief that migration must be accompanied by re-architecture — that moving a system is only legitimate if it is also modernised. This turns a two-quarter programme into a three-year one, and three-year programmes have a habit of being cancelled in year two.
What moving as-is actually buys
It gets you out of the data centre contract, which is often the actual deadline. It removes a hardware refresh cycle from your capital plan. Most usefully, it puts the workload somewhere you can iterate: once a system is on cloud infrastructure, improving it becomes a series of small, independently valuable changes rather than a single large project requiring its own business case.
That last point is the strongest argument. Modernising in place, in a data centre, means every improvement competes with feature work for the same approval. Modernising after a move means each step is incremental and reversible.
Where it genuinely fails
- Stopping at the move. Lift and shift is a first move, not a strategy, and the benefits only arrive if the second phase is funded before the first is celebrated.
- Moving systems that should have been retired. Migration is an excellent moment to audit what still earns its keep, and that audit is rarely done.
- Carrying across operational habits — manual provisioning, snowflake servers, quarterly release windows — which reproduce the old constraints on new infrastructure.
- Ignoring the cost model. On-premises economics reward idle capacity; cloud economics punish it, and a workload moved without resizing will surprise the finance team.
- No plan for data gravity. The compute moves easily; the data and everything that reads it does not.
The sequencing that works
Move first, then improve, with the improvement funded at the same time as the move rather than promised after it. Prioritise the systems where the second phase has clear value, and be willing to leave stable, low-change workloads exactly as they are indefinitely.
Not everything deserves to be modernised. Some systems simply need to keep working somewhere cheaper, and recognising that is a discipline rather than a compromise.
Let's build the system your business will run on next.
Tell us where it hurts. We'll bring the architects, engineers, and delivery model to fix it — and scale it.