When a Record Is Typed in Three Offices, Replacing Everything Is One Answer of Four.

The committee on administrative systems has met for a year. Its report recommends a single new system for admissions, fees, examinations, the library and the timetable, at several times what the institution spends on technology in a year.

The registrar thinks of two smaller things. Fee receipts still do not reach the examination section until somebody carries them across. And in June, the records for the upload to the national platform were put together by hand, from two applications and a spreadsheet, in the last week before the window closed.

Both are crossings between two systems. The report on the table replaces all five.

What We Found

For this article we went through the public record on the records that pass between an institution’s systems and what official texts have said about them: a letter from India’s University Grants Commission of June 2026, guidance from England’s Department for Education updated in September 2026, a UK university’s statement about a connection it could not make, and one cross-sector survey.

First, what we did not find: no source that ties the letter or the guidance to any institution’s old systems, no case of an institution that missed an upload because its systems were separate, and no figure for what a single join, or a single new system, costs a college.

In India, the UGC set a window for uploading academic records. 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. The letter, addressed to “The VCs of all Universities” and “Directors/ Principals of Autonomous Colleges”, says that “all credit awarding institutions are required to upload academic records, including marksheets/grade sheets and corresponding credit data”, and that after the deadline “no further fresh uploads for Examination Year 2025 shall be permitted on the platform”. It adds that “A timely upload of academic records with APAAR ID is essential for the effective implementation of the Academic Bank of Credits ecosystem”. 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 letter says nothing about any institution’s own systems. What it means for your institution is for your own registrar, controller of examinations and advisers.

In England, DfE guidance says “LLE funding is based on credits”. The Department for Education’s guidance for providers on the lifelong learning entitlement, updated on 24 September 2026, says: “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.” It says that “LLE funding is based on credits. This means fees are based on the number of credits, not years of study.” And among the things a provider “should also consider”, it lists “how admissions and student records systems will support modular learners”. This is guidance, not a statute, for providers in England that choose to offer courses funded this way; “should also consider” is the department’s phrase, and we do not turn it into a duty.

A join is not always possible. At one large UK university, in an older case from 2021, a spokesperson said the packaged student record product it was bringing in could not be joined to its 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.

Organisations hold back from the large cure. In one cross-sector survey of about five hundred US IT professionals, not about education, 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 Waits While a Record Is Typed in Three Offices

The better question is what the institution cannot do while it waits for one new system.

Records put together by hand. Our reading, and only that: an upload put together by hand from several systems spends the window on copying and checking, and where an enrolment, a credit or an identifier is held differently in two systems, the copying waits until someone at the institution settles it. A records application that knows only whole years would have to change before it could hold a course counted in credits. Neither the UGC’s letter nor the department’s guidance says this. Whether either applies to your institution, and what it asks of it, is for your registrar, your controller of examinations and your advisers.

The examination section’s hand-overs. While fee status and course registrations come by file and by telephone, every cycle begins with checking.

This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own institution.

Four Ways to Answer 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 no upload is close	The work grows with every intake, and records put together by hand use up the window before an upload
Buy a connection or integration product, or have one built for you	The crossings are 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. 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 changes at once, systems that work are thrown out, and the 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, module by module	The systems are used every day, and a few crossings cause most of the correction	It costs money before anything is joined. Each join is one more thing to look after, and several joins can become a tangle of their own

The honest costs. A join is one more thing to look after, and it can fail, or need changing when a supplier changes its product. A packaged product that lets nothing in or out cannot be joined by us at all. And a join does nothing for records that already disagree; your own staff put those right, and every record uploaded or issued stays with your examination section and registry.

Where You Are Now, and Where You Should Be

Before a replacement is quoted, we would set a benchmark for the decision.

Measure	Typical starting point	Where it should be	How it is checked
Answers weighed	One: replace everything, or wait	Four, each weighed against the crossing that causes most correction	The cost comparison
How a record reaches an upload or a return	Put together by hand from several systems, not written down	Every step written down, with which system each part comes from and who checks it	The map of the system as it stands
The cost of staying as you are	Never counted: copying, checking, corrections	Set beside the price of each stage	The cost comparison
The cost of change	One large replacement estimate	A price for each stage, set after the system is read	The staged plan and quote
The size of one commitment	Everything at once, or nothing	One module, with the freedom to pause after any accepted module	The staged plan

The starting points above are what we expect to find; in an engagement they are replaced by your own position, 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 and where a record crosses between them. 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 you need to bring: the assessment, bought in whatever way your own rules require; what each supplier publishes about how its product sends and receives data; an hour each from the staff who copy details between systems; an owner on your side for each join; and your own team keeping every system running.

What we do not do: we have no connection or integration product, we cannot change a packaged product, and we do not run, host or monitor a connection or any of your systems. We do not clean, correct, reconcile or migrate records, or handle student records. We do not upload records to any platform, prepare or check marksheets or credit data, or say whether any record or result is right; that stays with your examination section and registry. Acting on the UGC’s letter, the department’s guidance or any other rule is your own work: we offer no compliance or legal advice. We do not say we are empanelled with any university, board or government, and how each stage is 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	Joining the systems stops being a choice between doing nothing and replacing everything.
Registrar	One piece of daily re-typing ends, and the staff who did it check the exceptions in place of copying.
Head of finance	Money goes to the one join that causes the most correction, and the rest can wait until it has proved its worth.
Head of IT	One connection or one rebuilt application at a time, each proven against what it replaces, with everything that works left working.
Controller of examinations	The one hand-over the section waits on most reaches the examination application by a route that is written down and owned, and not by a file and a telephone call.

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

The case	What IOanyT does
This article names no institution as a case of the problem. Its figures come from a UGC letter, the department’s guidance, one UK university’s statement and one vendor’s survey.	We map where a record crosses between an institution’s own applications, and rebuild, module by module, the one that cannot send or receive. Whether a rule applies, any upload and every judgement on a record stay with the institution.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before you approve one system to replace them all, we would find the one crossing that causes most of the correction.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →