Legacy IT is a contracting habit, not a technology accident
Nobody sets out to build legacy IT. It arrives the way most expensive problems arrive, one reasonable decision at a time: a business case trimmed to fit an envelope, an extension signed because the replacement was not planned, a contract that assumed the supplier would keep things current without ever saying so. The government guidance on the commercial and supplier management approach to mitigating and preventing legacy IT is unusual because it puts the blame where the fix is, in commercial practice, and then names the specific clauses and habits that create the problem.
The savings that cost the most
The guidance contains one line that should be pinned above every approval board: do not trade away the cost and time elements of maintaining software versions and upgrading hardware to gain a short term saving. That is the mechanism. A business case is written honestly, it includes the money and the months required to keep the technology current over its life, and then those are the first things removed when the number needs to come down. The system still gets built. The maintenance does not.
The counterweight offered is a different accounting horizon. For legacy remediation, the guidance says to consider return on investment periods of five years or more and to count benefits that do not usually appear on a savings line: securing departmental service delivery, enabling future transformation, the ability to attract staff. These are real, and they are the ones that go missing when a remediation case is judged against the same payback window as a procurement of stationery.
There is a practical suggestion attached. Ring fence IT cost savings so they fund legacy remediation rather than being cashed in elsewhere. That only works if someone decides it in advance, which is a commercial decision, not a technical one.
What most organisations get wrong
The first mistake is assuming currency. Plenty of contracts are silent on whether the software an authority depends on has to remain a supported version. The guidance closes that gap directly: contracts should oblige suppliers to ensure all software is on supported versions and meets requirements throughout the contract and any extensions, including upgrades, updates and new releases, with deviations requiring written approval. Without that clause, staying current is a favour. With it, drifting out of support is a breach and someone has to sign for it.
The second is not knowing what you own. Guideline 9 asks suppliers to maintain an up to date view of digital and data assets through an inventory and configuration management database covering hardware, software, data, services and how they interoperate. Organisations that cannot answer what is running and what it depends on cannot prioritise by risk, which means remediation funding goes to whatever is loudest rather than whatever is most dangerous.
The third is the as is extension. The guidance is explicit that extended or re tendered as is contracts can lead to the build up of legacy IT, and it asks for pipelines that look three to five years ahead, at least 18 months. An extension signed twelve weeks before expiry is not a commercial decision, it is the absence of one, and it typically locks the same architecture in for another term.
Lock in is a design choice
Several of the twelve guidelines are really about keeping the exit open. Intellectual property should sit with the party best able to use it. Data extraction and sharing should use open standards mandated or recommended for government, which the guidance links to interoperability and reuse by other departments. Suppliers should align with the Technology Code of Practice, the Service Standard and API standards, with REST APIs called out as making data easier to move and share.
None of that is abstract architecture policy. Each one is the difference between a competitive re procurement and a conversation where the incumbent knows you cannot leave. The guidance allows direct award where there is a compelling case and legal advice has been taken, and it gives lock in as an example where changing supplier would be prohibitively expensive. That is an accurate description of reality and a warning at the same time: every direct award justified by lock in is the receipt for a contract that was written without an exit.
What good looks like
Do the unglamorous things first. Assess what you have and rank it by risk. Fix the standard contract once so that supported versions, evergreen provisions, intellectual property allocation, supplier risk reporting on end of life software, asset inventories, open data formats and legacy key performance indicators are in every technology contract by default, not negotiated one at a time.
Then manage the contract as though the technology will age, because it will. Take the supplier risk reports seriously, expect named management accountability for digital, data and cyber risk, and use demand management and cost optimisation tools to see underused capacity before it turns into a renewal.
And plan the ending at the beginning. Put the contract in a pipeline that runs three to five years out, decide what replacement looks like while there is time to compete it, and budget for dual running so migration does not stall halfway. Legacy IT is what happens when the exit is left to the last eighteen months. This guidance is essentially a list of the moments where that can be prevented.
The takeaways
- Legacy IT is created commercially, usually by removing maintenance cost and time from a business case to hit a number.
- Contracts should require software to stay on supported versions throughout the contract and extensions, with written approval for any deviation.
- Suppliers should maintain asset inventories and report on end of life risk, so remediation can be prioritised by risk.
- Open standards, API alignment and sensible intellectual property ownership are the practical defences against lock in.
- Pipelines of three to five years, and avoiding as is extensions, are what stop the same architecture being renewed indefinitely.
Want the full breakdown?
The complete explainer covers the key facts, the requirements in detail and a practical action list, free and printable in the Procurement Library.