Legacy IT and commercial contracts: the government guidance, explained

The key facts

• The guidance was published on 28 March 2022 and supports the Digital, Data and Technology Playbook.
• Legacy IT covers infrastructure, systems, software, hardware and related business processes that are end of life, out of support or on extended support, impossible to update, no longer cost effective, or above acceptable risk thresholds.
• Legacy IT is presented as a multi billion pound problem affecting cyber and national security, operational resilience, digital transformation and value for money.
• Policy 1 asks departments to assess and prioritise high risk legacy IT and to build the cost and time of preventing future legacy into business cases, rather than trading those elements away for a short term saving.
• Business cases for legacy remediation should consider longer return on investment periods of five years or more and recognise wider benefits such as securing service delivery, enabling future transformation and the ability to attract staff.
• Policy 2 requires contracts to oblige suppliers to keep all software on supported versions that meet the authority's requirements throughout the contract and any extensions, including upgrades, updates and new releases, with deviations requiring written approval from the contracting authority.
• Twelve guidelines cover supplier product alignment, planning, ring fencing savings, direct awards, outcome based contracts, future proofing measures, management tools, supplier risk management, asset records, open standards, government technology standards and contract exit planning.
• Commercial pipelines should look ahead three to five years, with a minimum of 18 months, and teams should avoid extended or re tendered as is contracts which can lead to the build up of legacy IT.

What this guidance is and who it applies to

This is Cabinet Office guidance on the commercial and supplier management approach to mitigating and preventing legacy IT, published on 28 March 2022 to support the Digital, Data and Technology Playbook. It is written for commercial teams and their digital colleagues in government organisations, and it treats legacy IT as a commercial problem as much as a technical one. The premise is blunt: a significant number of new digital, data and technology proposals exist to solve legacy issues, and government has committed to invest in current technology and replace legacy systems that are overly complex and difficult to use.

The guidance defines legacy IT as infrastructure, systems, software, hardware and the related business processes that have become obsolete. Obsolescence is described in practical terms: products that are end of life, out of support or on extended support, impossible to update, no longer cost effective, or carrying risk above acceptable thresholds. That definition matters commercially, because it means an asset can be legacy while it is still working.

Four impact areas are set out. Cyber and national security, where old and unpatched vulnerabilities create exposure. Operational resilience, where critical service delivery can fail. Digital transformation, where incompatibility between systems slows innovation. And value for money, where scarce specialist skills for obsolete technology command a premium. The guidance sits alongside the Digital, Data and Technology Playbook, the Sourcing Playbook, the Technology Code of Practice, the Service Standard, the Green Book and commercial pipeline guidance.

The two policies: business cases and keeping technology current

Policy 1 asks departments to reduce legacy IT through business cases and contract management. Departments should assess their legacy IT so that high risk items can be prioritised, and business cases should include the costs and the time needed to deal with future legacy accumulation, including maintaining software versions and upgrading hardware. The guidance warns explicitly against trading away those cost and time elements to gain a short term saving, which is exactly how legacy is created in the first place.

Business cases are also expected to reflect the real economics of change. Dual running costs while systems are transitioned, whole asset lifecycle costs, decommissioning expenses and continued investment in innovation to keep technology current all belong in the case. Where the business case is specifically about remediating legacy, the guidance says to consider longer return on investment periods of five years or more, and to recognise the wider benefits: securing departmental service delivery, enabling future transformation and the ability to attract staff, alongside avoiding the costs that legacy itself causes.

Policy 2 is the contractual half. Contracts must oblige suppliers to ensure all software is on supported versions and meets the authority's requirements throughout the contract and any extensions, covering upgrades, updates and new releases. Where a deviation is needed, it should require written approval from the contracting authority. This turns technology currency from an assumption into an enforceable obligation with a named decision point.

The twelve guidelines in practice

The first group is about planning and market posture. Guideline 1 asks teams to work with IT suppliers so that sourcing plans align with available supplier product and service plans and future roadmaps. Guideline 2 asks commercial teams to work with chief digital and information officers so that IT strategy, strategic plans and enterprise architecture are communicated to potential suppliers. Guideline 3 suggests ring fencing IT cost savings to fund legacy remediation rather than cashing them in. Guideline 4 restricts direct awards to cases with a compelling case and only after taking legal advice, for example where lock in makes changing supplier prohibitively expensive. Guideline 5 encourages outcome based and gain share contracts that share risk and reward on remediation and involve suppliers early.

The second group is about what goes into the contract. Guideline 6 sets out future proofing measures: intellectual property owned by the party best able to use it, evergreen provisions that keep software on currently supported versions, supplier risk management and reporting on end of life status, asset management covering all digital and data assets, data extract and sharing capabilities in open formats, key performance indicators for legacy mitigation and remediation, and compliance with government technology and service standards. Guideline 7 covers IT demand management and cost optimisation tools that identify underused resources, match system usage to need and use analytics to avoid unexpected spending.

