What is a legacy system, and when does it become a business risk

What is a legacy system, exactly?

Most definitions focus on age, but age is a weak signal. A ten-year-old system on a supported platform, with documentation and a developer who can still change it safely, is not legacy in any way that matters. A three-year-old system built by a contractor who has since disappeared, on a framework nobody maintains, absolutely is.

The useful definition is this: a legacy system is software that is critical to the business but has become disproportionately expensive or risky to change, support, or replace. That combination - critical plus risky - is what should worry a director, not the year on the invoice.

• It runs on a platform the vendor no longer patches, so every month it goes unpatched is a month closer to a known vulnerability being exploited.
• It depends on one person's knowledge, whether an employee nearing retirement or a freelancer who has moved on.
• It can't be connected to anything new without manual exports, workarounds, or a consultant flown in specially.
• Nobody wants to touch it, because the fear of breaking something outweighs the benefit of improving it.

The warning signs it's becoming a risk

Legacy risk builds slowly, which is exactly why it catches businesses out. There is rarely a single dramatic failure - more often a string of small ones that get worked around until a working around is itself the process.

Why legacy systems are a bigger deal for regulated or growing businesses

If your sector has any compliance requirement - data protection, financial reporting, health and safety records - an unsupported system is a liability beyond IT. Auditors and insurers increasingly ask about patching and support status directly, and "it still works" is not an answer they accept.

Growth compounds the problem in a different way. A system built for fifty orders a month rarely fails gracefully at five hundred; it just gets slower, flakier and more dependent on manual fixes, right at the point the business can least afford the distraction. The NCSC's guidance on vulnerability management is a good plain-English reference for why unpatched systems specifically are treated as a security issue, not just an inconvenience.

What to do once you've recognised one

The instinct is often to replace everything at once. That's rarely necessary and often riskier than the problem it solves. The first useful step is simply establishing what the system actually does, who depends on it, and what would happen if it stopped tomorrow.

1. 01List what depends on it - other systems, spreadsheets, people, reports that feed the board.
2. 02Establish the real support status - is it patched, and by whom, and until when.
3. 03Identify the single points of failure - people and infrastructure, not just code.
4. 04Decide whether to replace, wrap, or retire it piece by piece rather than in one project.

That assessment is the starting point for any sensible plan, and it's exactly where we begin our legacy software modernisation work - understanding the risk before recommending a fix, rather than assuming a full rebuild is the only option.

Once you know what you're dealing with, a full rewrite is often the wrong first move. A staged approach - read more in our guide to legacy system migration - usually gets the risk down faster and cheaper than starting from a blank sheet.

When it isn't actually a risk yet

Not every old system needs urgent attention. If it's patched, documented, understood by more than one person, and isn't blocking growth or integration, leaving it alone is a perfectly reasonable decision. Spending money to replace something that works, purely because it's old, is its own kind of risk.

If you're unsure which category you're in, that's worth a short conversation before it's worth a project - see our pricing for how we scope that kind of assessment.