"Does It Still Work?" Is The Wrong Question For Business-Critical Software

Ask most teams whether their core system is fine, and they'll say yes. It processes orders. It handles payments. Nobody's raised a ticket this week. Job done.

That's the wrong test. "Does it still work?" measures uptime. It says nothing about what happens the day it doesn't.

The Erosion, Not The Event

Legacy systems rarely fail overnight. They erode. Access gets slower. Simple tasks take more clicks, more workarounds, more "let me just check with Dave" than they should. Every change takes longer to ship, every integration gets a little more fragile, and the number of people who actually understand how the thing holds together keeps shrinking.

None of that shows up as an outage. It shows up as friction: a report that takes an extra day, a new starter who has to be told "we don't really touch that module", a release that goes out later than planned because nobody wants to be the one who breaks it. Each of those is small. None of them trips an alert. And because the core function still runs, it's easy to keep deferring the bigger conversation, right up until something finally breaks.

Ask The Real Question

So ask it directly. If this system went down tomorrow, could your people keep operating? Could customers still be served, orders processed, payments taken, information accessed? Would the business recover in an afternoon, or would the impact be severe, even catastrophic?

That's the actual test for business-critical software: not whether it's limping along today, but what your dependency on it would cost you if it stopped. Judged that way, a system can be "working" and still be a serious liability. It's the difference between a car that starts every morning and a car whose brakes you've never actually tested.

Most teams have never asked that question of their most important systems, because nobody's had a reason to. The system's always been there. It's always worked. That's precisely why the risk gets missed: the evidence you'd need to spot it, a near miss, a close call, a workaround that just about held, rarely gets written up or escalated. It just gets absorbed as "how things are."

Here's what that dependency tends to look like once you start digging into it properly.

Poor User Experience

The people who built the interface your staff use every day probably left the business years ago, along with the reasoning behind most of its design decisions. What's left is a system nobody would choose to build today, held together with tribal knowledge about which button actually does what.

That friction is a cost, even if it never appears on a spreadsheet. Slower onboarding, more errors, more time spent working around the system rather than with it. Multiply a few extra minutes per task across a whole team, every day, and the number gets large fast.

Declining Performance

Old architecture wasn't built for today's data volumes, today's integration count, or today's user load. Every year the gap between what the system was designed for and what it's actually being asked to do gets a little wider, and performance degrades a little further. Teams compensate with manual workarounds and patch fixes, which buys time but adds yet another layer that has to be maintained, understood, and eventually unpicked.

Technical Debt That Compounds

This is the cost that's easiest to underestimate, because it rarely arrives as a single bill. Deloitte's 2026 Global Technology Leadership Study puts technical debt at between 21% and 40% of total IT spending. For every pound spent on IT, a substantial chunk is going towards servicing decisions made years ago, not delivering anything new.

It compounds the way debt always does. Deferred upgrades and shortcut integrations don't disappear, they sit there accruing interest in the form of slower delivery, more defects, and less room to build anything new. The longer a business waits, the bigger the number gets, and the harder it becomes to justify the investment needed to fix it.

Knowledge Concentrated In Too Few Heads

Every legacy system eventually reaches a point where its real documentation is a person, not a wiki. One or two people carry the reasoning behind why a process works the way it does, what the odd exception handles, and which parts of the system are safe to touch. When that person leaves, retires, or is simply on holiday when something breaks, the business doesn't just lose a colleague. It loses the only reliable map of how a critical system actually behaves.

That's not a hypothetical risk sitting somewhere in the future. It's a live one, growing every year the underlying system stays unaddressed and the people who understand it move on. Ask around your own organisation how many business-critical processes genuinely have more than one person who could explain them under pressure, without notice, on a Friday afternoon. The answer is usually shorter than anyone would like.

Operational Risk That's Easy To Underprice

Put a number on an outage and the "it still works" framing starts to look thin. Estimates of the cost of IT downtime vary by size and sector, but even conservative, oft-cited industry baselines put the average cost of an hour of downtime well into six figures for a mid-sized organisation, before factoring in reputational damage or lost customer trust. For a business-critical system, that's not an IT budget line. It's an existential one.

Every release against a fragile, poorly understood system carries a little more of that risk than the last. Not because anyone's being careless, but because the margin for error shrinks every time another workaround gets bolted on.

Where This Usually Gets Missed

The reason all of this stays invisible for so long comes down to how it's measured. Uptime dashboards, incident counts, and SLA reports all answer "does it still work?" very well. None of them answer "what would it cost us if it didn't?"

That question needs a different exercise altogether: mapping which systems the business genuinely cannot operate without, how fragile each one actually is underneath, and what recovery would look like if the worst happened. It's not a technical audit so much as a business continuity one, and it usually surfaces at least one system that everyone assumed was low risk simply because it had never gone wrong.

What This Actually Costs The Organisation

Add it up and the picture is consistent: poor user experience slows people down, declining performance forces workarounds, technical debt eats budget that should be building the future, concentrated knowledge creates a single point of failure, and operational risk grows quietly with every release. None of it is visible in the way an outage is. All of it is real.

The goal here isn't newer technology for its own sake. Chasing the latest stack because it's fashionable is just a different way of ignoring the actual question. The goal is making sure the systems the business depends on stay safe, reliable, and practical to change, so that "does it still work" stops being the only question anyone's asking.

If you're not sure how your own business-critical systems would score against that test, that's exactly the conversation our data architecture and custom software development teams have with clients every week, and it usually starts with a much more useful question than "is it still running".

‍