Replacing a System Nobody Can Turn Off

Every organisation running a system old enough to be a problem has had the same meeting. The system is slow, nobody understands all of it, the people who wrote it have moved on, and someone proposes rebuilding it properly.

Then two years pass. The replacement is nearly ready, has been nearly ready for eight months, and the original is still running because the business could never afford the day it stopped.

This is the normal outcome of a big-bang rewrite, not the unlucky one. The reason is structural: a rewrite is a bet that you can rebuild years of accumulated behaviour, including the parts nobody remembers, and switch over in one movement without breaking a business that depends on it daily.

The old system knows things nobody wrote down

The most underestimated part of a legacy system is not its code. It is the behaviour encoded in it that exists because something once went wrong.

The odd validation rule that exists because a customer type breaks without it. The overnight job whose ordering matters for reasons lost to history. The special case for one large account, added in a hurry, now depended upon by three downstream processes.

None of this is in the specification, because the specification describes what the system was meant to do. The system does what it does, and a replacement built from the specification will be subtly wrong in ways that surface one production incident at a time.

Strangle it instead

The alternative is well known and less often practised. Put the new system in front of the old one, route one capability at a time to the new implementation, and let the old one shrink until nothing is left.

The properties that make this work:

There is never a switchover day. Each migration is one capability, releasable and reversible on its own. A bad one is rolled back in minutes rather than becoming a crisis.

Value arrives continuously. The first improved capability ships in weeks. A two-year rewrite delivers nothing until it delivers everything, which is also why it so often gets cancelled at eighteen months with nothing to show.

The undocumented behaviour surfaces safely. Running both implementations against real traffic and comparing outputs finds the special cases while the old system is still authoritative and still correct.

The team learns the domain gradually, rather than needing to understand everything before writing anything.

Start where the value is, not where it is easy

The instinct is to migrate the simplest module first, to prove the approach. It is a reasonable instinct and it usually wastes the first three months on something nobody cared about.

Better to start where the pain is: the capability that is slowest, breaks most often, or blocks the thing the business actually wants to do next. It is harder, and it means the second conversation about the migration happens after something visibly improved.

The data is the hard part

Routing requests is straightforward. Deciding where the data lives during a migration that runs for a year is not.

Dual writes drift. Synchronisation adds a failure mode. Splitting a database that was never designed to be split surfaces every implicit join that used to be free. These need a deliberate decision per capability — which system owns this data, who may write it, and how divergence is detected — rather than a general intention to keep things in sync.

Where a clean split is not possible yet, it is usually better to leave the data where it is and move the behaviour first. Moving both at once doubles the risk and makes it impossible to tell which change caused a problem.

Delete as you go

The step that gets skipped: once a capability is served by the new system and has been stable for a while, remove it from the old one.

Teams that skip this end up running both systems permanently, which is worse than either. The old code stays, someone eventually routes something back to it, and after three years there are two systems where there was one. The deletion is what makes it a migration rather than an expansion.

---

iLeaf does this work as a practice rather than a project — see Modernization and How we work.