Big-Bang Rewrites Almost Always Fail
Replacing an entire system at once feels decisive and clean. It is also the single most reliable way to turn a working operation into an expensive crater.
I build and replace software systems for a living. The most dangerous words a client can say to me are "let's just rebuild the whole thing at once." The big-bang rewrite is the most tempting plan in technology, and the one I fight hardest against. You scrap the old system, build its replacement in parallel, then flip a switch on launch day. It feels decisive, clean, and final. It is also how working operations turn into smoking craters.
I have watched teams pour a year and a fortune into a from-scratch replacement. Then, on launch day, they discover the old system did a hundred quiet things nobody documented, and now none of them work. The rewrite was supposed to be the upgrade. It became the outage.
Why the conventional wisdom is wrong
The common advice says a messy old system is best replaced cleanly. Freeze it, build its successor properly this time, and switch over once the new one is ready. It sounds responsible. But the old system is not just code. It is years of edge cases, fixes, and quiet behavior the business now depends on. A rewrite throws all of that away and bets the details can be rebuilt from memory, and they almost never can.
- The old system's quirks hold things up. Real customers, linked tools, and reports quietly rely on them, and nobody ever wrote that down.
- The rewrite has to chase a constantly moving target. The old system keeps evolving to serve the business the whole time you rebuild it.
- You deliver no value until launch day. So a full year of work produces zero feedback until it is far too late to correct course.
- The cutover is all or nothing. Every risk in the whole project converges on one scary moment.
What is actually true
The truth is that big systems are replaced safely by strangling them, not by blowing them up. You wrap the old system and route one slice of work at a time through the new one, and the old system shrinks slowly until nothing is left. Each step is small, reversible, and delivers value right away. Risk spreads across dozens of tiny cutovers instead of piling into one. By the time the old system is gone, the new one is already proven in production, piece by piece.
This is slower to start and far less satisfying than a clean-slate rewrite. There is no triumphant launch day, no moment where the old thing dies and the new thing is born. Instead there is a steady, boring migration where the lights never go out. That boredom is the point: the dramatic launch is where projects die, and the steady migration is where they survive.
When a rewrite is most tempting
The urge to rewrite is strongest at the exact moments you should resist it hardest.
- The old system is "a mess," so a clean rebuild feels satisfying. But messy and working still beats clean and unproven.
- A new team inherited the code, does not understand it, and would rather rebuild than learn it. That choice guarantees they will relearn its hidden lessons the hard way.
- A new technology is exciting. So the rewrite is really an excuse to use it. That is a bad reason to bet the entire business.
- Planning a step-by-step migration is hard, while "just rewrite it" sounds simple. So the safer, harder plan loses the meeting. The easy, risky one wins.
What we see at TTGC
When clients come to us wanting to scrap a system and rebuild it from zero, our first job is usually to talk them out of the big bang. We have seen the craters: year-long rewrites that launched broken and cutovers that took the business down. We have also seen rebuilds abandoned half-finished when the budget ran out. That leaves two half-working systems instead of one whole one. So we almost always migrate incrementally: wrap the old system, replace it slice by slice, and keep it running the entire time. Clients sometimes find this anticlimactic. They wanted a bold new platform, and we gave them a quiet series of small swaps. But their operation never went dark, and that is the whole job. The rewrites that make headlines are the ones that fail. The migrations that work are the ones nobody noticed.
The honest take
If you are about to replace a system, resist the clean rewrite no matter how good it feels. The big bang piles every risk onto one launch day and delivers nothing until then, which is why it fails so often. Strangle the old system instead: replace it one small, reversible slice at a time. Keep it running the whole way, and let the new system earn its place in production slowly. This path is slower, less heroic, and far less likely to end in a crater. In system replacement, boring is not a compromise. It is the strategy.
Sources
- Martin Fowler named the Strangler Fig pattern. It swaps out an old system, one bit at a time. See martinfowler.com
- Standish Group CHAOS Report. It tracks how often software projects fail. It also weighs the risk of large, all-at-once efforts.
- TTGC, what we see across client systems. Plus our own migration work.
Ready to work with Through The Glass Creatives?
Book a free Brand and Growth Assessment and see exactly how Mherie, Ravve, and the TTGC team would approach it.
Related reading: Modernizing Legacy Systems Without Halting Your Business · Most Transformation Projects Fail Before Launch
