When the Supplier's Contract Comes Up, Nobody Can Write the Tender. Here Is What the Public Record Shows.
We went through the public record on institutions tied to one supplier. The one education case is a schools IT contract extended many times; the record holds no college case of our readers' size. Here is what we found, the options, and the benchmark we would set.
The contract for the admissions and fees application ends in March. The head of purchasing raises it in October.
Could the work go to tender? The head of IT asks what the tender would say. What does the application do, exactly? Which rules are in it? What does it send to the bank, and when?
Nobody in the room can answer. The only people who can are the supplier’s. So the meeting ends as it did three years ago: extend for another term, and look at it properly next time.
The paradox: The contract gives the institution a date on which it could choose, and the institution has nothing to choose with.
What We Found
For this article we went through the public record on institutions tied to one supplier: a trade press report in mid-2026 on one schools authority’s IT contract in the UK, the UK government’s own review of its digital services, published in January 2025, and one column on university technology, published in 2025.
First, what we did not find: no case of a college or university tied to the supplier of an application built for it, nothing from India or the Middle East, no case of a supplier refusing to hand over code or data, and no figure for what a change of supplier costs.
An arrangement with one supplier can run well past its first term. By the trade press report, the contract of one UK schools authority for its schools’ IT, which covers over a thousand schools, was first signed in the early 2010s and has been extended several times without competition. It is a contract to run the schools’ networks and IT service, which is not application work and not our kind of work.
A change of supplier can be started and not finished. The same report says that an earlier contract to replace that arrangement, worth several hundred million pounds, ended within its first year; the report describes the ending as agreed by both sides and without fault. We did not examine why the contract was extended or why the earlier replacement ended, and we draw no cause from either. We pass no judgement on the authority, its officials or either supplier, and we do not name the suppliers.
Long arrangements are found outside education too. The UK government’s own review found that councils buy their children’s social care systems from 3 main providers, and use each system “for a median 10-year period”. The review sets this beside councils being “locked into vendors”. It gives no method for the figure. These are packaged products bought by local councils, not our kind of work and not education; we use the figure only to show how long a tie to one supplier can last.
One view from inside the market. One column on university technology, by an author who works for a firm that sells to the sector, says suppliers often end support for their older systems and leave institutions to adapt. It is an opinion, and we give it as one. Suppliers make such decisions for ordinary commercial reasons.
Our reading: the tie is rarely in the contract itself. It is in the fact that only the supplier can say what the system does. A contract can have an end date and still be renewed every time, because nobody on the institution’s side can describe the work well enough for anyone else to price it. That is our reasoning, not a finding of any source or an account of the case.
What our review does not show: The one education case is a public body’s contract to run its schools’ networks and IT service, on a scale far beyond any institution we write for. The record does not say what either contract provides or who holds any code or data, and we do not say. The council figure is cross-sector and about packaged products. The column is one opinion, not a finding that suppliers behave badly. We found nothing from India, no mid-size institution, and nothing on which technologies Indian institutions run. Contract law, the ownership of code and data, and purchasing rules were not part of our research, and nothing here says what any contract or rule provides.
What Waits While Only the Supplier Can Describe the System
A long arrangement with one supplier is not a failure; many institutions are well served by the firm that built their systems. Our reading is that several things cannot start while only that firm can describe the system.
A tender cannot be scoped. “A system like the one we have” is not a scope another firm can price.
A renewal quote has nothing to be set against. There is no second figure, because no other firm can price a system it cannot see.
The end date passes unused. Using it needs a document the institution does not have.
The gap we see: few institutions we write for hold a written description of their system that another firm could read and price. One that holds it can extend by decision, ask for a second opinion, or plan an exit. One that does not has one answer at every end date: extend, and look at it properly next time.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Get a Description of the System, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Ask the supplier for its documentation | The contract provides for it, and the supplier keeps good notes | It is the supplier’s description, written for its own engineers; the institution still has nothing it has checked itself |
| Reuse the specification from the original tender | The system has changed little since it went live | It describes the system as planned years ago, before every change made since |
| A write-up by the institution’s own staff, from the screens | A first view is needed quickly, and staff know the system well | Staff know what goes in and what comes out, not the rules in between |
| An assessment that reads the code and writes a specification the institution owns | The description must stand up to another firm’s pricing and to the end-date decision | It costs money before anything changes, and it needs read-only access to the code, which the institution arranges with its supplier, as its contract allows |
Our recommendation: get a description the institution owns before the end-date decision is due. The institution arranges read-only access to the code with its supplier, as its contract allows; that step is the institution’s, and we do not obtain code from a supplier. The assessment then writes down what the system does, the rules inside it and what it connects to, in a specification the institution owns and can show to other suppliers, subject to its own contract with its present supplier. The supplier’s notes are useful inputs, not a description the institution has checked. What the contract says about code, data and documents is a matter for the institution and its own legal advisers.
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 description of the system | Held by the supplier only | A current specification the institution owns, confirmed by its own staff | The specification |
| The rules inside it (fees, concessions, eligibility, certificate numbers) | Known to the supplier’s engineers | Each rule written down in plain language and traced to the code | 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 institution with its supplier, as its contract allows | Confirmed by the institution 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 |
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 an education 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 institution 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 institution and still runs, such as an admissions, fees or examination application. The institution 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 institution’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 an institution 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 do not run a school’s or a campus’s network, devices or IT service, which is what the case above involved, and we do not implement or move packaged products. We do not handle, move or vouch for student records; our confidentiality terms cover code. We do not work in COBOL, RPG or FoxPro or on mainframes. We do not say we are empanelled with any government, university or board, and we give no advice on purchasing rules: how an assessment and the stages after it are bought is the institution’s own decision. We have no published case of this work for an education body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of institution | When the contract ends, extending it is a choice the institution makes, and not the only thing it can do. |
| Head of purchasing | The work can be described in writing, so more than one firm can price the same scope. |
| Head of IT | A specification the institution 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. |
| Registrar | The registry’s own needs are written into the scope from the record, and are not rediscovered after a contract is signed. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| One UK schools authority: its schools IT contract, first signed in the early 2010s, has been extended several times without competition; an earlier replacement contract ended within its first year. | We make no comment on the authority, its officials, its contracts or either supplier, and our part is far narrower: we do not run school networks or IT services. For an application a supplier built for an institution, the assessment writes a specification the institution owns and can show 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 giving the institution its own description of the system, so that the end date becomes a decision.
Sources
- Trade press, 2026
- UK State of Digital Government Review, 21 January 2025
- A vendor author's column, 2025
In this issue
Locked to one supplier
Research note 2
Only the Supplier Can Say What Your System Does. Four Ways Forward at the End Date, Weighed.
No tender can be written without a description of the system. Four ways forward at the end date, what each risks, and why getting the code comes first.
Research note 3
Changing Supplier Does Not Have to Rest on One Handover Day. Here Is the Benchmark We Would Set.
A supplier change pictured as one handover day keeps institutions stuck. Four ways to leave, weighed, and the benchmark we would agree before starting.
Issue study
A Contract That Outlasts Its Term
Being tied to one supplier in education: a schools IT contract extended several times, how long such ties last, the options and our benchmark.
More from Education
Slow or faulty results processing
The Rules Your Results Application Applies Keep Changing. Four Ways to Make a Change You Can Check, Weighed.
Replacement is very costly
While One Large Figure Waits for Approval, New Options Wait Too. Four Ways to Replace, Weighed.
Unsupported databases