Legacy Is a Risk Problem, Not an Age Problem

When we describe a system as “legacy”, the conversation often starts with its age.

I think that’s increasingly the wrong place to start.

Government updated its definition of legacy IT in August, alongside the framework used to assess legacy risk across departments.

The indicators are much more useful than simply asking when a system was built. They include technology being out of support, difficult to update, dependent on scarce skills, unable to meet current or future business needs, affected by known vulnerabilities or experiencing reliability problems.

That distinction matters for architecture.

A twenty-year-old system that is stable, understood, supported and relatively easy to change may present less immediate risk than a five-year-old platform that nobody fully understands and cannot be safely modified.

And moving something to the cloud doesn’t automatically make it modern. Government’s own Cloud Challenge Book notes that some of its legacy estate is already cloud-based.

So the better question is not:

How old is the technology?

It is:

What risk does this technology create for the service?

That changes the modernisation conversation.

Start with the service the system supports.

What happens if it fails? Who depends on it? Where does its data go? Which other systems rely on it? How difficult is it to recover? And what changes are currently being avoided because nobody wants to touch it?

Then look at the constraints.

Perhaps the problem is unsupported software.

But it might equally be undocumented integrations, poor data quality, a supplier dependency, specialist knowledge held by two people, or business processes that have gradually been built around the limitations of the system.

Those aren’t simply technology problems.

They are architecture and operating-model problems.

This is also why “replace the legacy system” can be a poor starting objective.

Replacement may be right. But so might retirement, simplification, re-platforming, extracting a capability, improving an interface or removing a business process that no longer needs to exist.

The architecture decision should follow the risk and the service outcome, rather than assuming every old platform needs a like-for-like successor.

There is another point I think matters.

Legacy remediation competes for funding against visible new capabilities. A new digital service or AI initiative is easier to explain than replacing infrastructure that users may never see.

A risk-based view gives architects a better way to make that case.

Not:

“We need £10 million because this platform is old.”

But:

“This service supports a critical outcome, has these dependencies, cannot be safely changed, relies on unsupported components and creates this level of operational and security exposure.”

That’s a much stronger investment conversation.

Government’s updated framework is useful because it pushes the discussion in that direction.

Legacy isn’t defined by when a system was built.

It is defined by the risk created when the organisation can no longer change it safely.