Separate Systems That Do Not Agree

1. At a Glance

Issue study · From the public record. The university described here is a very large university abroad, far larger than the colleges, universities, school groups and institutes we write for, and we use it for one point: how many separate systems an institution can come to run. We found no public record of an Indian institution, or of one of our readers’ size, harmed because its systems did not share what they know. Each case is reported as the public record gives it, without judgement on any institution or official.

Organisation type	A very large US university that replaced dozens of separate student systems, set beside the position of a mid-size institution whose admissions, fees, examination, records and timetable systems do not share what they know
Size band	The case: very large. Our reader: a college, an autonomous college, a mid-size university, a school group, a coaching institute or a training body with several systems of its own
Region	The case: US. The reader: anywhere; the rules in section 3 are Indian and English
The decision at stake	What to do about systems that disagree: keep re-typing and reconciling, buy a connection or integration product, replace everything with one new system, or map every crossing and build the smallest join that helps
The public outcome	The university replaced dozens of separate student systems with a packaged product; a senior official described the old student systems as fragile home-grown applications, decades old. The source does not say how those systems were joined, or what their number cost
Why it matters to a mid-size institution	An institution can have many systems that each work and still give two answers to one question. The errors are made where a record passes between systems, and a UGC letter (June 2026) and DfE guidance (September 2026) concern records sent to a national platform or a funder

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

“We have an admissions system, a fees application, an examination application, a records application and a timetable. Each does its job. But an enrolment is typed at admission, again in the registry and again in the examination section, and the fee status on one screen does not always match the other. A program copies enrolments to the timetable every night, and once it stopped and nobody knew for eleven days. In June the records for the upload were put together by hand in the last week. Every supplier we ask says replace all five. I cannot approve that, and I cannot describe what we have.”

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

The institution is caught between systems that each work and offices that need them to agree. The cure it is offered, one new system, is larger than the problem it can describe.

3. What We Found

Method. We went through the public record on colleges and universities whose systems do not share what they know: trade press reporting on two US universities’ systems, a UK university’s statement about a connection it could not make, one sector body’s report on UK universities as carried in the trade press, one cross-sector survey, a letter from India’s University Grants Commission and guidance for providers from England’s Department for Education. The sources were published between 2021 and 2026. The sector research behind this study holds no institution of our readers’ size on this issue, no figure for how much re-typing is done, how often two systems disagree or what a failed transfer costs, and nothing on the scripts, timed files and spreadsheets that join systems in practice.

One university’s count. This is the case we give in most detail, and we use it for one point.

What	Public record
Institution	A very large US university
Its student systems	It replaced dozens of separate student systems with a packaged product; a senior official described the old student systems as fragile home-grown applications, decades old
How the systems were joined, and what their number cost	Not given by the source
The replacement	A packaged product, which is not IOanyT’s kind of work; not used here

A second count. Another large US university spent several years moving hundreds of old systems into one packaged finance and HR system. That move had difficulties of its own, which a consultancy report cited by the press put 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. We use the case for its count only.

A connection that could not be made. 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. We did not examine why the connection could not be made, and draw no cause from it.

What is said about old systems that do not meet. One sector body’s report on old technology in UK universities, as the trade press reported it in 2026, describes the build-up of disconnected and heavily customised old systems as a critical problem across the sector, and warns that it limits institutions’ ability to adopt new technologies such as AI. In one cross-sector survey of about five hundred US IT professionals, about four in ten named incompatibility with modern systems or tools among the top issues with their old systems, and more than four in ten named budget limits and more than a third fear of disrupting operations among the reasons they had not upgraded.

What a letter and guidance say about academic records. These are a letter and guidance, not cases, and we report them only in their issuers’ words.

Source	Public record	To whom it is addressed
UGC letter, 5 June 2026 (India)	Records for Examination Year 2025 were to be uploaded to the NAD/ABC platform by 30 June 2026, and the window would then close: “all credit awarding institutions are required to upload academic records, including marksheets/grade sheets and corresponding credit data”; after the deadline “no further fresh uploads for Examination Year 2025 shall be permitted on the platform”. That deadline has passed. When we checked on 14 October 2026, this letter was the newest item on the NAD/DigiLocker circulars page, and we found no letter for Examination Year 2026	”The VCs of all Universities” and “Directors/ Principals of Autonomous Colleges”. What it means for an institution is for its own registrar, controller of examinations and advisers
Department for Education guidance for providers on the lifelong learning entitlement, updated 24 September 2026 (England)	“Students will be able to apply for finance under the LLE from late October 2026 for courses and modules starting on or after January 2027”; “LLE funding is based on credits”; providers “should also consider” “how admissions and student records systems will support modular learners”	Providers in England that choose to offer courses funded this way. Guidance, not a statute; “should also consider” is the department’s phrase

Our reading of why separate systems cause trouble. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has a list of the crossings. Each office knows its own screen. Nobody has a picture of every place an enrolment or a fee status passes from one system to another.
2. The same facts are entered more than once, by people, by small programs and from spreadsheets, so a slip at one crossing is carried into the next.
3. The joins that exist were never recorded. Scripts, timed files and spreadsheets hold the systems together, stop without telling anyone, and are understood by one person or none.
4. The only cure offered is the largest. With no list of crossings, nobody can propose anything smaller than replacing every system.

Our reading of the letter and the guidance, and only that: an upload put together by hand from several systems spends the window on copying and checking, and a records application that knows only whole years would have to change before it could hold a course counted in credits. Neither the UGC nor the department says any institution’s systems are old or must change. What either asks of an institution is for its own registrar, controller of examinations and advisers.

