Legacy System Modernisation

This page is our guide to the subject. We are an independent publication. We write, explain, compare, check, cite and correct. We sign this page and we stay behind it.

What makes a system legacy

A system is not legacy because it is old. It is legacy when it constrains the organisation. The Catapult's guide to legacy system modernisation takes this view and details the material conditions: the system cannot be changed safely or quickly, it depends on unsupported technology, it requires scarce skills, it cannot integrate with newer services, it creates recurring incidents, or it blocks new products. Age may correlate with those conditions. Age does not cause them.

The Cabinet Office Digital Handbook takes a similar line. Legacy IT systems are often outdated and difficult to maintain, which can hinder the delivery of effective public services. The handbook points to the Legacy IT Risk Assessment Framework, a qualitative risk-based approach developed with departments to evaluate the criticality of legacy-related risks. The framework is not a scoring model for technology fashion. It is a way to decide where the risk actually sits.

The first decision is whether to modernise at all

The cheapest and lowest-risk modernisation route is often not modernising. GOV.UK's managing legacy technology guidance says the right time to migrate depends on the organisation. It shows the reasons that typically justify migration: the cost of maintaining old technology exceeds replacement, reduced efficiency blocks necessary service changes, supplier support has ended, a contract is due to expire, or the risk of maintaining the system has become too great.

That inventory matters because it prevents modernisation from becoming a default. If none of those reasons applies, the correct decision may be to retain the system, monitor it, and spend the money elsewhere. Catapult makes the same point: a stable system that continues to meet business needs may not require major intervention. Retention becomes a problem only when it is an indefinite delay caused by uncertainty rather than a deliberate decision.

Know the estate before you change it

You cannot modernise what you cannot describe. GOV.UK's guidance sets out principles that bear directly on risk. The organisation should build a complete and accurate register of its data assets, and it should know the full extent of its systems and infrastructure. In many cases, the guidance says, organisations are not confident that they have all of the information. The reasons are ordinary: Infrastructure evolved over time, corporate knowledge of older systems was lost, and documentation was never written or never stayed current.

The Cabinet Office Digital Handbook points to the same guidance, which also emphasises continuous improvement planning, building IT team skills, and having a flexible service model. The practical consequence is that discovery is not a preliminary phase you can skip. It is the first control on the risk register. Map the dependencies. Record the data. Find the people who still understand the system. Then decide.

The strategy set, and what each route changes

Modernisation is a portfolio decision, not a single route. The common framework, set out by GOV.UK and described in similar terms by Google Cloud, includes these options:

The terms differ between frameworks. The decision is the same. Which route removes the constraint that justified the investment, at a level of risk the organisation can carry? Re-hosting may fix an infrastructure problem without touching application debt. Re-platforming may preserve working business logic while moving off an unsupported runtime. Refactoring may be enough when the system has strong value but specific brittle components. Re-architecting is for structural constraints. Replacement is for systems that cannot be changed safely or cannot meet compliance obligations that cannot be retrofitted.

Where the risk actually sits

Data migration is usually the highest-risk part of the work. Catapult's guide explains why: legacy data contains duplicate or incomplete records, inconsistent formats, undocumented transformations, historical exceptions, and dependencies that are invisible in the application code. A migration plan must define what is migrated, retained, archived or deleted; how source and target models correspond; which quality rules must be met; how scripts are tested repeatedly; how records are reconciled; and what rollback or recovery process applies if validation is unsuccessful. Running old and new capabilities in parallel can reduce risk, but parallel operation creates its own synchronisation and support overhead, so it needs a defined end date.

Integration carries similar weight. Google Cloud's guidance on legacy modernisation says containerisation is a lower-risk entry point. Packaging an application with its dependencies into a portable unit decouples it from the underlying hardware and operating system. That allows the application to run on managed infrastructure before deeper refactoring begins. The same guidance says that APIs can expose legacy functionality without changing the core system. Both moves buy time and reduce the blast radius of change. Neither removes architectural debt on its own.

Organise the work in phases

GOV.UK's first principle for managing legacy technology is continuous improvement planning. The guidance suggests iterative or phased migration to prevent the accumulation of future legacy technology. The benefits are gradual retirement of technology, reduced risk to systems and infrastructure, focus on reducing legacy technical debt, and reduced risk to the migration itself. Continuous improvement planning requires extra effort in documentation, compatibility checks, and the use of architects and senior technical staff to review what has changed.

Future Processing's overview of modernisation approaches explains the same discipline in delivery terms. The Strangler Pattern introduces new system components gradually while the legacy system continues to run. Pilot testing, rollback plans, and deployment during non-peak hours reduce the risk of downtime. Automated migration tools, data validation, and backup strategies reduce the risk of data loss. The point is not to choose one technique. The point is to make change reversible where possible, and to keep the old system available until the new one has proved itself.

Commercial and supplier management

The commercial work is not procurement at the end of the programme. It is the design of the contract that keeps the system current. The Cabinet Office Digital Handbook summarises guidance from the Government Commercial Function on mitigating and preventing legacy IT. That guidance focuses on strategic contract management with suppliers, including clauses that mandate regular updates and maintenance, so that systems do not become obsolete during the contract term. It also calls for forward planning and commercial strategies that support long-term modernisation goals.

GOV.UK's managing legacy technology guidance shows the non-technical blockers that often decide the outcome: business and culture, commercial decisions and spending models, financial limits, guidance and policy, resources and responsibilities, use of multiple suppliers, contractual arrangements and exit strategies, aversion to risk, competing priorities, and legislative or ministerial requirements. None of those is a technology problem. All of them can stop a technically sound migration.

What the figures show

The table below collects selected figures from Red Eagle's 2026 UK guide to legacy software modernisation. We include it as reference material, separate from the argument above.

Source: Legacy Software Modernisation UK (2026 Guide: AI & Costs), Red Eagle.

Those figures are not a business case. They are a reason to build one. A risk-averse programme uses them to test assumptions, not to justify a decision already taken.

What we would check before signing off a modernisation plan

We would check that the estate is documented. We would check that the data asset register is current. We would check that the chosen route removes the constraint that justified the spend. We would check that the migration has a rollback path and a reconciliation process. We would check that the contract keeps the new system current. We would check that the people who understand the old system are involved in the change. We would check that the business case includes the cost of doing nothing, because that cost is real even when it appears on no invoice.

Legacy system modernisation is not a technology upgrade with a business case attached. It is a controlled change to systems that the organisation depends on. The publication argues that the work should be done deliberately, in phases, with the evidence in front of the people who carry the risk. That is the standard we hold this page to, and we will correct it when the sources change.

This page is maintained by the publication. We will correct it as the sources change.

Sources

• Legacy Systems - Cabinet Office Digital Handbook
• Managing legacy technology - GOV.UK
• Legacy system modernisation: challenges and common approaches - Future Processing
• Legacy System Modernisation: Strategies, Risks & Best Practices - Catapult
• What is legacy modernization? How does it work - Google Cloud
• Legacy Software Modernisation UK (2026 Guide: AI & Costs) - Red Eagle