Your Replacement Was Scoped From the Systems Everyone Could Remember. Here Is What the Public Record Shows.

The workshop to scope the replacement takes one morning. The registrar, the finance officer, the controller of examinations and the head of IT fill a whiteboard.

By lunch there are five boxes on it: admissions, fees, examinations, the portal, the library. The list is typed up and a figure is asked for.

Nobody mentions the program that prints the bonafide certificates, the spreadsheet that works out hostel dues, or the nightly job that copies fee receipts across so that hall tickets can be released. They are not thought of as systems. They are how the work gets done.

What We Found

For this article we went through the public record on replacing old student and administrative systems in universities: trade press reporting in 2021 and 2025 on two universities’ programmes, one sector body’s report on UK universities as carried in the trade press in 2026, and one cross-sector survey of US IT professionals from 2025.

First, what we did not find: no public case at a mid-size institution, a private college, a school group or a coaching institute; nothing from India or the Middle East on this issue; and no figure for what a replacement costs at an institution of our readers’ size. Every case below is a very large university abroad bringing in a packaged product, which is not our kind of work.

The public cases are very large universities bringing in packaged products. At one large UK university, in an older case from 2021, a programme begun in the mid-2010s was bringing in a packaged student record product. A spokesperson said the new product could not be joined to the existing central system as first planned, and the project, worth tens of millions of pounds, was scaled back. The trade press reported that the existing system ran on a database version already past its maker’s extended support, and asked whether that was behind the problem; the university did not say, and neither do we.

The sums are very large. At one very large US university, as the trade press reported in late 2025, a senior finance officer described the old student systems as fragile in-house applications dating from the 1990s. The university replaced dozens of separate student systems with a packaged product, at a cost the publication puts in the hundreds of millions of US dollars over several years. The only reason the record gives is that the old system was near the end of its life; the report says where the money went, not why.

Staying has a cost too, by one early estimate. One sector body’s report on old technology in UK universities, as the trade press reported it in 2026, says that old technology could be costing the sector billions of pounds a year. The body itself says no settled method yet exists for costing old technology, that it worked from indicative sector data and surveys, and calls its figure an early analysis. It is an early, indicative estimate about UK universities. The body gives the cause in general terms: the build-up of disconnected and heavily customised old systems.

Many old systems stay because they still work. In one cross-sector survey of about five hundred US IT professionals, which is not about education, half said the biggest reason they had not upgraded was that the current system still works.

Our reading: in each public case the replacement was one programme with one large figure. The record does not show what each institution listed before its figure was set. What we can describe is how a scope is usually made at the institutions we write for: in a room, from the systems people can name. Small programs, scheduled jobs and hand-offs between offices are on no list, and are found once the money is committed.

What a Scope From Memory Holds Back

Our reading is that several things wait on a scope nobody has checked.

The governing body cannot approve it. A member asks what exactly would be replaced, and the honest answer is what four people could recall.

The figure carries a margin for what nobody has looked at. Nobody can say whether it is too large or too small, so it is deferred.

Nothing is retired by decision. A register somebody needs is dropped because nobody knew it was there.

The rules stay where they are. The rules the registry and the examination section rely on stay inside the old applications, written down nowhere else.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Answer “What Exactly Would Be Replaced?”, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Patch and keep the old applications	They still work, change is rare, and the people who know them are still there	The question is put off; the rules stay written down nowhere, and the eventual replacement grows
One programme to bring in a packaged product	The institution’s work matches what the product does as it comes	What the old applications do that the product does not is found late. Not our kind of work; for some institutions it is the right choice
One programme to rebuild everything, scoped in a workshop	The applications are few, small and well documented	The scope is what the room remembers; the rest arrives as change requests on one large figure
Assess first: read the applications and write down what each one does, then replace module by module	The applications are the institution’s own, and the governing body needs a basis before it approves	It costs money before anything is replaced, and the list is longer than the whiteboard’s. The replacement looks larger, because it is

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
Applications the institution runs	Listed from memory	Each named, with its platform and the office that owns it	The map of the system as it stands
What each application does	Known to the people who use it	Written down and confirmed by the institution’s own experts	The specification
Small programs, scheduled jobs and hand-offs	On no list	Recorded where staff point to them, each with an owner	The map and the specification
What is not yet known	A margin in one figure	Listed before any price is set	The risk register
A decision for each item	None	Replace, keep or retire, decided by a named person at the institution	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 an education body.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the applications the institution runs. 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 the set of applications the institution built or had built, such as admissions, fee collection and the portal. 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. 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 implement, configure or move a packaged student, finance, HR or learning product. We do not keep the old applications running or secure while they are replaced; the institution’s own team or supplier does. We do not move, clean or correct student, fee or results records, and our confidentiality terms cover code, not records. We do not work in COBOL, RPG or FoxPro or on mainframes. We do not say a staged replacement is quicker or cheaper overall; it may take longer on the calendar. 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	The governing body is shown what the institution runs before it is asked to replace any of it, so the proposal is a scope and not a hope.
Registrar	Every register, certificate, letter and return the registry relies on is on a list before anything is designed, including the ones nobody would have thought to mention.
Head of finance	The figure put to finance rests on a written scope, so work found late is the exception and not the pattern.
Head of IT	A written list of every application, with its platform and its owner, taken from the systems themselves, so the estimate stops being the IT head’s personal guess.
Controller of examinations	The rules the examination section relies on are written down, and confirmed by the section, before anyone proposes to replace the application that applies them.

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

The case	What IOanyT does
One large UK university: a programme to bring in a packaged student record product could not be joined to the existing central system as first planned, and was scaled back.	We do not implement packaged products, we make no comment on that programme, and our part is far narrower. For applications an institution built, we write down what each one does before any price is set.

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 finding out what an institution runs, from the applications themselves, before anyone is asked to approve a figure.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →