Your Replacement Is One Programme With One Go-Live, Years Away. Here Is the Benchmark We Would Set.
A single replacement programme gives every office nothing for years, then changes everything at once. We went through the public record, weigh four ways to run a replacement, and set out the benchmark we would agree with an institution before the first stage.
The programme plan has one date on it, three years from now. On that date admissions, fees, examinations and the portal all move to the new system together.
Until then, nothing changes. Every request to improve the old screens gets the same reply: after go-live. The new system is being built in a room no clerk has entered.
The finance officer asks a fair question at the review meeting. If the programme stopped at the end of the second year, what could the institution switch on? The answer is nothing.
The paradox: The programme is meant to help every office, and for three years the only thing it gives them is a date.
What We Found
For this article we went through the public record on how replacements at universities have been run: trade press reporting in 2024 on one US university’s finance and HR programme and in 2021 on one UK university’s student records programme, and one cross-sector survey of US IT professionals from 2025.
First, what we did not find: no public case at a mid-size institution, a private college, a school group or a coaching institute; nothing from India or the Middle East on this issue; and no figure for how long a replacement takes at an institution of our readers’ size. Both cases below are very large universities abroad bringing in packaged products, which is not our kind of work.
When one programme moves a great deal at once, the strain is felt widely. One 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, and we keep them. 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 these difficulties have since been resolved is not in the research we hold.
Long programmes can be scaled back part-way. 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 record does not say why the change of plan came when it did.
Fear of disruption keeps old systems in place. In one cross-sector survey of about five hundred US IT professionals, which is not about education, nearly four in ten named fear of disrupting operations as a reason they had not upgraded.
Our reading: a programme with one go-live puts every office’s change into the same weeks, and nothing is in use until then. A pause part-way leaves an institution with money spent and nothing it can switch on.
What our review does not show: We found no case at an institution of our readers’ size, and nothing from India or the Middle East on this issue. Both cases are very large universities abroad bringing in packaged products, and one is an older case. The US case’s difficulties have causes in the record, which we give; we do not say that a single go-live caused them. The survey covers every sector. That a staged replacement spreads the change is our reasoning, not a finding of any source, and it may take longer on the calendar. We make no comment on any university’s choices.
What Changes When Each Module Is in Use
The usual view is that a replacement is one piece of work with one finish. Our reading is that the same work, done one module at a time, opens up three things a single programme cannot.
Something is in use within the first stage. One module replaces one part of the old application and goes into use when the institution accepts it. The office that uses it finds its faults while they are few.
The old applications carry everything else. They stay in use, kept running by the institution’s own team or supplier, for every part not yet moved. Nobody changes everything in the same weeks.
A pause leaves working parts. If the money or the priorities change, the institution can pause after any accepted module, and what has been delivered is its own.
The gap we see: most institutions we write for have a replacement plan with one date on it, or a proposal for one. Few have a plan in which each module is priced, accepted by the office that uses it, and checked against a benchmark agreed before the work began. An institution with one can see at each review what it has, what it paid and what is left.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Run the Replacement, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Patch and keep the old applications | They still work, and the people who know them are still there | Nothing is replaced; each year of patches adds to what the eventual replacement must match |
| One programme to bring in a packaged product, with one go-live | The institution’s work matches what the product does as it comes, and it can absorb a hard first season | Every office changes in the same weeks. Not our kind of work; for some institutions it is the right choice |
| One programme to rebuild everything custom, with one go-live | The applications are small and fully documented | Nothing is in use until the end, and a pause part-way leaves nothing to switch on |
| Assess first, then replace module by module, each accepted by the office that uses it, with the old applications running | The applications are the institution’s own, and it wants something in use early and the freedom to pause | Two systems run side by side for a time, some staff use both, and the whole may take longer on the calendar |
Our recommendation: for applications an institution built or had built, read them first, price each stage, and replace one module at a time. Each module goes into use when the office that uses it accepts it, and the old applications, kept running by the institution, carry everything not yet moved. Where a packaged product fits better, that is the institution’s decision, and not work we do. Any check the institution wants of a module before it accepts it, such as running a past cycle’s data through both, is the institution’s own team’s option, or a firm it chooses; we supply the specification and the benchmark to check against.
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 |
|---|---|---|---|
| Applications in scope | A list of five systems | Each application listed, with its platform and the office that owns it | The map of the system as it stands |
| Price of each stage | One figure for the whole | Each stage priced, beside the cost of staying | The staged plan with its fixed quote, and the cost comparison |
| Modules in use | None until go-live | Each module in use once the institution accepts it | The benchmark review after each module |
| Proof that a module does what the old one did | A go-live date | Every old function linked to its replacement | The traceability matrix |
| 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 |
| Who accepts each module | A committee signs one completion | The office that uses it | The benchmark review after each module |
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
- We listen: a free Reliability Review. A first conversation about the replacement plan, what is in use today and what the offices need first. 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 the set of applications the institution 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. You get the options and our recommendation.
- 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. 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.
- 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 do not implement, configure or move a packaged student, finance, HR or learning product. We do not keep the old applications running or secure while they are replaced; the institution’s own team or supplier does. We do not move, clean or correct student, fee or results records, and we do not vouch for any result. We do not train staff or manage change as a service. We do not say a staged replacement is quicker or cheaper overall. We do not say we are empanelled with any government, university or board, and we give no advice on purchasing rules: 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 | The institution is never years into a programme with nothing in use, and can pause after any accepted module with what has been built still working. |
| Registrar | Offices meet one change at a time, and keep the old screens for everything not yet moved. |
| Head of finance | Each stage approved ends with a module in use, so money spent and something working arrive together and not years apart. |
| Head of IT | Each module goes into use when it is accepted, so the team learns from real use early and is never years from its first delivery. |
| Controller of examinations | The examination modules move as a stage of their own, and the old application stays in use, run by the institution, until the section accepts the new one. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| One large US university moved hundreds of old systems into one packaged finance and HR system; research grants were held up in processing, and a consultancy report cited by the press named a shortage of IT skills, pandemic lockdowns, unclear priorities and delayed decisions. | We do not implement packaged products, we make no comment on that programme, and our part is far narrower. For applications an institution built, we replace one module at a time with the old applications still running, and we never do a single cutover. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We replace one module at a time, each in use once it is accepted, and measure every module against a benchmark agreed before the first.
Sources
- Trade press, 2024
- Trade press, 2021
- A vendor's survey, 2025
In this issue
Replacement is very costly
Research note 1
Your Replacement Was Scoped From the Systems Everyone Could Remember. Here Is What the Public Record Shows.
A replacement scope set from memory leaves out much of what an institution runs. What the public record shows, four options weighed, and our benchmark.
Research note 2
While One Large Figure Waits for Approval, New Options Wait Too. Four Ways to Replace, Weighed.
A replacement arrives as one figure nobody can judge, and new options such as a second intake wait. Four ways to replace, weighed, and what each risks.
Issue study
Priced Before It Was Read
What replacing old student and finance systems has cost large universities, from the public record: the options, what we would advise against, our benchmark.
More from Education
Slow or faulty results processing
The Rules Your Results Application Applies Keep Changing. Four Ways to Make a Change You Can Check, Weighed.
Locked to one supplier
Changing Supplier Does Not Have to Rest on One Handover Day. Here Is the Benchmark We Would Set.
Unsupported databases