4. The Options an Institution in This Position Had

Option	When it fits	What it risks	Our view
Keep re-typing and reconciling by hand	There are few systems and few records, and no upload is close	The work grows with every intake; disagreements are found late; records put together by hand use up the window before an upload	Right only for a small institution with few crossings
Buy a connection or integration product, or have one built	The crossings are already known, and the systems at each end can already send and receive	It joins only the crossings someone has listed; someone must run and watch it	The institution’s own choice and another firm’s product; IOanyT has none. Better after the crossings are mapped
Replace all the systems with one new system	Most of the systems are failing, and the institution can carry a long change	Every office changes at once; systems that work are thrown out; the crossing that hurts most waits for the whole programme	The institution’s own decision, and choosing or installing a packaged product is not IOanyT’s kind of work; we would advise against this as the first answer, and it is sometimes right as the last
Map every crossing, then build the smallest join that helps, module by module	The systems are used every day, and a few crossings cause most of the correction	Costs money before anything is joined; each join is one more thing to look after; some crossings stay hidden until they fail	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, examination and results, records and certificates, timetables and portals), and the places where they meet the institution’s other systems: map first. List every place a record crosses between systems, including by hand, by timed files, by scripts and by spreadsheets. Trace each kind of disagreement to the crossing that causes it, and have the institution name one system as the source for each fact. Then deal with the crossing that causes most correction by the smallest join that helps: one connection built inside a module rebuilt, or one application rebuilt, module by module, while the old arrangement keeps running, each module checked against what it replaces with a traceability matrix. Give each join an owner at the institution. Replacing everything comes last, and is sometimes right. 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
Crossings between systems, by program and by hand	Known in parts, to the people who make them	Every one mapped: what it carries, from where to where, how often, and whether a program or a person makes it	The map of the system as it stands
An owner for each join	Nobody, or whoever set it up	A named owner at the institution for every join	The list of joins beside the specification
Details typed in more than once	Not counted	Each listed, with one system named as its source by the institution	The specification
Disagreements between systems	Blamed on “the systems”	Each kind traced to the crossing that causes it	The risk register
Joins rebuilt	Left alone, because they work	The ones that matter rebuilt as modules, each with an agreed check against what it replaces before it is accepted	The traceability matrix
The size of one commitment	One new system, or nothing	One module, with the freedom to pause after any accepted module	The staged plan
Records that already disagree	Corrected as they are found	Listed by the crossing that caused them, and put right by the institution’s own staff	The institution’s own records, outside IOanyT’s work

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your systems, where a record crosses between them, and the last time two offices 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 study 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, records or timetable 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.
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. 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 institution’s own applications do, in writing, with every crossing between its systems that the assessment finds and the staff point to.
• The risk register: the crossings behind the most correction, listed before any price is set.
• The list of joins: each with what it carries and an owner at the institution.
• 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.

Running the joins, correcting the records that already disagree, every upload and every judgement on a record, and every decision about what a rule or guidance asks belong to the institution and its advisers.

9. What This Approach Does Not Cover

• IOanyT has no connection or integration product, and does not sell or license one. A connection layer is the institution’s own choice and another firm’s product.
• IOanyT cannot change a packaged student, finance, library or learning product, and does not install, upgrade, move or choose one. Where such a product sits at the end of a crossing, IOanyT works only with what it already lets other programs send and receive; a product that lets nothing in or out cannot be joined by IOanyT at all.
• IOanyT does not run, host or monitor a connection or a rebuilt module once it is built, and is not told when one stops. The owner of each join is someone at the institution, and the institution or its supplier keeps every old application running while modules are rebuilt.
• IOanyT does not clean, correct, reconcile or migrate records, including what went astray while a join was down, and does not handle student records. Its published confidentiality terms cover code.
• IOanyT does not upload records to any platform, prepare or check marksheets or credit data, or say whether any record or result is right. Every record stays with the examination section and the registry.
• Tests for a rebuilt join, and watching it once it runs, are for the institution’s own team or a firm it chooses; they work from the specification and the traceability matrix.
• Some crossings will be missed until they fail, because nobody remembers them. Crossings made by hand appear in no code; only the institution’s staff can point to them. A join is one more thing to look after, and several joins can become a tangle of their own.
• IOanyT offers no compliance, audit or legal advice and does not say what the UGC’s letter, the Department for Education’s guidance or any other rule requires of a particular institution.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any university, board or government, or that it meets the conditions of any tender. It gives no advice on procurement rules, and does not say an institution’s budget year, governing-body approval or tender will fit any of its terms.
• IOanyT reads the old technologies it names (VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP), not COBOL, RPG, FoxPro or mainframe systems.
• This study does not say IOanyT would have prevented anything at the universities described. IOanyT has no published case of this work for a college, a university or any 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
The Register, 2025	One very large US university: dozens of separate student systems; a senior official’s description
The Register, 2024	A second US university: hundreds of old systems, and the causes the press gave for its difficulties
The Register, 2021	One UK university: the connection that could not be made as planned; the project scaled back
Trade press report of a sector body’s report, 2026	Disconnected and heavily customised old systems across the sector, and their effect on adopting new technologies
A vendor’s survey, 2025	Incompatibility, budget limits and fear of disrupting operations
UGC public notice and letter, 5 June 2026 (on the NAD/DigiLocker site)	The upload of Examination Year 2025 records by 30 June 2026
Department for Education, LLE guidance for providers, updated 24 September 2026	Credit-based funding from January 2027; “how admissions and student records systems will support modular learners”

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Your systems already touch in more places than anyone has written down; we list them before anyone proposes to replace them.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →