Only the Supplier Can Describe It

1. At a Glance

Issue study · From the public record. None of the bodies named here was an IOanyT client, and IOanyT had no part in the events described. All are far larger than the departments, municipal bodies, utilities and boards we write for. We found no public record of an Indian public body, or of a body of our readers’ size, locked to one supplier, and no public case of a supplier refusing to hand over code or data to a public body. We do not suggest that suppliers behave badly. Each case is reported as the public record gives it, without judgement on any government, body, official or supplier.

Organisation type	A supplier-built system at a large UK public body, set beside the position of a mid-size public body whose main application was built, and is still run, by one supplier
Size band	The cases: national. Our reader: a state department or directorate, a municipal corporation or council, a public utility, a board or authority, or a public-sector undertaking
Region	The cases: UK and US, with one Indian source on e-services. The reader: anywhere
The decision at stake	What to do as a contract’s end date comes near, when only the supplier can describe the system: extend, re-tender without a description, negotiate a handover from the supplier, or have the body’s own specification written first and then leave in stages
The public outcome	A large UK public body’s supplier-built system, more than 25 years old, which the trade press reported in 2025 may now run into the 2030s, later than its planned replacement; a possibility rather than a fixed date
Why it matters to a mid-size public body	If a national system can stay with its supplier for decades, a smaller body’s system can too. Without its own description of the system, a body cannot use its end date, compare a quote or answer audit’s question about competition

2. The Business Problem, in the Buyer’s Words

“The contract for our grievance system ends in March, and procurement wants to know whether to tender or extend. The supplier built the system fourteen years ago and has run it ever since. The source code is on its servers, and so is the database. Our design document is from the year it went live. The state wants the system joined to its unified portal, and our only answer is that we will ask the supplier. The extension note is the same one we signed two years ago. I do not doubt the supplier. I just cannot describe our own system to anyone else.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The body is caught between a contract it cannot use and a supplier it cannot replace, because only the supplier can say what the system does.

3. What We Found

Method. 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 its digital services (January 2025), statements by the UK digital department to Parliament (reported in June 2026), the US national auditor’s July 2025 report on the most critical federal legacy systems and press coverage of it, and a written answer in India’s Lok Sabha in December 2025 on e-services in the states and union territories. The sector research behind this study holds no Indian public body and no body of our readers’ size locked to one supplier.

A supplier-built system that outlived its planned replacement. 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. The record we read does not say what the contract provides or who holds the code, and we do not say.

How long such arrangements last. The UK government’s own review, published in January 2025, found that councils’ children’s social care systems come from 3 main providers, and are used for a median of 10 years. These are packaged products, which IOanyT does not replace; we use the figure only to show how long one arrangement can last.

What bodies know of their own systems. In a letter reported in June 2026, the permanent secretary of the UK’s central digital department, a civil servant, wrote to a parliamentary committee that the existing “data is incomplete and uneven in coverage” on the government’s old systems. 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”.

How long leaving takes. Six years after the US national auditor named the 10 most critical federal legacy systems in 2019, press coverage of its July 2025 report found that 3 of those modernisations had been completed. For one, at the US health department, officials told the auditor in March 2025 that they now expect to complete the modernisation in fiscal year 2035, five years later than the original plan, and put the change down to funding availability. Some of the auditor’s systems are in COBOL and assembly language, which are not IOanyT’s kind of work.

What public bodies are being asked to do next. In a written answer in the Lok Sabha on 10 December 2025, the government said: “Between April 2023 and October 2025, the number of e-services offered by States/UTs increased from 11,614 to 23,919, which is over 105 % growth.” The same answer said: “At present, there is no API integration between CPGRAMS and State RTS systems.” CPGRAMS is the central public-grievance system; the RTS systems are the states’ Right to Services systems. The answer does not say why the systems are not connected, which systems are old, or who built them. That a system only its supplier can describe makes such connections harder is our reading.

Our reading of why the lock holds. These four are our reasoning from the record above. None is a finding of any source.

1. Only the supplier can describe the system. The body holds no current specification, so it cannot write a tender another firm could price, or check a quote.
2. Handover is left to the end. Code, database and documents are to be handed over when the contract ends, and each extension moves the end.
3. The question is asked too late. It comes up a few months before the end date, when extension is the only safe answer.
4. The only exit on offer is one handover day. A single switch-over, timed to the contract’s end, puts the whole service at stake, so the body stays.

