Digital Transformation Legacy Systems, Compared | Legacy Software Modernisation

There are two ways to begin, and they do not sit well together. The first approach manages the estate as a single portfolio: every system on the register receives a decision on a fixed cycle, the decision is written down, and the plan is refreshed before the next spending review. The other approach waits for a trigger, such as a supplier withdrawing support, a licence renewal arriving at a price the budget cannot carry, or an audit finding that marks the system in writing, and then works on that system alone. The portfolio route shows nothing for longer and costs less across a decade. The trigger route shows a result inside the current financial year and keeps everything outside its range exactly where it was. What follows does not argue for either. It compares the three artefacts each route leans on, so that the choice can rest on what those artefacts actually contain.

The three artefacts, each named as the particular thing it is

Managing legacy technology, published by the Government Digital Service, is a strategy menu for one system. It sets out five routes, retain, retire, re-host, repurchase and re-platform, and it states that which route or combination an organisation uses depends on its size and the complexity of its infrastructure. It is a decision aid. It is not a portfolio plan, and it ranks nothing.

The Legacy IT Risk Assessment Framework, described in the Cabinet Office Digital Handbook, is a qualitative self-assessment applied to an organisation. The handbook states that the Central Digital and Data Office developed the framework with departments to grade the criticality of legacy-related risk across government, and that all ministerial departments have been integrated into it. It ranks exposure across an entity. It selects no route for any system.

A published delivery case study is a narrative of one application. Aroopa's account of moving a client from a Microsoft Access database to MongoDB and rebuilding the interface as a web app and a mobile app is a clear example. It was written by the supplier that performed the work, after the work finished. It documents what one migration looked like. It says nothing about the rest of that client's estate.

Three artefacts, three units of work. Most disputes about digital transformation of legacy systems come from people holding one of these and believing they are holding another.

Each one manages the unit of work

The strategy menu takes a system. Each verb in it, including retain, applies to one object with a limit a user can set.

The risk framework takes an organisation. Its output is a location for the entity, and separate systems appear inside that location as contributors.

The case study takes an application, and often only the part of it the supplier touched. The database moved; the surrounding integrations, the reporting that fed the finance function, and the scheduled jobs that ran against the old schema may not appear in the narrative at all.

Who is expected to sign the decision

The strategy menu expects the organisation to sign. It asks for senior managers to understand the benefits of continuous improvement planning, and it says that a contract must require continuous improvement when a supplier does the work.

The risk framework expects a department to sign, because it is a self-assessment and departments run it. It provides a comparable view for those who can act on it.

The case study expects a client to sign a scope. That scope is written from the client's statement of need and the supplier's analysis of the existing system, which means the limit of the decision is set by what the client already knew to ask for.

What has to exist on paper before work is authorised

This is where the three diverge most sharply, and it is where the risk sits. The Managing legacy technology guidance is specific. It asks for a full and accurate register of data assets, checked regularly and made current. It asks for knowledge of the full extent of systems and infrastructure that the organisation can be confident in, and it acknowledges that many organisations are not confident, because infrastructure evolves over time and corporate knowledge of older systems is lost. It asks for skills in the IT team, and for a service model flexible enough to support new technology and the depreciation of legacy technology at the same time. OutSystems makes a related point in its guide to transformation: that legacy modernisation stalls on dependencies, unclear ownership and missing documentation, and that the practical response is a phased approach which modernises interfaces first and rebuilds or replaces on the strength of business value.

The risk framework asks for the assessment itself. Its evidence is the judgement of the people answering it.

The case study asks for enough understanding of the existing system to plan the migration. That is a lower bar than a register, and it is met far more often.

What each considers proof that the system has failed

The guidance shows the signs plainly: maintenance costing more than replacement, efficiency falling to the point where necessary service changes cannot be made, supplier support withdrawn, a contract due to expire, and risk that has grown too great to carry. Retaining a system past the best viable point of depreciation or replacement is where the guidance locates the higher costs and the higher risks.

The risk framework uses criticality as the measure. A system that breaks is one whose legacy risk is graded high enough to demand the attention of the company.

The case study uses difficulty and user experience as the measure. Aroopa's client found the system functional but hard to maintain and unfriendly to use, and that judgement, made by the client, started the work. It is a legitimate trigger. It is also a trigger that fires only for systems people touch often enough to complain about. The overnight job nobody looks at does not generate that complaint, and Impact My Biz notes in its review of legacy risk that old systems frequently cannot be integrated with modern platforms at all, which leaves their data isolated and their costs rising with no one feeling it week to week.

The three, compared on shared attributes

Attribute compared	Managing legacy technology (GDS)	Legacy IT Risk Assessment Framework (CDDO)	Published delivery case study
Unit of work	One system	One organisation, with systems ranked inside it	One application, often only part of it
Who signs	The organisation, through its own governance	The department, by self-assessment	The client, against a written scope
Evidence required first	Data asset register, infrastructure map, team skills, flexible service model	The completed assessment	Enough understanding of the existing system to plan the migration
Trigger treated as decisive	Maintenance cost, withdrawn support, contract expiry, unacceptable risk, depreciation point	Graded criticality of legacy risk	Maintainability and interface quality, as judged by the client
What remains afterwards	A continuous improvement cycle	An assessment that can be re-run	A new platform and its support arrangements
Where it is weakest	Slow to produce a visible result	Does not choose a route for anything	Produces no estate-level view, and can start the next legacy system

What each one remains as a legacy

The strategy menu creates a cycle. Its entire aim is to prevent the estate from gathering the next generation of legacy technology by insisting on iterative or phased migration.

The risk framework provides a repeatable state. Change the estate and the location changes, and the framework can be run again without rebuilding it.

The case study includes a platform and a supplier relationship. Vega IT makes the point that modernisation is a continuous process and that the low-risk strategy improves core systems gradually while maintaining existing functionality. The same article mentions a client whose on-premise payment system was so complex that only one worker could manage it, which is precisely the risk that a current register and a plan for team skills are meant to catch before a single resignation turns it into an incident.

What to do with all three

Put every system you run in one group, with a manager in charge of each entry and the date of the last infrastructure review next to it. A register that is not reviewed is a register that will be wrong within a year, and the guidance is explicit that the reviews are what keep it usable.
Match the artefact to the decision in front of you. Use the strategy menu when you are choosing a route for a named system, the risk framework when you are ranking exposure across the organisation, and a case study when you want to know what delivery looked like somewhere else.
Set the review cycle before the first migration starts. The case study route delivers a new platform and a new support contract, and neither of those prevents the next system from ageing.
Grade the systems that no one complains about. The systems that generate complaints will be modernised eventually. Exposure accumulates in systems that fail quietly because no one can integrate them and no one is measuring them.

The fork at the top of this page resolves the same way in most organisations: Run the portfolio cycle and use the trigger to decide the arrangement of work inside it.