Your Contract's End Date Means Little Until You Can Describe Your Own System. Four Ways Forward, Weighed.
Public services are moving online and onto shared portals, while many systems can be described only by the supplier that built them. We weigh four ways forward at a contract's end date and say what each one risks.
A newly posted secretary is reviewing the department’s systems. The state’s portal team has asked: can the licence system join the unified portal this year?
For the licence system, three questions are asked. Where is the source code? With the supplier. Where is the database? On the supplier’s servers. Is there a document that describes the system? There was one, from the year it went live.
The reply to the portal team is the usual one: we will ask the supplier. The contract ends next year, and the extension note is already drafted.
The paradox: The department is asked to join up its service, and cannot say what its own system does without asking someone else.
What We Found
For this article we went through the public record on what public bodies are asked to do with their systems, and how much they know about them: a written answer in India’s Lok Sabha in December 2025 on e-services in the states and union territories, the UK government’s own review of its digital services (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 locked to one supplier, and no record of which state or municipal systems one supplier built and runs. We 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.
Services are moving online, and onto shared portals. 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.” It added that “10 States/UTs now deliver over 90 % of their services through a unified portal, and 6 State/UTs provides 100 % of their services through their unified portal.” The figures come from the states’ own inputs to a monitoring dashboard.
Joining systems up is still work in progress. 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. An API is a connection point through which systems exchange data. The answer does not say why the systems are not connected, and we draw no cause from it.
Many bodies cannot describe what they run. The permanent secretary of the UK’s central digital department, a civil servant, wrote to a parliamentary committee, in a letter reported in June 2026, 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”.
Our reading: when a service has to connect to a portal or take on new e-services, the first question is what the existing system does and what it connects to. Where only the supplier that built it can answer, every such request goes through that supplier, and the end date offers no real choice. That a supplier-held system holds back a joined-up service is our reading, not a finding of the Lok Sabha answer or of any other source.
What our review does not show: The Lok Sabha answer is a count of e-services that the states reported themselves; it says nothing about which systems are old, who built them or who holds their code, and it is not a rule that binds any body. The UK figures describe national bodies far larger than our readers, and the 15% is of survey respondents, not of bodies. Contract law, the ownership of code and data, and procurement rules were not part of our research, and nothing here says what any contract or rule provides. We make no comment on any government, state, body or supplier.
What a System You Can Describe Opens Up
The usual view is that lock-in is a contract matter, dealt with at renewal. Our reading is that the end date is unusable without the body’s own description of its system, and that the description opens up more than the renewal.
Joining a portal. A body that knows what its system does and what data it exchanges can say what a connection needs.
A real renewal. With a description in hand, the body can set the cost of leaving beside the cost of staying.
A contract that names its handover. A body that knows what exists can say what it expects to receive at the end. What a contract may provide is for the body and its legal advisers.
A way out in stages. A described system can be moved one module at a time while the old system keeps running.
The gap we see: many public bodies we write for are asked to put more services online and onto shared portals, and some of the systems behind those services can be described only by the supplier that built them. A body that holds its own specification can answer the portal team, use its end date and plan its exit. A body that does not has one answer for every question: we will ask the supplier.
This is our reading of the evidence. It is not a measured market figure.
Four Ways Forward at the End Date, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Extend the present contract | The service is stable, the supplier serves it well, and no new demand is coming | The question returns at the next end date, and new demands still go through one firm |
| Re-tender the whole system without a description | The body must test the market now, and the present system is simple enough to describe in a few lines | Bidders price a guess, and the winner must learn the system from the firm it replaces |
| Negotiate a handover of code, data and documents from the supplier | The contract provides for it and the supplier cooperates | It is what the supplier hands over, described by the supplier; the department still has no description it has checked itself |
| The body’s own specification first, then leave in stages | The body wants a real choice at its end date and a way out that does not rest on one day | It costs money before anything moves; it needs read-only code access, which the body arranges with its supplier, as its contract allows; the present supplier must keep running the old system while modules move, and for a time the body pays two firms |
Our recommendation: the body arranges read-only access to the code with its supplier, as its contract allows; that step is the body’s, and we do not obtain code from a supplier. The assessment then produces a specification the body owns and can show to other suppliers, subject to its own contract with its present supplier. With it the body can extend with an alternative priced, re-tender on a real description, or leave in stages while the present supplier keeps running the old system. We give no legal advice on who owns code, data or documents, we do not negotiate with suppliers, and we do not take over the running of the supplier’s system.
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 |
|---|---|---|---|
| Whether the system can be described to another firm | Only the supplier can describe it | A specification the body owns and can show to other suppliers, subject to its own contract with its present supplier | 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 |
| Code access for an assessment | Never asked for | Read-only access, arranged by the body with its supplier, as its contract allows | Confirmed by the body before the assessment begins |
| Options at the end date | Extend, as the only safe course | Each option weighed, with its risk and its cost | The risk register and the cost comparison |
| A plan to leave, if the body chooses to | None | Modules in order, each with a fixed quote | The staged plan |
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, what the department holds today and what it is being asked to do next. 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. We do not obtain code or data from a supplier. We do not take over the running of the supplier’s system or keep it running while modules move; the present supplier does. We have not stated that we connect applications to any government portal. 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. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | The department can explain its own system to the minister, the auditor or the public without asking the supplier first. |
| Head of procurement | The department can say what it expects to receive at the end of the next contract, because it knows what exists. |
| Head of IT | Questions about how the system behaves are answered in-house, from a record the department holds. |
| Head of finance | The cost of leaving is known, so a renewal is negotiated with an alternative in hand. |
| Head of audit and vigilance | Something in the department’s own hands to show how it oversees its supplier. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| India’s Lok Sabha answer of 10 December 2025: states’ e-services rose from 11,614 to 23,919; “at present, there is no API integration between CPGRAMS and State RTS systems”. | We make no comment on any government or state system, and we have not stated that we connect applications to any portal. For an application a supplier built for a public body, we write down what it does and what it connects to. |
| The UK’s central digital department, in a letter reported in June 2026: existing “data is incomplete and uneven in coverage” on the government’s old systems. | Our part is far smaller. For one body’s supplier-built system, the assessment produces a map and a specification the body keeps. |
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 the department its own description of the system, so the next question does not have to go to the supplier.
Sources
In this issue
Locked to one supplier
Research note 1
Your Supplier's Contract Has an End Date You Cannot Use. Here Is What the Public Record Shows.
Public systems often stay with the supplier that built them, because only it can describe them. What we found, four options and the benchmark we would set.
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