The third group is about assurance and standards. Guideline 8 requires suppliers to run risk management processes and report on cyber and national security risks associated with legacy IT, to support independent reviews of mitigation status, and to evidence compliance with evergreen provisions, with at least one member of the supplier's UK management team holding digital, data and cyber expertise. Guideline 9 requires suppliers to maintain an up to date view of digital and data assets, through an asset inventory and configuration management database covering hardware, software, data and services and how they interoperate. Guideline 10 requires data extraction and sharing with the contracting authority using open standards mandated or recommended for government use, improving interoperability and the potential for reuse by other departments. Guideline 11 requires alignment with government digital policy including the Technology Code of Practice, the Service Standard and API standards, with examples such as enabling code reuse, low code solutions for software and REST APIs.

Guideline 12 closes the loop with exit planning. Contract updates and transitions should be planned by looking three to five years ahead in the commercial pipeline, with a minimum of 18 months. Extended or re tendered as is contracts are called out as a route to legacy build up. Where a system is being replaced, dual running should be planned, and closure or migration should be timely so the organisation moves towards a simplified, legacy free IT landscape.

What this changes and why it matters

The change is where responsibility sits. Under this guidance, keeping technology current is not something a department does between contracts, it is something the contract requires while it is running. Evergreen provisions, supplier reporting on end of life status and written approval for deviations move the conversation from an annual technical debt discussion to a contractual obligation with evidence attached.

It also changes how savings are read. If a business case wins approval by removing the cost and time of maintaining software versions and upgrading hardware, the guidance treats that as storing up a larger bill, not as efficiency. The instruction to ring fence IT cost savings to fund remediation points the same way: money released by better technology management should be reinvested rather than absorbed.

Finally, it makes exit and pipeline planning part of legacy prevention. Looking three to five years ahead, avoiding as is extensions and planning dual running are commercial disciplines, not technical ones, and they are the practical difference between replacing a system and renewing the problem.

Practical application

Start with visibility. An assessment of existing legacy IT, prioritised by risk, is the precondition for everything else, and it depends on knowing what assets exist. That is why the guidance puts asset inventories and configuration management databases into supplier obligations rather than leaving them as internal wishes.

Then fix the contract template. The clauses that matter are specific: supported software versions throughout the contract and extensions, written approval for deviations, intellectual property allocated to the party best able to use it, supplier risk reporting on end of life technology, open standards for data extraction and sharing, key performance indicators for legacy mitigation, and compliance with the Technology Code of Practice and Service Standard. Adding these once to a standard set is far cheaper than negotiating them contract by contract.

Finally, run the pipeline properly. Publish a forward view of three to five years, at least 18 months, so replacements can be planned rather than defaulted into. Where the honest answer is that the organisation is locked in, the guidance allows a direct award only with a compelling case and legal advice, which is a high bar and should read as a prompt to plan the exit rather than a route to repeat it.

How eSourcing Data helps

eSourcing Data gives commercial teams a place to hold the evidence this guidance asks for. Sourcing decisions, market engagement with suppliers about product roadmaps, the legacy assessment that informed prioritisation and the reasons behind any direct award can be recorded against the procurement, so the case for a decision exists in the record rather than in a mailbox.

The platform also supports the contractual half. Requirements and clause sets covering supported software versions, evergreen provisions, intellectual property allocation, open data formats and government technology standards can be applied consistently across procurements, and evaluation can test them rather than treating them as boilerplate. Once contracts are live, supplier risk reporting, end of life status returns and key performance indicators for legacy mitigation can be captured and tracked in one supplier management view.

Reporting closes the loop that exit planning depends on. Because contract dates, values, extension options and supplier records sit together, teams can build the three to five year forward pipeline the guidance expects, see which contracts are heading for an as is extension and plan replacement early enough to avoid renewing the legacy.

What to do about it

1. 1Assess and prioritise existing legacy IT by risk, so that the highest risk systems get the first call on funding.
2. 2Build the cost and time of preventing future legacy into business cases, including dual running, lifecycle and decommissioning costs, and resist trading them away for a short term saving.
3. 3Use longer return on investment periods of five years or more for legacy remediation cases and set out the wider benefits, including service delivery, transformation and staff attraction.
4. 4Add a clause requiring supported software versions throughout the contract and extensions, with written contracting authority approval for any deviation.
5. 5Add future proofing terms: intellectual property to the party best able to use it, evergreen provisions, supplier risk reporting on end of life software, asset inventory obligations, open format data extraction and legacy key performance indicators.
6. 6Require suppliers to align with the Technology Code of Practice, the Service Standard and government API standards, and to name management accountability for digital, data and cyber risk.
7. 7Publish a commercial pipeline looking three to five years ahead, at least 18 months, and plan replacement rather than as is extension or re tender.