Your Supplier's Contract Has an End Date You Cannot Use. Here Is What the Public Record Shows.
We went through the public record on public systems that stay with the supplier that built them. A system can outlive its planned replacement by years, and most bodies cannot describe what they run. Here is what we found, the options, and the benchmark we would set.
The contract for the department’s grievance system ends in March. In September, procurement sends the head of IT a routine question: tender, or extend?
The head of IT thinks it through. A new firm would need months to learn the system, and there is no current document to give it. Every change since go-live is known only to the supplier’s team.
The note that goes up recommends an extension of two years, as the safer course. It is almost word for word the note that went up two years ago.
The paradox: The contract has an end date, and the department has no way to use it.
What We Found
For this article we went through the public record on public systems that stay with the supplier that built them: UK trade press reporting in 2025 on a supplier-built system at a large UK public body, the UK government’s own review of the state of its digital services, published in January 2025, and the UK digital department’s statements to Parliament, reported in June 2026.
First, what we did not find: no public case of an Indian public body, state department, municipal body or public utility locked to one supplier, and nothing from the Middle East. We also found no public case of a supplier refusing to hand over code or data to a public body, and we do not suggest that suppliers behave badly. Every body named below is far larger than the departments and boards we write for.
A supplier-built system can outlive its planned replacement by years. UK trade press reported in 2025 on a large UK public body’s supplier-built system, more than 25 years old, which may now run into the 2030s, later than its planned replacement. That is a possibility, not a fixed date. We did not examine why the replacement date moved and draw no cause from it. We use the record for one point only: how long one supplier’s system can stay in service.
Long tenure with few providers is common. The UK government’s own review found that councils’ children’s social care systems come from 3 main providers, and are used for a median of 10 years. Those are packaged products, which are not our kind of work. We use the figure only to show how long one arrangement can last.
Even the centre’s own record is partial. In a letter to a parliamentary committee, reported in June 2026, the permanent secretary of the UK’s central digital department, a civil servant, wrote that the existing “data is incomplete and uneven in coverage” on the government’s old systems.
Many people cannot say how big their old estate is. In the UK government’s own survey of more than 500 public-sector leaders across 120 organisations, “around 15% of survey respondents could not even estimate the size of their legacy estate”.
Our reading: the lock is not in the contract, which has an end date and often an exit clause. The lock is that only the supplier can say what the system does. A body that cannot describe its own system cannot show it to another firm or act on its exit clause, so each end date ends in an extension, and each extension adds changes only the supplier knows.
What our review does not show: We found no Indian public body and no body of our readers’ size on the record with this problem, and nothing from the Middle East. That body is a large national one; the record we read does not say what its contract provides or who holds its code, and we do not say. The council figure is about packaged products. The 15% is of the people who answered a survey, not of public bodies. We found no figure for what a change of supplier costs. That the lock is a matter of knowledge rather than contract is our reasoning, not a finding of any source. We make no comment on any government, body or supplier; we report what the record published.
What Waits on an End Date Nobody Can Use
A department that extends is not careless. Our reading is that four things cannot start while only the supplier can describe the system.
A tender cannot be written. Without a description of the work, every bidder prices a guess.
A quote cannot be compared. A change or a renewal is priced by the only party that can make it. The price may be fair; nobody can tell.
The exit clause cannot be used. It says the supplier will hand over and assist. It does not say what, and the department cannot list it.
Audit’s question cannot be answered. The department can explain each extension. It cannot show a step it took to make competition possible.
The gap we see: most public bodies we write for could say which of their systems a supplier built and runs. Few could hand another firm a current description of what each one does, list what the body holds and what it lacks, and set the cost of leaving beside the cost of staying. A body that holds that can use its end date.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Get a Description of Your Own System, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Ask the present supplier to write full documentation before the end date | The contract provides for it and the supplier has the time | The description is written by the party being left, and the department has no independent way to check it |
| Extend once more and plan to start earlier next time | The end date is weeks away and the service must not be disturbed | The same question returns at the next end date, with two more years of changes known only to the supplier |
| Officers write down what they know of the system | Experienced officers are still in post | It records screens and practice, not the rules inside the code, and officers are transferred |
| An assessment that reads the system itself and writes a specification the body owns, confirmed by its own officers | The department wants its next end date to be a real choice | It costs money before anything moves; it needs read-only code access, which the body arranges with its supplier, as its contract allows; and it does not end the dependence by itself |
Our recommendation: get the description before the end-date decision is due, from the system itself, and make it the body’s own. The body arranges read-only access to the code with its supplier, as its contract allows; getting that access is the body’s step, and we do not obtain code from a supplier. The supplier’s documents and the officers’ knowledge are useful inputs, not a description the department can check itself. We give no advice on what a contract provides, and we do not negotiate with a supplier.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| A written description of the system | A design document from the year it went live | A current specification the body owns, confirmed by its own officers | The specification |
| Who can say how the system behaves | Only the supplier | The body’s own team, from the specification | The specification |
| What the body holds and what it lacks | Not listed; “all materials” in the exit clause | Each item listed: what the body holds and what it would need | The risk register |
| Cost of leaving | Unknown | Set beside the cost of staying | The cost comparison |
| When the end-date decision is taken | A few months before the end date, with no alternative in hand | With the specification and the cost comparison in hand | The assessment report, dated before the decision |
The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a public body.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the system, the contract’s end date and what the body holds today. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is an application a supplier built for the body and still runs. The body arranges read-only access to the code with its supplier, as its contract allows. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. The specification is the body’s own, and it can show it to other suppliers, subject to its own contract with its present supplier. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
What we do not do: we do not get a body out of a contract, negotiate with a supplier, or give legal advice on who owns code, data or documents or on what a contract allows. We do not obtain code or data from a supplier; the body arranges access with its supplier, as its contract allows. We do not take over the running of the supplier’s system; the present supplier keeps running it. We do not replace or implement packaged products. We do not work in COBOL or assembly language or on mainframes. We do not say we are empanelled with any government, and we give no advice on procurement rules: how an assessment and the stages after it are bought is the body’s own decision. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | When the contract ends, extending it is a choice the department makes, not the only thing it can do. |
| Head of procurement | The next tender can describe the work, so more than one firm can bid, and the exit clause means something. |
| Head of IT | A specification the department owns, which makes a second opinion or a second supplier possible. |
| Head of finance | A quote for a change or a renewal can be set against something. |
| Head of audit and vigilance | When audit asks why the contract was extended without competition, the department can show what it did to make competition possible. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large UK public body: a supplier-built system, more than 25 years old, which the trade press reported in 2025 may now run into the 2030s. | We make no comment on that body or its supplier, and our part is far smaller than a national system. For an application a supplier built for a public body, we write a specification the body owns and can show to other suppliers. |
| The UK government’s own review: councils’ children’s social care systems from 3 main providers, used for a median of 10 years. | We do not replace packaged products. For applications a body had built for it, the specification we write is the body’s own, and it can show it to other suppliers, subject to its own contract with its present supplier. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by writing down what your system does, so the next end date is yours to use.
Sources
In this issue
Locked to one supplier
Research note 2
Your Contract's End Date Means Little Until You Can Describe Your Own System. Four Ways Forward, Weighed.
Many public systems can be described only by their supplier. Four ways forward at a contract's end date, weighed, and what each one risks.
Research note 3
Leaving Your Supplier Does Not Have to Be One Handover Day. Here Is the Benchmark We Would Set.
A change of supplier planned as one handover day is easy to defer. We weigh four ways to leave and set out the benchmark we would agree before any module moves.
Issue study
Only the Supplier Can Describe It
Public systems that stay with the supplier that built them: how long such ties last, what public bodies know of their own systems, options, benchmark.
More from Government and public sector
Replacement fails or overruns
A Deferred Replacement Is Still a Decision. Four Ways to Replace an Old System, Weighed.
Thin or missing documentation
A New Officer Takes Charge of Your System With Nothing to Read. Three Ways to Change That, Weighed.
Wrong outputs trusted as correct