The Big Rewrite
"The big rewrite" is the plan to build a complete replacement for a working system alongside it, then move everything over in one go. It is the default shape a rewrite takes when nobody argues for a different one, and it is the shape that fails most reliably.
What makes a rewrite "big"
What defines it is the cutover, not the size of the codebase. A big-bang rewrite defers all delivery to a single switching event. Until that moment, nothing the team has built is in customers' hands, and after it, everything is. That separates it from the other things called rewrites:
- Refactoring changes internal structure without changing output. No cutover, no risk of this kind.
- Incremental replacement moves the seam gradually, a strangler fig routing one feature at a time. Many small cutovers, each reversible.
- The big rewrite has exactly one cutover, and it is not reversible.
Why teams pick it anyway
Because it is the version that feels safe. The appeal is the fantasy that because you only do it once, you can pour enough preparation into that one release to make it safe. Everything else about a rewrite is downstream of that belief.
It also feels efficient. Problems in an aging system tend to come coupled: the performance is bad, the data model is wrong, the UI is dated, the stack is old. Each one appears to block fixing the others. The authors of The Rewrite Trap call this musketeering: all for one and one for all, fix everything or fix nothing. Under musketeering, replacing everything at once looks like the only coherent option. Break the coupling by solving one member on its own and the big rewrite stops being necessary.
The costs that do not appear in the plan
The reset button hides a new set of risks:
- The business does not pause. The old system still needs bug fixes, still has outages, still demands features.
- Competitors do not pause. By the time you reach feature parity, the definition of parity has changed, and you ship something already behind.
- You pay for two of everything. Two codebases, two deployments, two sets of bugs, two competing priorities, and eventually two teams. The pain comes from maintaining two complete systems at once with the payoff deferred to one switch at the end, not from new code existing beside old code. That is duplication, not progress.
- The new system grows its own debt before it launches.
The second-system effect
Fred Brooks described this in 1975: the tendency to over-design a replacement. The first system stays disciplined because nobody knows what they are doing yet; the second inherits all the confidence and none of the restraint. Given a blank canvas, teams build the general solution, a framework for building solutions instead of a solution, which abstracts away every problem except the one the business has.
AI has not repealed this. If anything it accelerates it: AI tools will happily propose abstractions and extra features that each sound reasonable in isolation, and without firm scope boundaries an AI-assisted rewrite keeps expanding.
The six endings
A big rewrite ends in one of six ways, none of them the one in the plan: the Never-Ending Rewrite (six months becomes two years becomes cancellation), the Half-Launched Rewrite (part ships, nobody migrates, both systems run forever), the Over-Engineered Rewrite (collapses under its own architecture), the Business-Alienated Rewrite (arrives perfectly suited to the company of five years ago), the Product-Led Rewrite (launches without the boring features customers depend on), and the Vasa Rewrite.
That last one is the big rewrite in its purest form, and it is named for a literal example. In 1628 Sweden launched the Vasa, the most powerful warship it had ever built, made larger and more heavily armed than designed because the king wanted it so. A stability test alarmed the men running it, but the launch date would not move. The Vasa caught its first strong gust and sank thirteen hundred meters into its maiden voyage.
The Vasa Rewrite stakes everything on a single launch with nothing held in reserve. The other five outcomes waste time and money; this one also destroys trust, and goodwill built over years can drain in a single afternoon. Sonos's 2024 app release is the modern version: roughly $100 million of revenue impact, a CEO gone within eight months, and about a quarter of the company's market value.
The comparison that matters
On 1 August 2012 Knight Capital lost $440 million in 45 minutes over a botched release. Neither version of the software was broken. The firm lost control of which version was running, at roughly $160,000 per second.
A big-bang cutover is that same uncontrolled release, scaled to your entire system. Iterative replacement runs the opposite way: far more releases, none of which get lavish preparation, and none of which can sink you. The safety comes from keeping the blast radius small, not from the care taken over any one release.
If you are already committed
Being partway into a big rewrite does not mean finishing it. Calling one off is leadership, and a rewrite that gets stopped still leaves you something: reusable components, better tests, cleaner abstractions, and, above all, a much sharper understanding of the legacy system, because reaching for parity forced the team to figure out what the old code really did. Capture that while the people who earned it are still there. It is the one thing you cannot rebuild later.
