Strangler Fig vs Big-Bang Rewrite

Part 1 defined the strangler fig pattern: replace a legacy system from the edges in, slice by slice, while it keeps running. The obvious question is the one every modernization program faces before a line of code is written — why not just rewrite the thing and switch over? This part answers it. The choice between strangler fig and a big-bang rewrite is the most consequential decision in the program, and getting it right is mostly a matter of seeing the rewrite’s risk clearly, because the rewrite is the one whose risk hides.

The two shapes

A big-bang rewrite rebuilds the system in parallel with the one in production, then switches over at a single planned cutover. For a window — often measured in years — you run two efforts: keeping the legacy system alive, and building its replacement. On cutover day, you flip from old to new.

The strangler fig pattern replaces the system in a running sequence of slices. Each slice is built, proven equivalent to the legacy behavior, and promoted to production behind a routing facade while the rest of the system runs unchanged. Old and new coexist throughout; the legacy system is retired piece by piece as the modern one takes over. There is no single cutover — there are many small ones, each reversible.

Both can target the same end state. The difference isn’t ambition. It’s how risk, value, and feedback are distributed over time — and that difference decides most outcomes. (The general version of that risk-distribution argument is its own article: Incremental vs Big-Bang Modernization. Here we stay on the rewrite specifically, because the rewrite has failure modes all its own.)

Why the rewrite is so seductive — and so dangerous

The rewrite is appealing for honest reasons. The legacy code is hard to work in; a clean slate promises to be fast and pleasant; the team gets to use the stack they actually want. None of that is foolish. The teams who choose a rewrite are not naive — the framing simply hides the risk until it’s too late to recover.

Two well-documented forces do the hiding:

The second-system effect. Fred Brooks named it in The Mythical Man-Month (1975): a team’s second system is the most dangerous it will ever build, because it accumulates every feature and refinement the disciplined first version had to leave out. A rewrite is a second system by definition. Freed from the old constraints, scope balloons, the schedule slips, and the “clean” replacement becomes a new tangle that arrives late.

The discarded knowledge. In Things You Should Never Do, Part I (2000), Joel Spolsky made the case against the rewrite using Netscape, whose decision to rewrite its browser from scratch cost it years of market position. His core point endures: the ugly code you want to throw away is ugly because it encodes years of bug fixes for real-world edge cases. Rewrite from a clean slate and you silently discard all of it, then rediscover each case as a production incident.

The uncomfortable baseline sits underneath both: BCG found that up to 70% of digital transformations fail to deliver on their objectives (BCG, 2023). The cause is rarely a bad target architecture. It’s shape — and the rewrite is the shape that fails most reliably at scale.

The trade-off, head to head

Dimension	Big-bang rewrite	Strangler fig
When value arrives	All at cutover	Every few weeks, continuously
Where risk sits	Concentrated on one date	Distributed across many small steps
Rollback	All-or-nothing, often infeasible	Per slice, always available
Feedback	First real signal at cutover	After every slice
Business continuity	At risk during cutover	Maintained throughout
Legacy knowledge	Re-derived from scratch	Carried slice by slice
Upfront engineering	No facade needed	Routing facade required
Operating complexity	One system live during build	Two systems coexist

The table is honest in both directions. The strangler fig pattern wins decisively on risk, value timing, reversibility, and feedback — the dimensions that decide whether a large program survives. The rewrite wins on two real points: it avoids the operational complexity of running two systems at once, and it skips the facade engineering. For most enterprise systems those advantages are small and the disadvantages are fatal. But they are not nothing, which is why this is a judgment, not a dogma.

The cost and timeline the rewrite hides

The head-to-head table understates one dimension on purpose: money and calendar. Both deserve their own look, because the rewrite’s real price is not the replacement build. It is everything you keep paying while that build is in flight.

Three costs land on the rewrite that the strangler shape avoids or ramps down:

• The parallel-run tax. For the whole rebuild window, often two to three years on a large system, you fund two systems at once. The legacy one still needs its bug fixes, its compliance patches, its on-call rotation, its infrastructure bill. The new one needs a full team. You are not spending the replacement budget instead of the maintenance budget. You are spending both, together, for years.
• The frozen roadmap. A rewrite tends to freeze feature work on the legacy system, because every change now has to be built twice or it widens the gap the new system has to close. So the business waits. Competitors keep shipping. That cost is real even though it never shows up on the project’s own ledger.
• Value deferred to one date. The strangler shape returns value after the first slice, weeks in, and keeps returning it. The rewrite returns nothing until cutover. A unit of value at month thirty is worth far less to the business than the same unit at month two, and the rewrite pushes all of them to month thirty.

