"Legacy" has become an insult in most boardrooms: shorthand for embarrassing, or held together with string. That's a shame, because the word used to mean something more useful: an inheritance. A legacy system is one that has been quietly running the business since before most of the people currently arguing about it arrived, absorbing exceptions, tax changes, mergers and the odd near-disaster, one patch at a time, without ever being asked to explain itself.
None of that history shows up in a modern audit. What shows up is a screen that looks like it's from 2003, a naming convention nobody can decode, and a consultant recommending replacement before anyone has established whether the system is actually broken, or just old. Those are different problems. Confusing them is how organisations spend a great deal of money to solve nothing.
The system that's earning its keep
Plenty of old systems deserve to be left exactly where they are. They run one process, they run it correctly, and nobody outside the team that depends on them has thought about them in years, which, for a piece of software, is close to the highest compliment available. A batch job that reconciles stock overnight. A payroll engine that has never once paid someone the wrong amount. A scheduling tool built for a factory floor that hasn't changed its shift pattern since the day it was installed.
Replacing a system like that isn't modernisation. It's vanity spend wearing modernisation's clothes. The business case will talk about risk and efficiency, but pull on the thread and the actual driver is usually that somebody senior finds it embarrassing that the number still comes out of a beige terminal window. Embarrassment is not a risk. If the system isn't costing anyone real time, isn't blocking a decision, and isn't exposed to anything dangerous, the responsible move is to leave it alone and spend the budget on the part of the estate that's actually causing damage.
The signals that actually mean something
There are a handful of reasons to touch a system that still works, and "it looks old" isn't one of them. The first is straightforward: nobody supports it any more. The vendor stopped patching it, the operating system underneath reached end of life years ago, or the one supplier who understood the hardware retired. Unsupported doesn't mean risky in some abstract future sense. It means every fault from here is fixed by nobody, and every new vulnerability stays open indefinitely.
The second is a person, not a platform. One individual understands how the thing actually works, and they are closer to retirement than the system is. Ask what happens if they left tomorrow. If the honest answer involves the word "panic", what looks like a stable system is really a single point of failure with a badge and a desk.
The third is that it's standing in the way. A system can run its one job perfectly at today's scale and still be the reason the business can't do the thing it needs to do next: take on the data format a new partner requires, absorb the volume an acquisition brings, connect to something it was never built to talk to. A system stops being harmless the day it starts costing the business its next move.
The fourth is exposure. Old software isn't automatically insecure, but unmaintained software sitting on a live network eventually is, whether or not anyone has noticed yet. "We've never had a problem" is a description of luck, not of safety, and luck is not a control.
Why the big rewrite fails
The instinctive response to an old system is to replace it wholesale: freeze the old one, specify the new one, build for a year or two, cut over on a Friday night. It is also, reliably, how modernisation programmes turn into the next legacy problem. A system that took a decade to reach its current state encoded a decade of decisions that nobody wrote down and few people can reconstruct from a requirements workshop. Big-bang projects rediscover this halfway through, once the estimate has already been spent.
Worse, the business doesn't hold still while the rewrite is being built. New products launch, regulations change, somebody signs a deal that assumes a capability the old system has and the new one, eighteen months into development, does not yet. By the time the replacement is ready, it's being measured against a business that has moved on, not the one the project was scoped against.
The alternative is less exciting and considerably more reliable: replace the system in pieces, behind the interfaces that already exist, one function at a time, while the old system keeps running everything nobody has got to yet. Each piece ships, earns its keep, and reduces what the old system needs to do, until eventually there's little enough left of it that retiring the remainder is a formality rather than an event. It's a slower story to tell a board. It's also the version that actually finishes.
The knowledge is in the system, not the wiki
The most valuable thing an old system holds usually isn't its code. It's the accumulated judgement buried inside that code: the tax exception added after an inspection, the validation rule that exists because of a customer complaint from a year nobody remembers, the odd sequencing that turns out to be the only thing preventing a duplicate payment. None of it was documented, because it didn't need to be at the time. The person who added it simply knew why.
Migrate the data and skip that knowledge, and the replacement will faithfully reproduce the bug that judgement was quietly preventing. The people who maintain the old system (often the ones nobody thought to interview, because they're not in the room where modernisation gets decided) are the closest thing the business has to documentation. Sit with them before writing a line of the new system, not after it's gone wrong in production.
A decision checklist
Before committing budget to modernising anything, it's worth answering the following, in order. The answers usually make the decision on their own.
- Is this system actually costing anyone time, money or sleep today, or does it just look old?
- Would replacing it change anything a customer, or the business, would notice?
- Is the platform still supported, and by whom?
- Does its continued operation depend on one person's memory?
- Is it stopping the business from doing something it needs to do next?
- Is it exposed to risks nobody has assessed since it went live?
- Has anyone who actually maintains it been asked what it's for?
Where to start
None of this is decided well from a slide with a red/amber/green rating and a guess at replacement cost. It starts with looking at what the system actually does, who depends on it, and what would genuinely break if it stopped: a proper audit, not a nostalgia trip or a sales pitch dressed as one.
That audit is a discovery exercise, and it's how we begin every modernisation conversation, because the honest answer is sometimes "leave it alone", and that's worth knowing before anyone commits to the alternative.
