Priced Before It Was Read

1. At a Glance

Issue study · From the public record. None of the institutions described here was an IOanyT client, and IOanyT had no part in the events described. All three are very large universities abroad, and each was bringing in a packaged product, which is not IOanyT’s kind of work. We found no public record of a mid-size institution, a private college, a school group or a coaching institute on this issue, and nothing from India or the Middle East. Each case is reported as the public record gives it, without judgement on any institution, governing body or official.

Organisation type	Three very large universities that replaced, or set out to replace, old student or administrative systems, set beside the position of a college, university or school group whose applications it built or had built must be replaced
Size band	The cases: very large universities. Our reader: a college, a mid-size university, a school group, a coaching institute or a training body
Region	The cases: US and UK. The reader: India first, and anywhere
The decision at stake	How to replace the old applications: patch and keep them, bring in a packaged product in one programme, rebuild everything in one programme, or read them first and replace them module by module
The public outcome	One very large US university replaced dozens of separate student systems with a packaged product, at a cost the trade press puts in the hundreds of millions of US dollars over several years. A large UK university’s student records project, worth tens of millions of pounds, was scaled back. At a second large US university, a large number of research grants were held up in processing in 2024, with causes given in the record
Why it matters to a mid-size institution	If very large universities find replacement this costly, a smaller institution’s governing body will not approve one large figure on little basis. So the decision is deferred, and changes the institution wants wait with the old applications

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

“Everyone agrees the old admissions, fees and examination applications have to go. The proposal has been to the governing body twice, each time as one figure, a supplier’s estimate. Each time a member asked what it was made of and what staying as we are costs, and we could not answer. Meanwhile the academic council wants to consider a second intake, and the registrar says the admissions application cannot take one. I cannot ask our governing body to stake years of funds on one paper.”

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

The institution is caught between old applications it cannot change easily and a replacement proposal it cannot ask anyone to approve, because nobody has read the applications or set the cost of keeping them beside the cost of replacing them.

3. What We Found

Method. We went through the public record on replacing old student and administrative systems in universities: trade press reporting in 2025, 2024 and 2021 on three universities; one sector body’s report on UK universities as carried in the trade press in 2026; one cross-sector survey of US IT professionals from 2025; and two documents of India’s University Grants Commission (UGC): its 2025 degree regulations and its letter of 5 June 2026 on uploading academic records. The sector research behind this study holds no mid-size institution and nothing from India on the cost of a replacement.

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

A finance move whose difficulties the record explains. A different large US university spent several years moving hundreds of old systems into one packaged finance and HR system, an implementation the trade press put in the hundreds of millions of US dollars. In 2024, by the same report, a large number of research grants were held up in processing, and a backlog of unpaid supplier invoices that had built up the year before had been roughly halved. The source gives causes: a consultancy report cited by the press put the difficulties down to a shortage of IT skills, pandemic lockdowns, a plan with unclear priorities and delayed decisions; the university describes them as problems of putting the system into operation. Whether the difficulties have since been resolved is not in the research we hold.

A project scaled back. 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.

What staying is estimated to cost. One sector body’s report on old technology in UK universities, as the trade press reported it in 2026, says 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, and calls its figure an early analysis. It is an early, indicative estimate about UK universities, and the body gives the cause in general terms: the build-up of disconnected and heavily customised old systems.

Why organisations wait. 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; more than four in ten gave budget limitations, and nearly four in ten fear of disrupting operations.

What waits in India. The UGC’s regulations on minimum standards of instruction for undergraduate and postgraduate degrees, notified on 26 March 2025, apply, in their own words, to “every University established or incorporated by or under a Central Act, a Provincial Act, or a State Act, all institutions and colleges recognized by or affiliated to such Universities, and all institutions deemed to be universities under Section 3 of the UGC Act 1956”. They allow, and do not require, that “HEIs prepared to handle biannual admissions may admit students twice a year, in July/August and January/February.” They say that “HEIs shall provide multiple entry and exit options in the academic programmes.” A student who exits after earning 40 credits is awarded an undergraduate certificate, provided they have also done a skill-enhancement course of at least 4 credits over and above those 40, and “Students shall be allowed to join back in the 2nd year at level 5 before the expiry of the credits earned, subject to a maximum duration of seven years.” Separately, on 5 June 2026 the UGC wrote to universities and autonomous colleges that records for Examination Year 2025 were to be uploaded to the NAD/ABC platform by 30 June 2026, and that the window would then close. That date has passed. When we checked on 15 October 2026, this letter was the newest item on the NAD/DigiLocker circulars page, and we found no letter for Examination Year 2026 there or on the UGC’s notices page. Neither document says anything about institutions’ own systems. What either means for a particular institution is for its own registrar, controller of examinations and advisers.

Our reading of why replacement becomes so costly. These four are our reasoning from the record above. Only the causes the second US university’s record gives are findings of a source; the rest is ours.

1. The scope is made from memory. Offices list the systems they can name; the small programs, scheduled jobs and hand-offs are found once the money is committed.
2. The price is set before the applications are read. It carries a margin for the unknown, and grows when the unknown is met.
3. The cost of staying is never written down. So the figure is compared with nothing, and looks too large whatever it is, while changes the institution wants wait on the old applications.
4. Everything is delivered on one date. Nothing is in use for years, every office changes together, and a pause part-way leaves nothing to switch on.

