Modernization Approaches Compared: Strangler Fig vs Lift-and-Shift vs Rewrite
Most modernization decisions reduce to three approaches. Lift-and-shift moves the system as-is to new infrastructure — fast, but it carries the old problems along. A full rewrite replaces everything and switches over at one cutover — cleanest in theory, riskiest in practice. Incremental replacement behind a strangler facade rebuilds the system one proven slice at a time, with old and new running side by side. For most large, business-critical systems the incremental path wins because it distributes risk instead of concentrating it, but the honest answer depends on the system's size, its hosting pressure, and whether it can run alongside its replacement.
Walk into any modernization decision and the options on the whiteboard nearly always reduce to three: move the system as it is, replace it all at once, or replace it piece by piece. The labels vary — rehost, replatform, rebuild, the 7 Rs — but underneath, the live choice is between lift-and-shift, a full rewrite, and incremental replacement behind a strangler facade. This guide compares the three at the decision level: what each is genuinely for, what it costs you, and how to tell which lane your system is in. The internals of each approach have their own deep treatments in this library; the job here is to route you to the right one.
The three approaches, plainly
Lift-and-shift (rehosting) moves the system unchanged onto new infrastructure — typically the cloud. The code, the architecture, and the behavior all stay the same; only where it runs changes. It is the fastest of the three and the lowest-risk technically, because you are not rewriting anything. What it does not do is fix the system. Whatever made the application hard to change still makes it hard to change — now with a cloud bill attached. Lift-and-shift solves a hosting problem, not a software problem.
A full rewrite (big-bang rebuild) builds a new implementation in parallel with the one in production, then switches over at a single cutover. In theory it is the cleanest outcome: new code, modern architecture, none of the old baggage. In practice it concentrates every risk on one distant date. The new system has to re-earn every behavior the old one accumulated — including the undocumented ones — and the business waits years for the first delta of value. This is why up to 70% of digital transformations fail to deliver on their objectives (BCG, 2023); the failures cluster around big, all-at-once programs.
Incremental replacement behind a strangler facade rebuilds the system one slice at a time. Each slice — a vertical cut of business capability — is built, proven to behave identically to the legacy through parity validation, and promoted to production while the rest of the system keeps running. Old and new coexist; the legacy is retired piece by piece. There is no single cutover, only many small reversible ones. It is slower to start delivering the final architecture than a rewrite promises to be, but it ships working value every few weeks and never bets the business on one date.
How they compare
| Lift-and-shift | Full rewrite | Incremental (strangler) | |
|---|---|---|---|
| What changes | Hosting only | Everything, at once | Everything, slice by slice |
| Risk shape | Low, but problem unsolved | Concentrated on one cutover | Distributed, each slice reversible |
| Time to first value | Fast | Years | Weeks |
| Fixes the legacy? | No | Yes (if it lands) | Yes |
| Cost profile | Low upfront, high to keep | High upfront, high overrun risk | Spread across the program |
| Rollback if it goes wrong | Revert the move | None once you cut over | One slice, one config change |
| Business disruption | Minimal | Roadmap freezes for years | Business keeps shipping throughout |
| The old system’s baggage | Comes with it | Gone (if you land) | Retired piece by piece |
| Where it fails | Sold as a fix when it isn’t | The distant cutover that keeps slipping | Wrong slice boundaries, no discipline |
| Best fit | Hosting deadline; buying time | Small, well-understood systems | Large, entangled, business-critical systems |
The rows that matter most are the ones teams skip when they compare on speed and cost alone: rollback, disruption, and where each approach fails. A method that is fast and cheap to start but has no way back and freezes the business for two years is not actually the cheap option. It just moves the bill.
Worked examples: three systems, three lanes
The approaches are abstract until you put them against real situations. Here are three, each a composite of the kind of system that lands in each lane.
The data center is closing in nine months. A retailer runs its order-management system in a leased facility whose lease is not being renewed. The system works. It is just in the wrong building. Here the pressure is the building, not the software, and the honest move is lift-and-shift: rehost onto the cloud before the deadline, accept that the application is no better afterward, and schedule the real modernization for once the clock is off. Trying to rewrite under a nine-month eviction is how you get a failed rewrite and a lost data center at the same time.
A 4,000-line internal tool one team fully understands. An operations team maintains a scheduling app built years ago by two engineers who still work there. It is small, the behavior is completely known, and a competent pair could rebuild it cleanly in a few weeks. Here a focused rewrite is the pragmatic call. The incremental apparatus, the facade, the parity harness, the slice sequencing, exists to control risk this system does not carry. Paying for that machinery on a small, well-understood tool is overhead, not safety.
A 900,000-line policy-administration platform the business runs on. An insurer’s core system has grown for two decades, nobody fully understands it, and it processes every claim the company pays. This is the lane where incremental replacement is not a preference but a survival requirement. A big-bang rewrite of a system this large and this poorly understood is the exact shape that fails most often, because it has to re-earn twenty years of undocumented behavior before it delivers a single claim. Slice by slice, behind a facade, with each slice proven before it carries traffic, is the only version of this that reliably lands.
Where each approach fails
Every approach has a signature failure. Knowing it is how you avoid it.
Lift-and-shift fails when it is mistaken for modernization. The move goes fine. Six months later the team is still slow, changes are still risky, and now there is a cloud bill that is often larger than the data center, because inefficient legacy code costs real money per hour to run. The failure is not technical. It is a strategy error made at the whiteboard, when relocating the problem got sold as solving it.
The rewrite fails at the distant cutover. The new system is always three months from ready. Parity gaps surface late, after sunk cost has already won every argument to keep going. The business waits years for the first delta of value, the roadmap freezes, and the people who knew why the old system behaved as it did have moved on before the rebuild needs them. This is the pattern behind the up to 70% of digital transformations that fail to deliver on their objectives (BCG, 2023). The failures cluster around big, all-at-once programs.
Incremental replacement fails on bad boundaries and lost discipline. The strangler shape removes the concentrated risk, but it introduces its own way to go wrong: cut the slices along the code’s accidental structure instead of real domain seams and you get a distributed system that is more tangled than the monolith was. Skip the parity proof to move faster and you reintroduce exactly the cutover risk the approach exists to remove. The method is safe only if the discipline holds.
How to tell which lane you are in
Three questions usually settle it.
Is the pressure a closing data center or a contract deadline? If something external forces you off your current infrastructure before you can modernize, lift-and-shift buys time — move first, modernize after. Just go in clear-eyed that you have relocated the problem, not solved it.
Is the system small and genuinely well understood? If a competent team could rebuild it cleanly in a few weeks and the behavior is fully known, a focused rewrite can be the honest, pragmatic choice. The incremental machinery exists to control risk that a small system does not carry. Don’t pay for apparatus you don’t need.
Is the system large, entangled, or business-critical? Then incremental replacement is almost always the right default, because the thing that kills modernization programs at that scale is concentrated risk — and incremental delivery is the structural answer to it. The bigger and more poorly understood the system, the more reliably a big-bang rewrite fails and the more the slice-by-slice approach pays off.
When the three questions disagree, weight them in that order. External hosting pressure decides the near term first: if you must move by a date, lift-and-shift wins the near-term argument regardless of the rest, and the modernization question waits. Absent that pressure, size and understanding decide: small and fully known points to a rewrite, large or entangled points to incremental. The one combination to distrust is “large, critical, and we’re confident we understand it well enough to rewrite it.” That confidence is almost always the documentation gap talking, and it is the exact prelude to a failed big-bang.
The approaches aren’t rivals
These approaches are not a forced single choice, and treating them as one is a common mistake. Real programs mix them: lift-and-shift to escape a data-center deadline, then modernize incrementally; refactor the slices that are basically sound while rewriting the ones that need new capability; leave alone the parts that need neither. The decision is rarely “pick one for the whole system” — it is “match each approach to the part of the system it fits.”
And none of the three is illegitimate. Lift-and-shift providers solve a real problem when the clock is on the infrastructure. Big-bang rewrites are simpler and faster for small, isolated systems. The point is not that one approach is virtuous and the others are traps — it is to match the method to your system’s actual situation with clear eyes about the risk each one carries.
Where this leads
Choosing an approach is the first fork. The second is whether to modernize the system you have at all, or replace it wholesale — buy a package, adopt a SaaS product, or rip and replace. Part 2, Modernize vs Replace (Rip-and-Replace), takes that decision head-on: when keeping and improving the asset beats throwing it away, and when it genuinely doesn’t. If you want to put numbers behind the comparison first, the Legacy Cost Calculator estimates what standing still on the current system already costs.
Frequently asked questions
- What is the difference between lift-and-shift and a rewrite?
- Lift-and-shift moves the existing system, unchanged, onto new infrastructure — usually the cloud — so the code and architecture stay the same and only the hosting changes. A rewrite replaces the code with a new implementation. Lift-and-shift is faster and lower-risk but solves only a hosting problem; a rewrite can change everything but concentrates all the risk on one cutover.
- Is the strangler fig pattern always better than a rewrite?
- Not always — it is better for most large or entangled systems because it replaces them slice by slice with each slice proven and reversible, so risk never concentrates on a single date. But for a small, well-understood system that can be rebuilt cleanly in weeks, the incremental apparatus is overhead you do not need, and a focused rewrite can be the pragmatic call.
- Can you combine these approaches?
- Yes, and good programs usually do. You might lift-and-shift to escape a closing data center, then modernize incrementally once the pressure is off; or refactor the slices that are basically sound while rewriting the ones that need new capability. The approaches are not mutually exclusive — the skill is matching each one to the part of the system it actually fits.
- Which modernization approach is cheapest?
- Lift-and-shift is cheapest to execute and most expensive to live with, because it changes the hosting and leaves the software problem in place, so the maintenance drag and change cost continue. A full rewrite has the highest upfront cost and the highest chance of overrunning it, since the new system has to re-earn every accumulated behavior before it delivers anything. Incremental replacement spreads its cost across the program and starts returning value within weeks, so it is rarely the cheapest to start but usually the cheapest per unit of risk removed. The real comparison is not sticker price. It is total cost including the risk of the approach failing, and on that measure the incremental path is normally the most economical for a large system.
- When is lift-and-shift a mistake?
- When you reach for it hoping to fix the system rather than just relocate it. Rehosting a slow, brittle, hard-to-change application onto the cloud gives you a slow, brittle, hard-to-change application with a usage-based bill, and the bill is often higher than the data center it replaced because inefficient legacy code is expensive to run per hour. Lift-and-shift is the right call when an external deadline forces you off your current infrastructure and you have decided, deliberately, to move now and modernize later. It is a mistake when it is sold as modernization itself.
- What is a strangler facade?
- A routing layer placed in front of the legacy system that decides, request by request, whether each call is served by the old system or by a new component that has replaced part of it. On day one it routes everything to the legacy system, so nothing changes for users. As each slice is rebuilt and proven, the facade shifts that slice's traffic to the new component, a controlled percentage at a time, with the legacy still standing by for rollback. It is the mechanism that lets old and new run side by side and turns a single risky cutover into many small reversible ones. The name comes from the strangler fig, which grows around a host tree and gradually takes its place.