How to modernise a legacy system without a big-bang rewrite
The full rewrite is the most tempting and most dangerous way to modernise. There's a slower path that actually finishes.
Every legacy system eventually invites the same proposal: throw it away and build a new one. The old code is hard to change, the people who wrote it have moved on, and a clean rewrite promises to make all of that go away.
It rarely does. The rewrite has to reach feature parity with a system that took years to grow — including the edge cases nobody remembers until they break — all while the old system keeps changing underneath it. Most big-bang rewrites run long, cost more than the system they replace, and a fair number are quietly abandoned halfway.
There’s a less dramatic path that has one advantage: it finishes.
Strangle, don’t replace
The pattern is old and boring and it works. Instead of replacing the system in one move, you put a boundary in front of it and route one capability at a time to new code. The old system keeps running. Each slice you move is small enough to understand, test and reverse. Over time the new implementation grows around the old one until there’s nothing left inside — and at no point was there a single risky switch-over.
It’s called the strangler pattern, and its real value isn’t technical. It’s that you’re never betting the business on a date.
Make the first slice a real one
The temptation is to start with something trivial to prove the approach. Don’t. Start with a capability that’s genuinely painful in the old system — one where the business will feel the improvement. That does two things: it proves the approach on real complexity, and it earns the patience you’ll need for the slices that follow.
Keep the old system honest
While you migrate, the legacy system is still your source of truth. Run the new path alongside the old one and compare outputs before you cut over. When they disagree — and they will — you’ve usually just found an undocumented rule that the old system has been quietly enforcing for years. That discovery is the whole point. It’s also exactly what a big-bang rewrite skips, and exactly why so many of them fail on launch day.
The trade-off, stated plainly
Incremental modernisation is slower to start and less satisfying to talk about than a fresh build. You carry two systems for a while. What you get in return is that you’re always shippable, always reversible, and never staking the whole business on one cut-over that has to go right. For a system a business depends on, that’s a trade worth making every time.