Why Big-Bang Rewrites Fail

A big-bang rewrite bets the business on one weekend: build the new system in the background, switch it on, switch the old one off, and find out on Monday everything the plan assumed.

---

The safer way replaces the old system a piece at a time, with each new piece running beside the old one and checked against it before anything is switched off.

The appeal of the rewrite is easy to see. The old system is slow, fragile and expensive to change, and a rewrite promises a clean slate: one project, one budget, one go-live date. It sounds decisive, and it is the riskiest way to modernize.

In 2000, Joel Spolsky looked at Netscape’s decision to rewrite its browser from scratch and called it “the single worst strategic mistake that any software company can make.” “There never was a version 5.0,” he wrote. Version 4.0 had shipped almost three years earlier; Netscape spent those years with no new major version to ship while the replacement was built.

Financial services has its own version. In April 2018, the UK bank TSB moved its customers onto a new banking platform in a single weekend, a “single-event implementation” in the words of the independent review its board commissioned. The data arrived intact, but the platform did not hold. Branch, phone, online and mobile banking were disrupted for a significant proportion of its 5.2 million customers, recovery took until December, and in 2022 the two UK regulators fined the bank £48.65 million.

In both cases the problem was the shape of the plan: everything was replaced at once.

The five assumptions a big-bang plan makes

A big-bang plan rests on five assumptions, and all of them have to hold at the same time. The plan meets them in this order: build it, move the data, keep the business waiting, cut over, and only then find out whether anyone knew everything the old system did. Sort them by what it costs if each is wrong, and the order turns upside down.

The ranking is our judgment, not a survey. The assumption that ends up on top is the one nobody writes down. An old system holds twelve years of answers to questions nobody remembers asking: the exception for one client, the rounding rule a regulator asked for, the workaround for a vendor bug fixed long ago. A rewrite built from a requirements document leaves those out and finds them one at a time, in production, after the old system is gone.

What piece by piece looks like

The alternative replaces the old system the way you would renovate a building people still work in: one floor at a time, with the lights on.

Say the invoicing moves first while everything else stays where it is. The new invoicing runs beside the old for a cycle on the same data, and its numbers are checked against the old system’s before anyone relies on them. When they match, the old invoicing is switched off and the next piece starts.

Engineers call this the strangler fig pattern, after the tree Martin Fowler saw in Queensland’s rainforests: it grows around its host a little at a time until the host is no longer needed. Nothing is switched over until it has already worked.

What piece by piece costs

You run two systems for a while, and some work is done twice so they can talk to each other. On a calendar, piece by piece can look slower than the rewrite’s promised date.

That date depends on all five assumptions holding on one weekend. Piece by piece trades one large, unknowable risk for a series of small, visible ones, each checked against the old system before it matters. And from the first month, something works that didn’t before.

Our team has worked this way. At MJ Hudson, between 2021 and 2023, Shan Peiris led the nine-person team that rebuilt six of the firm’s fourteen applications as modern services, in increments, with a demo to the C-suite after every one. Lakshitha, Saranga and Aravinda worked alongside him.