4. The Options a Body in This Position Had

Option	When it fits	What it risks	Our view
Extend the present contract	The service is stable, the supplier serves it well, and no new demand is coming	The same question returns at the next end date; new demands still go through one firm	Right when chosen with an alternative priced; not as the only course
Re-tender the whole system without a description	The system is simple enough to describe in a few lines	Bidders price a guess; the winner must learn the system from the firm it replaces	Right only for a small, simple system
Negotiate a handover of code, data and documents from the supplier	The contract provides for it and the supplier cooperates	The handover is described by the supplier; the body has no description it has checked itself	A useful input; what a contract provides is for the body and its legal advisers
The body’s own specification first, made with read-only code access the body arranges with its supplier, as its contract allows, then leave in stages	The body wants a real choice at its end date and a way out with no single handover day	Costs money before anything moves; the present supplier keeps running the old system while modules move, and for a time the body pays two firms	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For an application a supplier built for a body and still runs (a grievance system, a licence or permit register, a property tax or billing application, a citizen portal): get the body’s own description of the system before the end-date decision is due. The body arranges read-only access to the code with its supplier, as its contract allows; that step is the body’s, and IOanyT does not obtain code from a supplier. The assessment writes down what the system does and what it connects to, in a specification the body owns and can show to other suppliers, subject to its own contract with its present supplier, with a risk register, a cost comparison between staying and leaving and a staged plan with a fixed quote. With that in hand the body can extend with an alternative priced, or leave one module at a time, each module checked against a traceability matrix and accepted before the next, while the present supplier keeps running the old system. How each stage is bought is the body’s own decision under its own rules.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the body’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
A description of the system	A design document from the year it went live; otherwise held by the supplier only	A current specification the body owns, confirmed by its own officers	The specification
What the system connects to	Known to the supplier	Each connection in and out written down	The map of the system as it stands
What the body holds and what it lacks	Not listed	Each item listed: what the body holds and what it would need	The risk register
The cost of leaving	Unknown until after the end date, if ever	Known before the end date, set beside the cost of staying	The cost comparison
A specification other suppliers can price from	None; the system is described in one line	A specification the body can show to other suppliers, subject to its own contract with its present supplier, with each stage described	The specification and the staged plan with its fixed quote
Proof that a module is done	A completion certificate signed on a switch-over date	Each module accepted, every old function linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. 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.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
3. 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.
4. 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. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. 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.

8. What the Client Would Own

• The map and the specification: what the system does and what it connects to, in writing. The body owns it and can show it to other suppliers, subject to its own contract with its present supplier.
• The risk register: the risks of staying and of leaving, and what the body holds and lacks.
• The cost comparison and the staged plan: the cost of staying set beside the cost of leaving, and each stage with a fixed quote.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the body’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Arranging code access with the present supplier, and keeping the old system running until the last module has moved, are matters between the body and its supplier.

9. What This Approach Does Not Cover

• IOanyT does 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.
• IOanyT does not obtain code or data from a supplier. The body arranges read-only access to the code with its supplier, as its contract allows.
• IOanyT does not take over the running of the supplier’s system, or keep it running while modules move. The present supplier does, and for a time the body pays two firms.
• IOanyT does not replace or implement packaged products.
• IOanyT does not work in COBOL or assembly language or on mainframes, and does not work on air traffic control, defence or other safety systems.
• IOanyT has not stated that it connects applications to any government portal, and makes no claim about any state’s systems.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any government, or that it meets the conditions of any tender. It gives no advice on budget or procurement rules.
• This study does not say IOanyT would have prevented the events described. IOanyT has no published case of this work for a public body.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Trade press, 2025	The UK national public body’s system, more than 25 years old and possibly running into the 2030s
UK State of Digital Government Review, 21 January 2025	Councils’ children’s social care systems; the survey’s 15%
PublicTechnology, 12 June 2026	”Incomplete and uneven in coverage”
FedScoop, 17 July 2025; US Government Accountability Office, GAO-25-107795, 17 July 2025	3 of 10 modernisations completed; fiscal year 2035; COBOL and assembly language
Lok Sabha, Unstarred Question 1653, 10 December 2025	E-services in the states and union territories; CPGRAMS and State RTS systems

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We give a public body its own description of a system a supplier built, so its end date is a choice, and a way out in stages if it chooses to leave.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →