Every piece of software becomes “legacy” eventually — the label just means it’s old enough that changing it now carries real risk. The hard question isn’t whether to modernise eventually; it’s recognising the right moment, and choosing an approach that doesn’t put your business at risk in the process.
Signs It’s Time to Act
Legacy system problems tend to show up gradually, then all at once. Common warning signs:
- Every change takes longer than it should. If a small feature request now takes weeks because nobody fully understands how the system’s pieces connect, that’s a cost compounding quietly in the background.
- The people who understand it are leaving, or have left. Systems built and maintained by one or two people who’ve since moved on are a specific, serious risk — knowledge that exists only in someone’s head is knowledge your business doesn’t actually have.
- It can’t do something the business now needs. Integration with a new tool, support for a new payment method, compliance with a new regulation — legacy systems often weren’t built with today’s requirements in mind, and retrofitting keeps getting harder.
- Security patching has stopped, or is falling behind. Outdated frameworks and unsupported platforms accumulate known vulnerabilities that nobody’s actively addressing.
None of these alone necessarily means “rebuild everything now” — but two or three together is usually a strong signal that the cost of not acting is quietly overtaking the cost of doing something about it.
The Options, Realistically
Full rewrite. Sometimes genuinely necessary — particularly when the underlying technology is end-of-life, or the system’s architecture actively prevents the business from doing what it needs to do. But full rewrites are high-risk: they take longer than estimated more often than not, and running two systems in parallel during the transition is its own project.
Incremental modernisation (strangler pattern). Gradually replace pieces of the old system with new ones, routing traffic to the new components as they’re ready, while the old system keeps running underneath. This spreads risk over time and lets you keep delivering value throughout — at the cost of a more complex transition period where old and new coexist.
Targeted upgrades. Sometimes the core system is sound, but specific parts — an outdated database, an unsupported dependency, a fragile integration — are the actual problem. Fixing those specifically, without a wholesale rebuild, is often the fastest and lowest-risk path.
Wrap and extend. Building a modern interface or API layer around an old system that still works internally, so the business can move forward on the surface while the underlying system is modernised later, or not at all if it’s genuinely stable.
The right choice depends heavily on specifics — how central the system is, how much technical debt has actually accumulated, and how much appetite the business has for risk during the transition. Anyone who recommends a full rewrite without first understanding those specifics is optimising for an interesting project, not necessarily for your business.
Making It Safe
Whichever route you take, a few practices consistently reduce risk:
- Document what the current system actually does before changing it — including the undocumented behaviour everyone’s quietly relying on.
- Migrate incrementally where possible, so a mistake affects a small piece of functionality rather than everything at once.
- Keep the old system running in parallel until the new one has proven itself under real conditions, not just in testing.
- Involve the people who use the system daily early in the process — they know the edge cases that documentation missed.
Modernisation done well is rarely dramatic. It’s careful, incremental, and boring in the best sense — which is exactly what you want from a process touching the systems your business actually depends on.