The strangler fig pattern is not free either. It front-loads the facade and pays the operational cost of two systems coexisting, which is the rewrite’s one honest advantage. The difference is when the spend converts to value, and whether it converts at all. Strangler spend buys shipped, reversible slices from the first month. Rewrite spend buys a promise that only pays out if a single distant cutover lands.

How the money and calendar behave	Big-bang rewrite	Strangler fig
First value to the business	At cutover, often 2+ years out	Within weeks, then continuous
Legacy upkeep during the build	Fully funded in parallel, flat	Ramps down as slices retire it
Feature roadmap	Typically frozen	Continues on live slices
Cost if the plan stalls	Sunk, with nothing shipped	Contained to the current slice

What a stalling rewrite looks like

The failure worth naming is rarely a dramatic collapse. It is a slow one, and it looks reassuring until very late.

A rewrite reports progress in tasks completed, not in value shipped, because nothing ships until the end. So for most of its life it looks healthy. Burndown charts fall, demos of the new stack impress, the team is visibly busy. The trap is that the last stretch, the parity work, is where the real cost hides. The new system has to match not just the features anyone remembers but the thousand behaviors the old one quietly grew to handle: the edge cases, the data quirks, the undocumented rule a single large customer depends on. Those surface one at a time, late, as the team tries to close the gap to a system it is trying to replace wholesale.

So the rewrite reaches “ninety percent done” and stays there. Each newly discovered behavior costs another week. The cutover date slips a quarter, then another. By now the sunk cost is large enough that stopping feels like admitting the whole effort was wasted, which is exactly the trap: the argument to keep going gets stronger precisely as the evidence says it is not working. This is how a two-year rewrite becomes a four-year one, and how some never cut over at all.

The strangler shape cannot produce this failure, because parity is proven per slice, on a small surface, before that slice carries traffic. The gap between what was built and what the system actually has to do surfaces in week six of a single slice, not in year two of the whole program. A slice that cannot reach parity is a contained problem you can rescope or defer. A rewrite that cannot reach parity is the program.

The honest case for the rewrite

Pretending the strangler fig pattern is universally correct would be exactly the overreach this brand refuses. A big-bang rewrite is the right call in a few real situations:

• Small, well-understood systems. If a clean rebuild genuinely takes weeks, the facade and slice-by-slice coexistence cost more than the risk they remove. Don’t build a routing layer to replace a system one engineer could rewrite over a long sprint.
• Forced wholesale replacement. Sometimes an external constraint mandates replacing everything at once — a vendor platform at hard end-of-life with no path to run a replacement alongside it, or a regulatory change that invalidates the entire current approach. If coexistence is genuinely impossible, the strangler shape isn’t available.
• Truly independent systems. A system with no live coupling to anything else, swappable behind a simple switch with a clean rollback, doesn’t need the incremental apparatus.

The deciding variable is size and entanglement. The smaller and more isolated the system, the more defensible the rewrite. The larger and more interwoven with the running business, the more reliably it fails. The mistake is never choosing a rewrite — it’s choosing one for a large, entangled, business-critical system because the clean-slate story is seductive.

How to choose, in practice

Walk a short path for the system in front of you:

1. Can the legacy and a replacement coexist, with traffic split between them? If no — a hard external constraint forces wholesale replacement — a rewrite may be unavoidable; proceed with eyes open. If yes, continue.
2. Is the system small enough to rebuild cleanly in weeks? If yes, a rewrite is likely simpler and cheaper. If no, continue.
3. Is it business-critical and entangled with the running operation? If yes — which describes most systems worth a modernization program — the strangler fig pattern is the strongly indicated choice.

Most systems that justify a program at all land on the strangler shape, because the systems worth modernizing are precisely the large, critical, entangled ones. If you want to put numbers behind the decision, the legacy cost calculator helps weigh the cost of acting against the cost of waiting.

Where this leads

Choosing the strangler fig pattern raises an immediate engineering question: what actually holds a system together while half of it is old and half is new? The answer is a single piece of infrastructure that every other part of this series depends on. Part 3, The Strangler Fig Facade & Routing Layer, goes inside it — where it sits, how it decides which implementation answers each request, and why getting it right is what turns “replace it slice by slice” from a slogan into a working migration.