The visible costs
Some of what legacy IT costs you is on the surface. End-of-life hardware and software attracts premium support contracts – if support is available at all. Often it isn't. Running a system that the vendor no longer patches or maintains means you own every problem that emerges from it, without recourse to anyone who built it.
Older infrastructure fails more often and takes longer to recover from. Most businesses don't track downtime events systematically, which means the cost – lost productivity, missed transactions, staff time spent managing the incident – goes unmeasured. Unmeasured costs don't make it into investment cases. That's part of why modernisation decisions keep getting deferred.
Security patching is the starkest visible cost. Systems that no longer receive updates are a liability – not a theoretical one. The majority of successful breaches exploit known vulnerabilities in software that hadn't been patched, often months or years after the fix was available. Running unpatched systems isn't a gap in your security posture. It's a gap with a known address that attackers can look up.
The invisible costs
This is where the real damage accumulates. And because it's spread out, gradual and hard to attribute to a single line item, most businesses underestimate it significantly.
Staff workarounds. When systems are slow, clunky or unreliable, people find ways around them. Spreadsheets that duplicate data from the official system. Manual processes that should be automated. Copy-paste workflows that introduce errors every time someone is in a hurry. These workarounds become invisible infrastructure. They're rarely documented. They create dependency on specific individuals – the person who knows how the spreadsheet works, the one who manually runs the export every Monday morning. When those people leave, the knowledge goes with them. And they do leave, partly because competent people don't want to spend their time fighting with broken tools.
Integration debt. Every integration built around a legacy system is a liability waiting to be called in. When the legacy system eventually changes – or breaks – every downstream integration breaks with it. Businesses that have deferred modernisation for years often discover their technical debt runs deeper than they thought, precisely because legacy systems have accumulated integrations that nobody has a full map of. The cost of unwinding that isn't just the new system. It's the archaeology project required to understand what's connected to what before you can safely change anything.
Opportunity cost. This is the most commercially significant invisible cost, and the hardest to quantify. You can't implement a new system because it won't integrate with the old one. You can't adopt a better process because the current platform doesn't support it. You can't scale a particular workflow because the underlying system is a bottleneck. These aren't IT problems. They're commercial constraints – capabilities you don't have, decisions you can't make quickly, market opportunities you respond to more slowly than you should. The legacy system doesn't appear on the list of reasons you didn't win that contract or couldn't move fast enough on that initiative. But it's there.
Staff morale and retention. This one gets underestimated in almost every organisation we work with. People don't often leave a job because the software is bad. But it's a factor more often than employers recognise, particularly for technical roles. Someone who joined expecting to work with modern tools and spends their time managing broken integrations and manually reconciling data will look elsewhere. The cost of replacing them – recruiting, onboarding, the ramp-up period – is significant. It rarely gets attributed to the systems that contributed to their decision to go.
The bias toward keeping legacy systems
If the costs are real, why does this keep happening? It's not purely inertia, though inertia plays a role. The dynamic is more structural than that.
The cost of modernisation is visible, immediate and concentrated. A project cost, a migration timeline, disruption during cutover – these show up clearly on a budget and require someone to approve them. The cost of legacy is spread out, gradual and dispersed across teams in ways that are genuinely difficult to measure. Finance doesn't see an invoice for "staff time lost to manual workarounds" each month. It just doesn't appear.
The "if it ain't broke" logic holds enormous appeal until you look carefully at whether it's actually true. The system works, in the sense that it processes transactions and hasn't fallen over completely. But it's broke – broke gradually, across dozens of small frictions and missed opportunities that nobody tracks as a single line item.
Migration risk is real and shouldn't be dismissed. Moving data, rebuilding integrations and retraining teams on new systems carries genuine risk. But that risk is manageable with proper planning. It's the unmanaged risk of staying on the legacy system – the security exposure, the increasing fragility, the accumulating integration debt – that tends to be underweighted in the same conversation.
Often the decision doesn't belong clearly to anyone. IT knows the problem but doesn't control the budget. Finance controls the budget but doesn't feel the pain directly. Operations feels the pain but isn't driving the technology strategy. The modernisation decision falls into the gap between them and nothing happens until something breaks badly enough to force the issue.
How to think about it
Don't start with "what should we replace." Start with "what is this costing us." That reframes the conversation in terms that every stakeholder can engage with.
Quantify the maintenance spend on the legacy system. Count the downtime events in the last 12 months and estimate what each hour cost the business. Talk to the people who use the system every day and ask how much time they spend on workarounds – then multiply that across the team and across the year. Look at the security exposure: is this a system that's still receiving patches, and if not, what's the risk profile?
Then look at what you can't do. The capabilities you want that the legacy system prevents, the integrations you'd build if the platform supported them, the workflows you'd automate if the underlying system allowed it. Give those a commercial value, even a rough one.
When the status quo has a price attached to it rather than being treated as free, the modernisation decision looks different. The question shifts from "can we afford to change this?" to "can we afford not to?" That's usually the right question – and it's the one most businesses get to eventually, just later than they needed to.