The Big-Bang Rewrite Trap

This series stakes a single claim: the safest way to replace a legacy system is to replace it slice by slice, with each slice proven equivalent to the old one before it carries real traffic — never to rebuild the whole thing and switch over at one date. That claim only earns its weight if the alternative is understood clearly, so the series opens where every modernization program opens: with the rewrite, and the reasons it is chosen far more often than it should be.

The choice between a big-bang rewrite and incremental replacement is the most consequential decision in the entire program. It is made before a line of code is written, it shapes every outcome that follows, and it is usually made for the wrong reasons — not because anyone is careless, but because the rewrite’s risk is the one that hides.

What “big-bang” actually means

A big-bang rewrite rebuilds the system in parallel with the one in production, then replaces it all at once. For a window — often measured in years for an enterprise system — two efforts run side by side: keeping the legacy system alive and serving the business, and constructing its replacement. Nothing about the replacement reaches users until it is finished. On cutover day, the business flips from old to new in a single move.

The opposite shape replaces the system one slice at a time. Each slice — a vertical cut of business capability — is built, proven equivalent to the legacy behavior, and promoted to production behind a routing layer while everything else runs unchanged. Old and new coexist throughout; the legacy system is retired piece by piece. There is no single cutover, only many small ones, each reversible. That shape has a name and a body of practice behind it — the strangler fig pattern — and the rest of this series is, in effect, the risk case for choosing it.

Both shapes can target the identical end state. The difference is not ambition or effort. It is how risk, value, and feedback are distributed over time — and that difference decides most outcomes.

Why the rewrite is so seductive

The pull toward a rewrite is real, and it comes from honest places. Worth naming them plainly, because a trap you can’t see the appeal of is one you’ll walk into again:

• The legacy code is genuinely painful. Every change is slow and risky; the team is tired of working around it. A clean slate promises relief.
• A fresh build looks faster than it is. Greenfield code moves quickly at first — there is nothing to work around yet — which creates an early impression of velocity that the integration phase later erases.
• The team gets the stack it wants. Modern tools, a clean architecture, none of the old constraints. That is motivating, and motivation is not nothing.
• It tells a clean story to leadership. “We will rebuild it properly and switch over in Q3” is far easier to put on a slide than “we will replace it gradually over many increments.” The simpler narrative wins the room.

None of these is foolish. The teams who choose a rewrite are usually capable engineers and serious leaders. The framing simply makes the rewrite look like the disciplined option while obscuring what it actually does to risk.

The trap: where all the risk goes

Here is the move the rewrite makes that the slide never shows. It takes every category of risk in the program and stacks it onto a single future moment.

• Parity risk is deferred to cutover. Whether the new system actually reproduces the old one’s behavior — including the undocumented rules accreted over decades — is not truly tested until live traffic hits it. The first real exam is the cutover itself, which is the worst possible time to learn the answer.
• Estimation risk is maximized. The core estimate is “rebuild the whole system,” made at the moment the team understands the system least. There is no early delivery to calibrate against, so the forecast drifts and the timeline slips with no mechanism to catch it.
• Value risk runs the whole length. The business sees nothing until cutover, so the program runs for years on faith, with no delivered result to defend it when budgets tighten.
• Continuity risk concentrates on one day. The entire business switches systems at once. If the new system misbehaves, there is no slice to roll back — only the whole thing, often with the old system already half-decommissioned.

The same four risks exist in both shapes. The only question is whether they land all at once, far away, or a little at a time, up close:

Risk	Big-bang rewrite	Incremental, slice by slice
Parity (does the new system behave like the old?)	Untested until cutover, under live load	Proven per slice before it carries traffic
Estimation	One giant estimate made when you understand the system least	Re-calibrated against every slice you actually ship
Value	Nothing until cutover. Years running on faith	Working software delivered every increment
Continuity	The whole business switches on one day	One small, reversible cutover at a time
Reversibility	Roll back everything, or nothing	Roll back a single slice and keep running

Stack those together and the trap is visible. The rewrite feels lower-risk because it has one clean plan and one clean date. It is in fact the highest-risk shape available, because it removes every opportunity to discover a problem while that problem is still cheap to fix. The industry baseline reflects this: Boston Consulting Group found that up to 70% of digital transformations fail to deliver on their objectives (BCG, 2023). That figure is not evidence the goal is impossible — it is evidence that most programs keep choosing the shape that concentrates risk.

The trap closes with sunk cost

What makes it a trap rather than merely a risky choice is how it ends. Two years and a large budget into a rebuild, the parity gaps start surfacing. The rational response — stop, reassess, change shape — is now the hardest thing to do politically, because so much has been spent. Sunk cost wins the argument to push forward, the gaps get patched live under pressure, and the program limps to a cutover it cannot safely reverse. The decision that felt most responsible at the start has removed every off-ramp by the end. (Part 2 takes apart exactly why the rewrite fails, mechanism by mechanism.)

The honest exception

This series will argue for incremental replacement throughout, but it will not pretend the rewrite is never right — that overreach would be its own kind of dishonesty. A big-bang rewrite is the sound call in a few real situations:

• Small, well-understood systems. If a clean rebuild genuinely takes weeks, the apparatus of running old and new side by side costs more than the risk it removes. Don’t build a routing layer to replace something one engineer could rewrite over a long sprint.
• Forced wholesale replacement. When an external constraint makes coexistence impossible — a vendor platform at hard end-of-life with no path to run a replacement alongside it — the incremental shape simply 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 machinery.

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 — and the systems worth a modernization program are precisely the large, critical, entangled ones. The same decision at the pattern altitude, with the incremental mechanics laid out, lives in Strangler Fig vs Big-Bang Rewrite; if you want to put numbers behind the choice, the legacy cost calculator helps weigh acting against waiting.

Where this leads

This part named the trap and where the risk goes. The obvious next question is why — why does a shape this seductive fail so consistently, even for strong teams? The answer isn’t bad luck or bad engineering; it’s a small set of well-documented forces that operate on rewrites specifically. Part 2, Why Software Rewrites Fail, takes them apart one by one — the second-system effect, the knowledge you silently discard, the moving target, and the sunk-cost ratchet — so the failure stops looking like misfortune and starts looking like a predictable property of the shape.