Legacy is about what you can’t explain, not only how old it is

Government has been candid about legacy IT. The Government Cyber Action Plan, published in January 2026, puts legacy at around 28% of the technology estate. A March letter to the Science, Innovation and Technology Committee acknowledged that the data was incomplete, with thousands of non-critical systems still unidentified. A House of Lords answer in April said reporting under the previous assessment framework was suspended in 2025. That is not a criticism. Large estates behave this way. Counting is the right place to start, but it carries a risk. 

Legacy, as normally counted, is a property of the system: its age, whether it is still supported. Unsupported systems are a genuine risk, as the Action Plan says. But what makes legacy dangerous is a property of the organisation: how much of what the estate does can no longer be explained. Picture a forty-year-old platform with every connection documented, beside a three-year-old cloud environment with hundreds of firewall rules nobody can tie to a service. The first is a known risk. The second is not, whatever the asset register says. We call that gap, between what an estate does and what you can account for, governance debt. 

It matters because of how programmes are measured. If success is the number of systems retired, systems will be retired. That number says nothing about whether the replacement is better understood than the original, and during migration it often isn’t. Old and new run side by side for longer than planned. Connections are added to make cutover work. Exceptions are granted to hit a date. A rule opened “temporarily” is often the most permanent feature of a network. 

The old system knows things nobody wrote down 

Older systems are often held together by dependencies no document records: a month-end job, a route a supplier needed years ago, a flow that appears only at financial year end. Documentation records intent. Traffic records behaviour. Before cutover, build your picture of dependencies from the live estate, not from memory. Ask finance and service owners for the calendar peaks, then plan the capture window to cover them, because a fortnight will miss anything quarterly or annual. Treat every flow you cannot explain as something to resolve before the move, not a risk to carry across. 

Measure what you can account for 

Four habits help. 

Give every temporary exception an expiry date and an owner who is told when it lapses. Fund the switch-off as a deliverable in its own right, because projects are paid to go live and the people who understood the old system have often moved on by the time anyone closes it. Use one route for change across old and new, including changes made by suppliers, so the record and the live estate do not drift apart. And name, in the contract, who is accountable at each join between suppliers. The test is blunt: if it breaks at 2am during cutover, who finds out why? 

A better headline measure than systems retired is the proportion of your rules, routes and connections that you can tie to a named service and a named owner. If that rises through a migration, you are paying debt down. If it falls, you are building the next legacy while retiring the last. 

Cloud Gateway runs network and security as one managed platform for regulated organisations, so for the services in scope there is one change process and one accountable party. If you are mid-migration and want to compare notes, we would be glad to talk.