Your Systems Are Already Joined, by Scripts, Files and Spreadsheets. Here Is the Benchmark We Would Set.
A nightly program stopped and two courses showed last term's class lists. Here is the benchmark we would set for the scripts, timed files, spreadsheets and hand-offs that already join an institution's admissions, fees, examination and timetable systems, what we would rebuild, and what we will not claim.
It is the second week of term. The timetable office notices that two courses still show last term’s class lists. The enrolments were made in the admissions system weeks ago. They never reached the timetable.
It takes a day to find out why. Every night at two, a small program copies new enrolments from one system to the other. Eleven nights ago it stopped. It raised no alarm, because it was never built to.
The program was written nine years ago by a colleague who has since moved on. It is on no list of the institution’s systems. Until this week, nobody in the IT office knew it was there.
The paradox: The institution says its systems are not connected. They are, by things nobody knows are there.
What We Found
For this article we went through the public record on how colleges and universities join their systems when the systems do not share on their own, and on what it costs when a join stops.
First, what we did not find: no public evidence at all on the scripts, timed files and spreadsheets that join admissions, fees, examination and timetable systems in this sector. No count, no case and no cost, in India or anywhere else. What follows is the nearest the record comes, and it is about something a little different.
Where there are many systems, there are many places where they meet. One large US university, as the trade press reported in December 2025, “replaced nearly 80 separate student systems” with a packaged product. The source does not say how those systems were joined, and we do not guess. We give the count for one reason: nobody would suppose that every pair of those systems that needed to agree was joined by something designed and written down.
One sector body sees disconnected systems as a sector-wide problem. One sector body’s report on old technology in UK universities, as the trade press reported it in March 2026, describes “the accumulation of disconnected and highly customised legacy systems” as “a critical, sector-wide issue”, and warns that these systems are “limiting institutions’ ability to adopt emerging technologies such as AI”. 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.
What our review does not show: Everything this article says about scripts, timed files and spreadsheets as joins is our reasoning, and the scene is imagined. The university’s count says nothing about how its systems were joined; it is very large, abroad, and was bringing in a packaged product. The sector body speaks of UK universities as a whole. The survey is cross-sector, from a firm that sells related services. We found no institution of our readers’ size with this problem, nothing from India or the Middle East, no figure for how often a join stops, and no evidence that rebuilding a join prevents a later failure. We claim none.
What a List of Your Joins Opens Up
A list of the places where records cross between systems is usually seen as the IT office’s homework. Our reading is that it frees more than that office.
- Failures get an owner. A stopped program becomes someone’s job before it becomes last term’s class lists, or a short list on the registry’s desk.
- Disagreements get a cause. A fee status that differs between two offices is traced to the join where it changed.
- Change becomes possible. A join that is written down can be altered when a system is updated. An unknown one can only be avoided.
- The hand-offs get counted. The copying staff do between screens is real work. Once it is listed, it can be reduced stage by stage, and the people doing it move from copying to checking.
The gap we see: most institutions we write for know their systems are joined by something. Few can list every join, name its owner, and say which joins are made by people. The difference between that and an institution that can change one system without breaking another is a written list, with an owner beside every line.
This is our reading. It is not a measured market figure.
Three Ways to Look After the Joins You Have, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Fix each join when it fails | There are few joins, and the people who made them are still there | Each failure is found by its effects, often days later. Each repair adds one more rule nobody wrote down |
| Put a connection or integration product across the systems, bought from a supplier or built for you, and move the joins onto it | The joins are already known, and the systems at each end are sound | The joins nobody listed are not moved, and keep running beside it. Someone must run and watch it. This is your choice and another firm’s product; we have none |
| List every join, give each an owner at the institution, and rebuild the ones that matter as modules | The systems are used every day, and some joins carry rules the institution depends on | It takes stages and costs money before anything is rebuilt. Some joins will be missed until they fail |
Our recommendation: list every join first, including those done by hand, by timed files, by scripts and by spreadsheets, and give each one an owner at the institution. Trace each kind of disagreement to the join that causes it. Then rebuild the joins that matter as modules, while the old arrangement keeps running, each rebuilt module checked against what it replaces, by a check agreed with you before the module is accepted. If you also want a connection or integration product, that is your choice and another firm’s product, and the list is what it needs. We have no connection or integration product. We do not run or monitor a join once it is rebuilt; the owner on your side does. We cannot change a packaged product.
Where You Are Now, and Where You Should Be
This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.
| 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 detail typed in more than once listed, with the system named as its source | The specification |
| The rules each join applies | Known only to the code or the person | Written in plain words, each marked keep, correct or retire by the institution | The specification |
| 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 | A new system, 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.
A small part of the finished list might look like this.
| Join | Made by | Owner | Status |
|---|---|---|---|
| Enrolments from admissions to the timetable | A nightly program on a spare machine | Head of IT | Its rules written down; rebuilt as a module and accepted in stage 1 |
| Course lists from the registry to examinations | A clerk re-typing from a printout | Registrar | Counted; the records application named as the source; in the stage 2 plan |
| Fee status from fees to examinations | A spreadsheet sent by email before each cycle | Finance officer | Listed; in the stage 3 plan |
| Receipts from the bank | The bank’s own file | Not ours | Outside our work |
The rows above are an illustration, not taken from a real institution.
How We Work With You, and What You Are Left With
- We listen: a free Reliability Review. A first conversation about your systems, the joins you know about, and the last one that stopped. 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.
- 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.
- 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the joins that matter, rebuilt inside the modules we rebuild. 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.
- We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted 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.
This has a price. Some joins will be missed until they fail, because nobody remembers them. Joins made by hand appear in no code, so only your staff can point to them; they are the finding, never the fault. Writing down the rules will turn up some that nobody can explain, and each needs a decision from the institution. A spreadsheet that rests on someone’s judgement is not wholly replaced by a program. If your own team, or a firm you choose, wants to write tests for a rebuilt join or to watch it once it runs, they work from the specification and the traceability matrix; that work is theirs, not ours. We have no connection or integration product. We do not run, host or monitor the joins or the rebuilt modules; the owner on each line is someone on your side. We cannot change a packaged product; we work only with what it already lets other programs send and receive. We do not clean, correct, reconcile or migrate records, including what went astray while a join was down, and we do not handle student records or say whether any record or result is right; your registry and examination section answer for those. None of this makes several systems into one. 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.
At the end you hold the list of joins with an owner beside each, the specification, the traceability matrix for every module we rebuilt, the code of those modules, and the filled-in benchmark.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of institution | The institution no longer depends on a nightly file and a spreadsheet that one person understands. |
| Registrar | Every join the registry depends on is on a list with an owner, and the registry is no longer the first to notice from a list that looks short. |
| Head of finance | The joins that carry receipts between systems are on a list with an owner, so a stopped one is someone’s job before it becomes a term-end reconciliation that will not close. |
| Head of IT | Every script, timed file and spreadsheet that joins the systems is written down with an owner, and every join rebuilt as a module is checked against the old one before it is accepted. |
| Controller of examinations | Every file the section depends on before a cycle is on a list with an owner at the institution, so a missing one is someone’s job before the section finds out on the day. |
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: we found no public evidence on the scripts, files and spreadsheets that join an institution’s systems. Its figures come from a trade press report on one large US university, a sector body’s report on UK universities and one vendor’s survey, which we do not name. | For an institution’s own applications, we list the joins its systems already depend on, including those done by hand, and rebuild the ones that matter as modules. We do not run or watch them afterwards, and we do not correct records. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next time a join stops, the institution should already know it exists and who owns it.