Only the Supplier Can Say What Your System Does. Four Ways Forward at the End Date, Weighed.

A member of the governing body asks a simple question at the audit committee. How does the system decide which fee concession applies when a case qualifies for two?

The registrar does not know. The head of IT does not know. Both know who does. A request is raised with the supplier, and the answer comes back nine days later, in two lines, with a reference to a change made some years ago.

Nobody doubts the answer. What stays with the committee is the nine days, and the fact that the institution had to ask an outside firm how its own rule works.

What We Found

For this article we went through the public record on how institutions come to depend on one supplier for knowledge of their own systems: one column on university technology (2025), one vendor’s survey of about 500 IT professionals in the US (2025, not about education), and the UK government’s own review of its digital services (January 2025).

First, what we did not find: no count of how many colleges or universities hold a written description of the systems built for them, no case of an institution of our readers’ size tied to the supplier of an application, and nothing from India or the Middle East on this issue.

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. Suppliers make such decisions for ordinary commercial reasons.

Losing a supplier’s support is a common worry. In one vendor’s survey of about 500 IT professionals in the US, about a third named lack of vendor support among the top challenges of their old systems. The survey is cross-sector, and about two thirds of those who answered work in technology or software.

The usual reason to wait is that the system works. In the same survey, half said the biggest reason they had not upgraded is that the current system still works, and more than four in ten named budget limits.

A tie to one supplier can last a decade. 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”, beside councils being “locked into vendors”. These are packaged products bought by local councils, not education, and no method is given for the figure.

Our reading: when a question about the system can be answered only by its supplier, three things follow. The institution cannot check an answer, because it has nothing of its own to set it against. Knowledge arrives one question at a time and is filed in somebody’s email. And no tender can be written, because a tender starts from a description the institution does not have. That is our reasoning, not a finding of any source above.

What a Description You Hold Opens Up

The usual view is that a tie to one supplier is a contract matter, dealt with at renewal. Our reading is that the end date is of little use without the institution’s own description of its system, and that the description opens up more than the renewal.

A tender that can be written. No tender can be written without a description of the system. With one, the work has a scope that more than one firm can price.

A renewal with an alternative. With a description in hand, the cost of leaving can be set beside the cost of staying.

Answers the institution holds. A governing body member’s question about a rule is answered from the institution’s own record, not from a request and a wait.

A contract that names what exists. An institution that knows what its system is made of can say what it expects at the end of a contract. What a contract may provide is for the institution and its legal advisers.

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 again	The system is stable, the supplier serves it well, and no new demand is coming	The same question returns at the next end date, and every change still goes through one firm
Tender on a functional description written by the institution’s own staff	The system is small and simple enough to describe from its screens	Bidders price what the description shows; rules no screen shows are found after the contract is signed
One new firm replaces everything	The institution has a full description, and funding for a complete rebuild is assured	One handover day at the end, and a new dependence on one firm for another long term
A specification first, then leave in stages	The institution 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 institution arranges with its supplier, as its contract allows; it relies on the present supplier keeping the old system running while modules move, under the institution’s contract with it, and for a time the institution pays two firms

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 institution owns and can show to other suppliers, subject to its own contract with its present supplier	The specification
How a rule is worked out (a fee, a concession, a certificate number)	A request to the supplier, answered days later	Written down in plain language and confirmed by the staff who use it	The specification
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
What the institution holds and what it lacks	Not listed	Each item listed	The risk register
Cost of leaving against cost of staying	Unknown	Set side by side, before the end date	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

1. We listen: a free Reliability Review. A first conversation about the system, what the institution holds today and the questions it has had to send to its supplier. 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 article 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 institution and still runs. 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.
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. 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.
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.

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 or on what a contract allows. 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 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 each stage is 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	The institution can explain its own system to its governing body or an auditor without asking the supplier first.
Head of purchasing	The next contract can list what the institution expects back at its end, because the institution knows what exists.
Head of IT	Questions about how the system behaves are answered in-house, from a record the institution holds.
Head of finance	The cost of leaving is known, so a renewal is discussed with an alternative in hand.
Registrar	The registry can find out how a register or a certificate is produced without raising a request and waiting.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation as a case. Its figures are one opinion, one cross-sector survey and one review of councils’ packaged systems.	For an application a supplier built for an institution, we write down what it does and what it connects to, in a specification the institution owns. Getting read-only access to the code is the institution’s own step: it arranges it with its supplier, as its contract allows, and we give no legal advice on it.

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 institution its own description of its system, so the next question does not have to go to the supplier.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →