Legacy System Modernisation in the UK: You Don’t Have a Technology Problem

Every UK organisation running legacy infrastructure knows the shape of the risk. The system works until the one person who understands it retires.

The vendor support window closes. The security team flags an OS that stopped receiving patches years ago. Integration with anything modern requires a small miracle. And the annual cost of simply keeping it alive climbs, quietly, every year.

What is discussed less honestly is why modernisation programmes stall. It is rarely the technology. Migration patterns for ageing databases, monoliths, and on-prem estates are well understood; reference architectures exist; and the tooling is mature. UK modernisation programmes fail specifically on people, on the assumption that the team that operates a legacy system can also be the team that replaces it.

Why in-house teams get stuck

This is not a criticism of in-house engineers. It is arithmetic and incentives.

The people who know the legacy system are fully occupied running it; that is why it still works. Asking them to modernise it on top is asking for both jobs to be done badly. Meanwhile, the skills a migration needs at its core target-state architecture, data migration at scale, cutover design, and modern platform engineering are needed intensely for twelve months and then barely at all. That profile fits almost no one for a permanent hire.

And hiring for it is brutal anyway. Senior engineers with genuine migration scars are among the scarcest profiles in the UK market, they command salaries that are hard to justify for a time-boxed need, and a recruitment cycle can consume six months before anyone writes a line of code. Recruit a strong one for a role that is 30% legacy maintenance and they leave; recruit a junior and you have handed your riskiest programme to someone learning on the job.

So organisations do the rational-seeming thing: defer. And deferral has a price that compounds rising run costs, deepens key-person risk, and widens security exposure as unsupported components accumulate. IBM’s most recent Cost of a Data Breach research puts the average UK breach in the millions of pounds; legacy estates, with their unpatched edges and forgotten interfaces, are where those incidents disproportionately start.

The pattern that works

The modernisation programmes that finish share a structure.

Senior engineers own the migration; the in-house team keeps the lights on and learns the target state as it is built. The programme is outcome-scoped “these workloads, off that platform, by this date, at this run-rate” not staffed as an open-ended augmentation. The sequence is risk-first: the components with the worst security exposure and key-person concentration move early, not the easy wins that make the first quarter’s slides look good. And crucially, the engagement ends. The destination is an estate the internal team can run, documented and handed over not a permanent dependency on outside help.

The common thread is seniority. Legacy migration is nine-tenths judgement: what to move as-is, what to re-engineer, what to retire outright, and in which order nothing breaks. That judgement is exactly what cannot be delegated to junior execution, however well supervised.

Where to start when everything looks urgent

If the whole estate feels like a problem, begin with a discovery exercise that answers four questions per system: what breaks if it fails for a week, who is the only person who understands it, when does its platform lose support, and what does it actually cost to run licences, infrastructure, and the people-hours spent nursing it. Plot those answers, and the sequence usually writes itself. Most estates contain two or three systems whose risk concentration dwarfs everything else, and one or two that should simply be switched off, retired outright, have their function absorbed elsewhere, or be revealed to have no function at all. Decommissioning is the most underrated move in modernisation: every system you retire is one you never have to migrate, patch or explain to an auditor again.

Discovery of this kind takes weeks, not months, and it converts an anxious, open-ended “we should modernise” into a costed, sequenced programme a board can approve. It is also the cheapest possible way to find out whether your problem is as big as it feels sometimes it is smaller; occasionally it is worse and better known than discovered mid-incident.

Buying judgement without buying headcount

This is the model Human operates. Senior infrastructure and data engineers no juniors, no bench deployed onto your legacy problem in weeks, working under your brand where that matters, accountable to the outcome you scoped. When the migration is done, the engagement is done. No recruitment fees, no six-month lead time, no permanent salary for a temporary need.

For a finance-aware leader, the comparison worth running is simple: the fully-loaded cost of an outcome-scoped senior engagement against the sum of another year of legacy run costs, the risk you are carrying in the meantime, and the price of a failed attempt with the wrong team. Legacy systems age in one direction only. The question is whether you modernise on your schedule or the incident’s.

Have a legacy estate that needs senior attention?

Contact david@designbyhuman.com.