The Fees Office Says Paid and the Examination Section Says Due. Here Is What the Public Record Shows About Separate Systems.

It is the week before examinations. The fees office has a receipt on its screen: paid in full, eleven days ago.

Across the corridor, the examination section’s screen shows the same enrolment number as fee due. So the number sits on the section’s list of records to query with the fees office before the cycle begins.

Both screens are right, by their own lights. The fee was paid, and the examination application was never told. Somewhere between the two offices the payment stopped, and nobody in either office can say where.

What We Found

For this article we went through the public record on colleges and universities whose systems do not share what they know: reporting on two US universities’ systems, a UK university’s statement about a connection it could not make, and one cross-sector survey, published between November 2021 and December 2025.

First, what we did not find: no Indian institution on record with this problem, none of our readers’ size, and nothing from the Middle East. We found no figure for how much re-typing is done, how often two systems disagree, or what a failed transfer costs. We give none.

The count can be far higher than anyone would say from memory. A very large US university “replaced nearly 80 separate student systems” with a packaged product, as the trade press reported in December 2025. Its finance chief described the old student systems as “a 1990s era set of fragile, homegrown applications”. We use this case for the count only. The source does not say what the number of systems cost, what went wrong because of it, or how the systems were joined, and we add nothing. The replacement, a packaged product, is not part of this article.

A second very large university counted in the hundreds. Another large US university spent more than five years “shifting 850 legacy tech” into one packaged finance and HR system, as the trade press reported in March 2024. That move had difficulties of its own, which a consultancy report cited by the press put down to “a lack of IT skills and pandemic lockdowns”, a plan that “contained ill-defined priorities” and delayed decisions; the university calls them “operational implementation issues”. We use the case only for its count.

Joining old and new is not always possible. At one large UK university, in an older case from 2021, a programme begun in 2014 was bringing in a packaged student record product. A university spokesperson said that “it will not be possible to integrate” the new product “with our current Corporate Information System (CIS) as initially planned”, and the £30.4 million project was scaled back. We did not examine why the connection could not be made, and draw no cause from it.

Old systems are widely seen as hard to fit with newer ones. In one survey of 504 IT professionals in the US, which is not about education, 41% named incompatibility with modern systems or tools among the top issues with their old systems.

Our reading: an institution rarely chose to have many systems; they arrived one office at a time. Each holds its own copy of an enrolment or a fee status, and the errors are made where that copy passes from one system to the next. Those places are rarely listed. So when two offices disagree, the institution blames “the systems”, and nobody can say at which crossing the fact stopped.

What Waits While the Systems Disagree

Separate systems are usually treated as a technology problem for another year. Our reading is that the cost is paid every day, by the offices.

One question gets two answers. Whoever takes the call has to choose which screen to believe.

The registry carries the data. Staff spend their mornings typing what is already on another office’s screen, and their afternoons correcting the copies. They are doing it well. Their time appears in no budget line.

The examination section waits on other offices. The fee status and course registrations it relies on come from someone else’s system, by routes it cannot see.

Every fix is a guess. Asked to “integrate the systems”, the head of IT has no list of where they already touch, so the only proposal anyone can make is to replace everything.

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

Four Ways to Deal With Separate Systems, Weighed

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

Option	When it fits	What it risks
Keep re-typing and reconciling by hand	There are few systems and few records, and staff know which screen to believe	The work grows with every intake and every system, and disagreements are found by whoever is affected
Buy a connection or integration product, or have one built for you	The crossings are already known, and the systems at each end can already send and receive	It joins only the crossings someone has listed, and someone must run and watch it. This is your choice and another firm’s product; we have none
Replace all the systems with one new system	Most of the systems are failing, and the institution can carry a long change	Every office’s screen changes, and the one crossing that hurts most waits for the whole programme. Choosing or installing a packaged product is not our kind of work
Map every place a record crosses between systems, then build the smallest join that helps	The systems are used every day, and a few crossings cause most of the correction	It costs money before anything is joined, a map joins nothing by itself, and some crossings stay hidden until they fail

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
Crossings between systems	Known in parts, to the people who make them	Every one listed: by program, timed file, spreadsheet or person, with what it carries	The map of the system as it stands
Where each key fact begins	An enrolment or fee status typed wherever it is needed	For each, where it is first entered and every place it is copied to	The specification
The source for each fact	Staff know which screen to believe	One system named as the source for each fact, decided by the institution	The specification
Disagreements between systems	Blamed on “the systems”	Each kind traced to the crossing where the two parted	The risk register
Records that already disagree	Corrected as they are found	Listed by the crossing that caused them, and put right by your own staff	Your own records, outside our work

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 your systems, where a record crosses between them, and where two offices last disagreed. 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 admissions, fees, examination or records application your institution built or had built, and the places where it meets your other systems. 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. Here that means the smallest join that helps, built inside a module we rebuild, or the one application that cannot send or receive, rebuilt. 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 have no connection or integration product. We cannot change a packaged student, finance, library or learning product, and we do not install, upgrade or move one. We do not run, host or monitor a connection once it is built; your own team or supplier does, and keeps every old application running while we work. We do not clean, correct, reconcile or migrate records, we do not handle student records, and we do not say whether any record or result is right; our confidentiality terms cover code. We do not say we are empanelled or approved as a supplier to any university, board or government, and we give no advice on procurement 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 a college, a university or any education body.

What changes for the business:

Role	What they gain
Head of institution	When two offices give different answers about the same record, the institution can say where they parted, and stops blaming “the systems”.
Registrar	The registry can see which details its staff re-type from other offices’ systems, and which of that re-typing leads to the corrections they later make.
Head of finance	A fee figure that differs between two systems can be traced to the crossing where the two parted.
Head of IT	A map of every place a record passes from one system to another, by program or by hand, with what is sent, what is re-typed and which system is the source.
Controller of examinations	The examination section knows where each figure it relies on comes from, and which office’s system is the source.

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

The case	What IOanyT does
A very large US university “replaced nearly 80 separate student systems” with a packaged product.	Our part is narrower, the university was not an IOanyT client, and we make no comment on it or on its replacement, which is not our kind of work. For the applications an institution built, we map each one and every place a record passes between them, so the institution can see which crossings to deal with first.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before anyone proposes to replace your systems, we would list where they already touch.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →