The word "rewrite" sounds clean and decisive. You take the old thing, throw it away, and build a shiny new version from scratch. In practice, big-bang rewrites are one of the most dangerous bets in software. They take longer than anyone expects, they throw away real working code along with the bad, and they bet the business on a new system that has never been used by real customers.
The alternative isn't to leave the legacy software alone and hope it holds up. It's to modernise it incrementally, one piece at a time, while the system keeps running.
Why big-bang rewrites fail
A full rewrite sounds efficient but creates a period where you're maintaining two systems: the old one that's still live, and the new one that isn't ready yet. During that window:
- The old system still needs care. Bugs don't stop happening because you're building a replacement.
- Scope grows on the new build. Without the constraints of the existing system, ambition expands and "while we're at it" takes over.
- You lose institutional knowledge. The old code encodes years of business rules, edge cases, and hard-won lessons. Starting from scratch means rediscovering them the expensive way.
A rewrite isn't a fresh start. It's running two projects at once, one of which is invisible until it's too late.
The incremental path
Legacy software modernisation works best as a series of small, focused changes that each deliver value on their own:
- Strengthen what works. The parts of the system that are solid don't need touching. Leave them alone and focus energy where it matters.
- Replace one piece at a time. Swap out the component that's causing the most pain, not the whole system. Each swap reduces risk.
- Keep the system running. Every change goes live while the rest of the system continues working. No big-bang, no dangerous cutover window.
What this looks like in practice
A typical incremental modernisation might start with the most painful bottleneck, a slow database query, a page that times out, a report that takes an hour. Fix that one thing, ship it, and measure the improvement. Then move to the next worst piece.
Over months, the system transforms without anyone noticing a single dramatic moment. The codebase gets cleaner, performance improves, and the team gains confidence that each change is safe because the pattern is proven.
When to modernise vs. rebuild
Not every legacy system deserves modernisation. If the fundamental architecture is wrong for the problem, a monolith that needs to be distributed, a language that nobody maintains anymore, a rebuild might be the honest answer. But for most systems, the code works, the data is there, and the business depends on it running today. Incremental modernisation is how you improve it without betting the business on a single dramatic moment.
The question to ask isn't "is the code old?" It's "does the code do what the business needs, and can we make it do that better, one piece at a time?" If the answer is yes, modernise. If the architecture fundamentally can't support what you need, rebuild. But be honest about which one it is, because the cost of a rewrite you didn't need is one you feel for years.
