Every architect I respect has, at some point, recommended lift and shift. And every one of them has done so slightly apologetically — as if it were the dirty option, the path of compromise, the move you make because you could not be bothered to do it properly. I have seen it myself. And I want to challenge that assumption. Because looking back across a decade of cloud migrations, the honest verdict is that lift-and-shift, done rigorously, has produced more successful outcomes than the well-intentioned re-architecture initiatives that consistently stall, run over budget, or quietly slip into the maintenance backlog never to emerge.
This is the unfashionable thing to say. The cloud-native discourse has spent fifteen years selling a simple message: if you migrate without re-architecting, you are just moving your problems to somebody else's infrastructure. The message has merit in narrow contexts. It has been catastrophic when applied as a general prescription, because the prescription does not survive contact with mid-market reality. Most organisations are not Netflix. Most workloads are not the differentiator. Most teams do not have the bandwidth to re-architect their entire estate in flight while keeping the business running. And the orthodoxy that says they should has paid for itself in delayed migrations, blown budgets, and platforms that ended up with the worst of both worlds — neither properly modernised nor calmly operational.
What actually happens when you try to re-architect everything
The pattern is so consistent across organisations it is almost predictable. The pattern often begins with ambition. Architecture diagrams show the target state, cloud-native principles are easy to describe, and the destination looks cleaner than the estate people are trying to leave behind. The first wave goes well, because the first wave is always a few green-field services that were already cloud-shaped. Confidence rises. The second wave hits the harder workloads — the ones with legacy dependencies, the ones the business actually runs on — and the programme slows. Not stops; slows. Estimates get revised, scope gets clarified, the "we will modernise this in-flight" assumption quietly becomes "we will modernise this in a follow-up phase." A year passes.
By month eighteen the programme is in a recognisable shape. Some workloads have been beautifully re-architected and are running well. Some have been lifted and shifted under pressure as the deadline loomed and the team realised re-architecting them was not feasible within the timeline. Some are still in the datacenter, awaiting their elegant target state. The CIO is being asked uncomfortable questions about cost and progress. The cloud bill is high because the lifted workloads were not optimised. The team is exhausted because they are carrying three architectures simultaneously — legacy, lifted, and re-architected — and the operational model for all three.
Compare that with the path on the green line. A rigorous lift-and-shift makes steady visible progress from month one. Around month fourteen, the migration is complete — workloads are across, the datacenter contract can be wound down, the team has a single operational model to learn instead of three, and the platform is now in a position where it can be improved incrementally with attention focused on the workloads that actually deserve it. The slope flattens because improvement happens after the migration, not during it. The cumulative progress at month twenty-four is higher, not because the destination was more ambitious, but because the destination was reachable.
The argument for re-architecting in flight assumes that the two activities — moving and modernising — combine well. They do not. They compete. Every team trying to do both is choosing, in every meeting, whether this hour goes to keeping the migration on schedule or to making the target state more elegant. The decision is almost always made under pressure, by the person available, with imperfect information. The combined activity is not the sum of two good things; it is two good things made worse by being attempted together.
What "rigorous" lift-and-shift actually means
I want to be precise about the word "rigorous," because the case I am making is not for sloppy lift-and-shift, and the cloud-native critique is partly a response to sloppy lift-and-shifts that genuinely deserved it. Rigorous lift-and-shift means specific things. It means the landing zone was designed as architecture, not assembled from a checklist. It means identity was sequenced first and properly. It means the network topology was thought through, not replicated by default from the datacenter. It means the operational model — observability, security baselines, change management — was redesigned for the new environment rather than carried over. It means each lifted workload was put through enough scrutiny to confirm it was a candidate for lift, not a candidate that was being defaulted to lift because nobody had time to consider an alternative.
None of that is re-architecting the workload. All of it is rigour around the move. And the result is a platform that is genuinely better than what came before — calmer to operate, easier to govern, less dependent on the institutional memory of three engineers who happen to know how the datacenter was wired. A lifted workload running in a well-designed landing zone with proper identity and observability is not the same thing as the legacy workload it used to be. It looks the same on the inside; the world around it has improved.
The cloud-native purists were right about one thing: a lift-and-shift into a chaotic landing zone is not progress. They were wrong to conclude the answer was to re-architect the workloads. The answer was to fix the landing zone.
Which workloads actually need re-architecting
I am not arguing against re-architecting. I am arguing against re-architecting by default. Some workloads genuinely benefit from being re-shaped for the cloud — there are real cases where lift-and-shift would be the wrong answer — and a good migration programme can identify them up front rather than discovering them mid-flight. The decision is not difficult once you give yourself permission to ask it explicitly.
Plot every workload against two axes. The vertical is how business-critical the workload is. The horizontal is how fast it changes — how often it gets new features, how much competitive advantage depends on its evolution. The right answer for each workload lives in one of four boxes, and only one of those four is "re-architect."
The top-right quadrant — the workloads that are both business-critical and fast-moving — is where re-architecting earns its keep. These are the platforms where the shape of the system directly enables what the business can do, where the cloud-native pattern gives you something you genuinely could not have on-premise. Customer-facing platforms in fast-moving sectors. Data and analytics estates when the business is using them as a differentiator. Trading systems. These are real cases, and rigour about them is worth the investment.
The other three quadrants are the source of most of the failed re-architecture projects I have seen. Stable core systems — ERP, finance, the legacy line-of-business platforms that have been doing their job for fifteen years — should be lifted first, not re-architected. They are not going to deliver competitive advantage by being more cloud-native; they are going to deliver competitive advantage by remaining boring and operating calmly somewhere cheaper to run. Utility workloads in the bottom-left should be lifted, then improved opportunistically as cost or operational concerns surface. And peripheral systems in the bottom-right rarely deserve re-platforming at all; the honest answer is usually SaaS replacement or sunset.
The cloud-native default treats every workload as if it sat in the top-right quadrant. Most workloads do not. Many architects know this and apply it implicitly when nobody is looking; the framework above just makes the implicit explicit, and gives a technology team something to defend when visible progress is mistaken for better architecture.
The phrase that does the most damage
"We should not just lift and shift" is the most expensive sentence in mid-market cloud transformation. Spoken in a leadership meeting, written in a strategy deck, repeated in strategy reviews and planning conversations — it sounds rigorous, but it commits the programme to a posture that is not appropriate for most of the workloads in scope. It implies that lifting is the lazy answer when, for the bulk of any real estate, lifting is the correct answer.
A better sentence, when the situation calls for it, is: "We will lift this rigorously, into a foundation good enough to improve from later." That sentence honours the discipline lift-and-shift actually requires while refusing the false dichotomy between modernisation and migration. It sequences the work properly — migrate first, modernise from a calm base — and it gives the team permission to be selective about where the real re-architecting effort goes.
The case the cloud-native purists made was never wrong in its narrowest form: a chaotic lift into a poorly designed landing zone, with no rigour around identity or operations, is not progress. They were right about that, and the industry needed to hear it. What went wrong was the generalisation. The fix for sloppy lift-and-shift is not to re-architect the workloads. It is to lift them rigorously, into a foundation that deserves to be lifted into. That is a different conclusion, and it is the conclusion that holds up across the mid-market migration pattern — where the more disciplined approach succeeds quietly while the more ambitious one accumulates visible problems.
Done is a feature. Re-architecting in production is not the same as re-architecting in plan. The architect who recommends lift and shift, when that is the right answer, is not taking the easy path. They are resisting the social pressure to perform modernisation theatre — and that is a harder thing to do in a room that wants to hear something more ambitious.