4. The Options an Institution in This Position Had

Option	When it fits	What it risks	Our view
Patch and keep the old applications	They still work, change is rare, and the people who know them are still there	The rules stay written down nowhere; each new option is added to code few can change; the eventual replacement grows	Right as a dated pause, not as a standing answer
One programme to bring in a packaged product	The institution’s work matches what the product does as it comes, and it would rather buy a product than own applications	One large figure and one go-live; fitting the product means custom changes; what the old applications do that the product does not is found late	Right for some institutions; their decision, and not our kind of work
One programme to rebuild everything custom	The applications are few, small and fully documented, and funding for several years is assured	The figure is set before the applications are read; nothing is in use until the end; a pause leaves nothing to switch on	Right only for a small, well-documented estate
Assess first: read the applications, write down what they do, set the cost of staying beside the cost of replacing, then replace module by module with the old applications running	The applications are the institution’s own, and its governing body wants to approve one stage at a time	Costs money before anything is built; the total may be higher than a first guess; two systems run side by side for a time; some staff use both	Our recommendation

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

For the applications an institution built or had built (admissions and enrolment, fee collection and receipts, timetables, attendance, examination and results applications, portals, certificates and registers): read them first and write down what each does, the platform it stands on and the office that owns it, including the small programs and hand-offs staff point to. List the unknowns before the price. Set the cost of keeping the applications beside the cost of replacing them, and price each stage. Then replace one module at a time, with the old applications kept running by the institution’s own team or supplier, a traceability matrix linking every old function to its replacement, and each module accepted by the office that uses it before the next begins. Which application comes first is the institution’s choice when the plan is drawn up. Where a packaged product fits the institution’s work better, that is its decision, and not work we do. How the assessment and each stage are 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
Applications in scope	Listed from memory in a workshop	Each application listed, 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, or to a supplier	Written down and confirmed by the institution’s own experts	The specification
Price of the replacement	One figure, set before the applications are read	A fixed quote for each stage, beside the written cost of staying	The staged plan with its fixed quote, and the cost comparison
What is uncertain	A margin inside the figure	Listed before the price is set	The risk register
Modules in use	None until go-live	Each module in use once the office that uses it accepts it	The benchmark review after each module
The old applications	Frozen, then switched off on one date	Kept running by the institution for everything not yet moved, until each module is accepted	The staged plan
Proof that a module does what the old one did	A go-live date	Every old function linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the applications the institution runs, the replacement proposal and the changes waiting on it. 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 the set of applications the institution built or had built and plans to replace. 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.
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 each application does, in writing, confirmed by the institution’s own experts. The institution can show it to any supplier.
• The risk register: what is uncertain about the replacement, listed before the price.
• The cost comparison and the staged plan: the cost of keeping the applications beside the cost of replacing them, and a fixed quote for each stage.
• 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.

Keeping the old applications running, accepting each module, moving records and switching off each old application when its last module has moved are the institution’s own steps.

9. What This Approach Does Not Cover

• IOanyT does not implement, configure, convert or move a packaged student, finance, HR or learning product, which is what all three named cases involved. Its work is on applications an institution built or had built, in the old technologies it reads: VB6, Delphi, AngularJS, PHP (any version, 4 to 8), Java 8, and .NET Framework or classic ASP. It does not work in COBOL, RPG or FoxPro or on mainframes.
• IOanyT does not keep the old applications running or secure while they are replaced; the institution’s own team or supplier does.
• IOanyT does not move, clean, correct or reconcile student, fee or results records, and does not upload records to any platform. Its confidentiality terms cover code, not student, staff or applicant records.
• IOanyT does not handle, correct or vouch for students’ results, and nothing here suggests its work makes any result right.
• Any check an institution wants before it accepts a module, such as running past data through old and new, is the institution’s own team’s option, or a firm it chooses; IOanyT supplies the specification and the benchmark to check against.
• IOanyT does not train staff or manage change as a service, and does not host applications.
• IOanyT does not say a staged replacement is quicker or cheaper overall; it may take longer on the calendar. The assessment says which unknowns remain.
• IOanyT gives no legal advice and does not say what any UGC regulation or letter requires of an institution.
• 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 purchasing rules.
• This study does not say IOanyT would have prevented the events 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, 2025	One very large US university: the old systems, the cost, the years, the reason given
Trade press, 2024	A second US university: the programme, the grants and invoices, the causes
Trade press, 2021	One UK university: the programme, the spokesperson’s statement, the sum, the database’s support
Trade press report of a sector body’s report, 2026; the sector body’s release, 2026 and the sector body’s blog, 2026	The early, indicative estimate and its method
A vendor’s survey, 2025	Reasons for not upgrading (cross-sector)
UGC regulations on minimum standards of instruction for undergraduate and postgraduate degrees, 26 March 2025 (Gazette of India text, from the UGC’s website)	Who the regulations apply to; twice-yearly admission; multiple entry and exit; the certificate exit and re-entry (clause 11.1)
UGC Advisory regarding Academic Bank of Credits (ABC), letter of 5 June 2026 (UGC’s own copy, ugc.gov.in)	The Examination Year 2025 upload window

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We read an institution’s applications before anyone is asked to approve a figure, price each stage beside the cost of staying, and replace one module at a time with the old applications still in use.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →