Lift-and-Shift vs Refactor

Part 2 showed that most of the 7 Rs are easy calls once you understand a workload. Retire the dead, retain the stable, repurchase the commodity. The decision that consumes the real debate sits in the middle of the spectrum: do you move this workload to the cloud as it is, or do you change how it’s built on the way? That is the lift-and-shift versus refactor question, and getting it wrong in either direction is expensive — over-refactor a workload that didn’t need it and you’ve spent a fortune relocating a non-problem; lift-and-shift a workload that needed re-architecting and you’ve paid cloud prices for an unchanged legacy system. This part is a framework for making that call per workload.

What each move actually does

Lift-and-shift (rehost) moves the workload to the cloud with minimal change — same code, same architecture, new infrastructure underneath. It optimizes for speed and low risk. You can move a workload in weeks, you touch none of its risky internals, and you get out of owned infrastructure fast.

Refactor (and its deeper sibling, re-architect) restructures the workload to fit the cloud — making it scale horizontally, fail gracefully, use managed services, and be changed safely — while preserving what it does. It optimizes for the value the cloud can actually deliver, at the cost of time and risk.

The two are not points on a quality scale where refactor is “better.” They are answers to different questions. Lift-and-shift answers how do we get out of here? Refactor answers how do we make this system good?

The trade, stated plainly

	Lift-and-shift	Refactor
Speed	Weeks per workload	Months per workload
Risk	Low — internals untouched	Higher — behavior must be preserved
What you get	A new location	An elastic, changeable system
What you don’t	Changeability, efficiency	Speed, low cost
Cloud cost after	Often flat or higher	Lower, if done right
Right when	You need out, the system is fine	The system blocks the business

The row that surprises people is cloud cost. A workload designed for fixed owned hardware frequently runs more expensively on metered cloud infrastructure: it’s sized for peak load around the clock, it can’t scale down when idle, and it ignores the cheaper managed services that make the cloud economical. Lift-and-shift the architecture, and you can lift-and-shift the inefficiency straight onto a metered bill. Flexera’s surveys consistently find organizations self-estimate that roughly 30% of cloud spend is wasted (Flexera, State of the Cloud) — and unrefactored rehosts are a recurring source.

How to decide: start from what the business needs

The decision does not start with the technology. It starts with a question about the business: what does this workload need to do that it can’t today?

• If the answer is nothing — the workload is stable, the business asks nothing new of it, and you’re moving only because the data center is closing — lift-and-shift. Re-architecting a system the business is content with is spending money to solve a problem you don’t have.
• If the answer is specific and real — it needs to handle 10× the load, integrate with systems it can’t reach, ship features it currently blocks, or shed a runtime that’s going end-of-life — and the current design is what prevents it, refactor. The cloud’s elasticity and managed services are exactly what unblock those needs, but only if the workload is built to use them.

The trap is letting the technology lead. “It’s old, so we should refactor it” is not a business case; plenty of old workloads are perfectly fine. “It’s urgent, so we’ll just lift it” ignores that some workloads are urgent because their design is failing, and relocating them solves nothing.

Signals that point each way

The business-need question is the anchor. These are the concrete signals that usually accompany each answer, so you can sanity-check a call against the shape of the workload in front of you. Read them as weight on the scale, not as a checklist that decides for you.

Signal in the workload	Usually points toward
Data center lease ending on a hard, immovable date	Lift-and-shift
Stable, no new business asks in the last two years	Lift-and-shift
Small, well-understood, low rate of change	Lift-and-shift or leave it alone
Must scale far beyond its current peak	Refactor
Blocks features the business keeps asking for	Refactor
Cannot integrate with systems it now has to reach	Refactor
Runtime, framework, or OS going end-of-life	Refactor
Cloud bill would balloon if moved unchanged	Refactor or replatform
Operationally painful to run, but the logic is fine	Replatform

When the signals split across columns, the workload is usually decomposable: part of it is stable and can be lifted, and a smaller part is what actually blocks the business and earns the refactor. That decomposition is the real work, and it is why the per-workload call often becomes a per-slice call.

The “lift now, refactor later” sequence

There is a legitimate middle path: rehost to stop the bleeding, then refactor the high-value workloads once you’re stable in the cloud. When a data center deadline is real and immovable, this is often the right sequence — get everything safely relocated first, then re-architect deliberately rather than under a clock.

The honest risk: later has a way of never arriving. The workload runs in the cloud unchanged for years, the cloud bill climbs, and the refactor stays a line on a roadmap nobody funds. If you choose this path, the discipline is to make the refactor a committed, funded plan with a date — not a vague intention. A rehost that is explicitly a first step is sound. A rehost that quietly becomes the finish line is the most common way “we moved to the cloud” ends in disappointment.

De-risking the refactor

The reason teams flinch at refactoring is that changing the inside of a working system means risking its behavior — and the behavior includes the undocumented edge cases nobody remembers. That fear is rational. It is also exactly what disciplined modernization is built to remove.

The structural answer is to refactor incrementally behind a strangler facade: change one slice at a time, run the new slice beside the legacy, and prove it produces identical results before it carries live load. Each slice clears a parity gate — functional parity, data integrity, performance — verified against the legacy’s actual behavior. A slice that fails the gate never reaches production; it goes back for fixing. This is the difference between a refactor that introduces silent regressions and one where, as we put it, surprises become tickets, not outages.

Don’t forget the move between them

Framing the choice as lift-and-shift versus refactor is useful for clarity, but it hides a third option that is often the best answer: replatform — the middle of the spectrum from Part 2. Replatforming keeps the application’s internal structure but makes targeted changes to capture real operating benefit: swap a self-managed database for a managed one, containerize the app, move files to object storage. It’s most of lift-and-shift’s speed and low risk, with a meaningful slice of refactor’s payoff.

Replatform is the right answer more often than the binary framing suggests, because many workloads don’t need their logic changed — they need their operations changed. The business isn’t asking the system to do anything new; it’s the running of the system that hurts. In that case, re-architecting the code is solving a problem you don’t have, while a pure lift leaves the operating pain in place. Replatform threads that gap. When you catch yourself arguing lift-versus-refactor and neither feels right, the workload is often telling you the answer is in the middle.

Three workloads, three different calls

The framework only earns its keep when you apply it to a real portfolio, where different workloads pull in different directions. Picture three, each asking a different question.

A nightly billing batch job. It runs, it reconciles, it has not needed a feature in years. The only reason it is moving at all is that the data center it lives in is closing. The business asks nothing new of it. This is a lift-and-shift. Re-architecting a job the business is content with, purely because you happen to be touching it, is spending money to solve a problem you do not have.

A customer-facing order API. It falls over at peak, it cannot be extended to serve the new product line the business has already sold, and its current design is the reason for both. Here the answer the workload is giving is loud and specific, so it earns a refactor, done incrementally behind a facade so the current API keeps serving traffic while the new one is proven slice by slice. Lifting it unchanged would relocate the exact ceiling that is already hurting the business.

A self-managed reporting database. Functionally it is fine, and nobody is asking it for new behavior. What hurts is the operations: constant patching, manual failover, a standby nobody trusts. The logic does not need to change, the running of it does. That is a replatform onto a managed database, capturing the operational relief without paying for a re-architecture the workload never asked for.

Same migration, same portfolio, three different correct answers. That is the point of deciding per workload rather than adopting one strategy for the whole estate.

Two honest admissions

Two honest admissions. First, lift-and-shift is not a lesser choice that “real” engineers look down on — for a stable workload under a deadline, it is precisely correct, and over-engineering a refactor it didn’t need is its own failure. Second, refactoring is not free even when it’s right; it takes months, it carries real risk, and a small workload you could rewrite cleanly in a couple of weeks may not justify the incremental apparatus at all. The framework here tells you which question a workload is asking. It does not excuse you from answering honestly — including the answer that this particular system should just be moved and left alone.

Where this leads

The lift-versus-refactor decision is where migrations are won or lost on paper. But sound decisions still fail in execution — and cloud migrations fail in patterns specific enough to name and avoid. Part 4, Why Cloud Migrations Fail, walks the recurring failure modes — the surprise bill, the big-bang cutover, the data migration nobody validated — and how to design each one out before it costs you.