A Contract That Outlasts Its Term

1. At a Glance

Issue study · From the public record. The body described here is a large public body in the UK, far larger than the colleges, universities, school groups and institutes we write for, and its contract is to run schools’ networks and IT service, which is not application work and not IOanyT’s kind of work. We found no public record of a college or university, in India or elsewhere, tied to the supplier of an application built for it. The case is reported as the public record gives it, without judgement on the authority, its officials or either supplier, and neither supplier is named.

Organisation type	A public body’s contract for its schools’ IT, as reported in the trade press, set beside the position of an institution whose admissions, fees or examination application was built and is still run by one supplier
Size band	The case: a schools authority covering over a thousand schools. Our reader: a college, a university, a school group, a coaching institute or a training body
Region	The case: the UK. The reader: anywhere
The decision at stake	What to do as a supplier’s contract nears its end: extend again, tender on whatever description exists, appoint one new firm to replace everything, or get the institution’s own specification first and then leave in stages
The public outcome	The authority’s schools IT contract, first signed in the early 2010s, has been extended several times without competition. An earlier replacement contract worth several hundred million pounds ended within its first year. A new deal is sought
Why it matters to a mid-size institution	A tie to one supplier can outlast its first term many times over, and a change of supplier can be started and not finished. A smaller institution with an application only its supplier can describe faces the same end-date question with less room to recover

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

“The firm that built our admissions and fees application has looked after it for eleven years, and it does a decent job. Every three years the contract comes up, and every three years someone asks whether we should tender. I ask what the tender would say, and nobody can tell me. When the governing body asks how a fee concession is chosen, we have to ask the supplier and wait. When we did look at changing, the only plan anyone could write had one handover day, in the middle of admissions. So we extended.”

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

The institution is caught between a contract with an end date and a system it cannot describe to anyone else, because only the supplier holds the description.

3. What We Found

Method. 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 (January 2025), one column on university technology (2025) and one vendor’s cross-sector survey of IT professionals in the US (2025). The sector research behind this study holds no college or university of our readers’ size, and nothing from India, on this issue.

A schools IT contract, first signed in the early 2010s. By the trade press report, one UK schools authority’s contract for its schools’ IT, covering over a thousand schools and hundreds of thousands of pupils, was first signed in the early 2010s and has been extended several times without competition. An earlier contract to replace that arrangement, worth several hundred million pounds, ended within its first year, which the report describes as agreed by both sides and without fault. The existing contracts and the new deal sought are each reported to be worth several hundred million pounds. The report was published in mid-2026. We did not examine why the contract was extended or why the earlier replacement ended, and draw no cause from either. The contract is to run the schools’ networks and IT service, which is not IOanyT’s kind of work; we use it for one narrow point only: an arrangement with one supplier can run well past its first term, and a change of supplier can be started and not finished.

How long a tie can last elsewhere. 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”, and gives no method for the figure. These are packaged products bought by local councils, which is not IOanyT’s kind of work, and the review is not about education.

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, with no figure behind it. Suppliers make such decisions for ordinary commercial reasons.

How organisations regard their old systems. In one vendor’s survey of about 500 IT professionals in the US, which is not about education, about a third named lack of vendor support among the top challenges of their old systems. Among reasons for not modernising, half said the current system still works, more than four in ten named budget limits and nearly four in ten fear of disrupting operations. About two thirds of those who answered work in technology or software.

Our reading of why an institution stays tied. These four are our reasoning from the record above. None is a finding of any source, none is an account of the case, and none supposes that a supplier has behaved badly.

1. Only the supplier can describe the system. Changes were agreed in calls and emails and built. Nobody on the institution’s side wrote down the result.
2. No tender can be written without a description. “A system like the one we have” is not a scope, so the end date passes unused.
3. The institution has not asked for read-only access to the system’s code. That access, arranged with its supplier, as its contract allows, is where its own description starts, and it is the institution’s step.
4. Leaving is pictured as one handover day. That looks riskier than staying, so the institution stays.

4. The Options an Institution in This Position Had

Option	When it fits	What it risks	Our view
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; every change still goes through one firm	Right when chosen with an alternative priced; not as the only course
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	Right only for a small, simple system
One new firm replaces everything, with one switch-over at the end	The institution has a full description, and funding for a complete rebuild is assured	One handover day, and a new dependence on one firm for another long term	Rarely right without a full description first
A specification first, made with read-only code access the institution arranges with its supplier, as its contract allows, then leave in stages	The institution 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 institution pays two firms	Our recommendation

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

For an application a supplier built for an institution and still runs (an admissions and enrolment application, fee collection and receipts, an examination and results application, a certificate register): get the institution’s own description of the system 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 IOanyT does not obtain code from a supplier. The assessment 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, with a risk register, a cost comparison between staying and leaving and a staged plan with a fixed quote. With that in hand the institution 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. What a contract provides is for the institution and its own legal advisers. How each stage is bought is the institution’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 institution’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Share of the system described in a document the institution holds	Little or none; the original tender document describes the system as planned	The whole system, in 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
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
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
Modules traced	None; the change is pictured as one handover	Every old function in each module linked to its replacement	The traceability matrix
Stages accepted	A completion certificate signed on a switch-over date	Each module accepted by a named person at the institution before the next begins	The staged plan, updated after each module

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the system, the contract’s end date, what the institution holds today and any transition plan already drafted. 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 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.
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, the rules inside it and what it connects to, in writing. The institution 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 institution 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 institution’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 institution and its supplier.

9. What This Approach Does Not Cover

• IOanyT does 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.
• IOanyT does not obtain code or data from a supplier. Read-only access is arranged by the institution 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 institution pays two firms.
• IOanyT does not run a school’s or a campus’s network, devices or IT service, which is what the case in section 3 involved, and it does not implement or move packaged products.
• IOanyT does not handle, move, correct or vouch for student, staff or applicant records. Moving records is done by the institution’s own people or a firm they choose, and IOanyT’s confidentiality terms cover code.
• IOanyT does not work in COBOL, RPG or FoxPro or on mainframes. The older technologies it reads are VB6, Delphi, AngularJS, PHP 4 to 8, Java 8 and .NET Framework or classic ASP.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any government, university or board, or that it meets the conditions of any tender. It gives no advice on budget or purchasing rules, and does not say an institution’s budget year, governing-body approval or tender will fit any of its terms.
• IOanyT does not say a staged exit is quicker or cheaper overall. It may take longer on the calendar.
• This study does not say IOanyT would have changed anything in the case described. IOanyT has no published case of this work for an education 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, 2026	One schools authority’s IT contract: first signed, extensions, the earlier replacement, the scale
UK State of Digital Government Review, 21 January 2025	Councils’ children’s social care systems: 3 main providers, each used “for a median 10-year period”
A vendor author’s column, 2025	One opinion on suppliers phasing out support
A vendor’s survey, 2025	Challenges of old systems, and reasons for not modernising (cross-sector)

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 the system before its end date, 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 →