The Upgrade Is Your Team's to Do. Here Is the Benchmark We Would Set to Check It Against.

The database was upgraded over a long weekend. On Monday every application opened, and the IT office allowed itself a quiet cup of tea.

On Thursday a clerk in accounts noticed a late fee worked out to the rupee, where it had always been rounded to the nearest ten. Nobody had changed the rule.

The fee was corrected by hand. Then the real question arrived. If that changed, what else did? Nobody could say. There was nothing to compare the applications with, except what people remembered.

What We Found

For this article we went through the public record on how changes to old systems are checked: one developer’s account (2025), a tool maker’s 2025 survey of developers whose main language is PHP, the published support dates of two widely used databases, and one cross-sector survey of about 500 IT professionals in the US (2025).

First, what we did not find: nothing on how institutions check a database upgrade, no figure for how often an upgrade changes results, and nothing from India or the Middle East. Everything below is about developers and organisations in general.

Developers themselves fear changing an old system without checks. One developer put it plainly: “There’s nothing scarier than making changes to a critical legacy system with no tests.” A test, here, is a small automatic check that an application still gives a known answer. This is one person’s account.

Automatic checks are far from universal. In one tool maker’s survey of more than 1,500 developers whose main language is PHP, a common web language, about a third said they still do not write tests at all. Not writing automatic tests is not the same as doing no checking; it means the check is done by hand, or from memory.

The next date is already set. For MySQL, a widely used database, version 5.7 reached the end of its support on 31 October 2023, and version 8.0 on 30 April 2026. An institution that upgraded from one to the other has already met the next date. For SQL Server 2016, extended support ended on 14 July 2026, and extended security updates are available only to 17 July 2029.

Fear of disruption keeps old systems in place. In one survey of about 500 IT professionals in the US, not about education and from a firm that sells related services, nearly four in ten named fear of disrupting operations among their reasons for not upgrading old systems.

Our reading: an upgrade is feared mostly because it cannot be checked. Nobody wrote down what each application should produce, so there is nothing to compare with afterwards. The fix is not a braver weekend. It is a specification and a benchmark agreed before the upgrade, so the institution’s own team can check the results before and after.

What a Checkable Upgrade Opens Up

The usual view is that an upgrade is a risk to get through on a quiet weekend. Our reading is that an upgrade the team can check opens up four things.

The upgrade becomes ordinary work. When the team can see what changed, the next end-of-support date is a piece of scheduled work and not a crisis.

Differences are found before the offices open. A sum worked out differently is on a list on Sunday evening, not noticed by a clerk on Thursday.

There is a rule to decide from. When a result differs, someone can look up what the application is meant to do, and rule on it.

The application that pins the database can move too. Its rebuilt modules are checked against the same specification before they take over.

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

Four Ways to Check an Upgrade, Weighed

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

Option	When it fits	What it risks
Open each application and see	The applications are simple	Opening is not agreeing; an application can start perfectly and calculate differently
Ask each office to check its own work by hand afterwards	The offices know their outputs well	People check what they expect, from memory; differences are found late
Automatic tests written by the institution’s own team, or by a firm it chooses	The team has people who can write and keep them, and a way to make example cases from its own records	Tests cover only the cases someone named, and a test built from today’s results protects an old mistake as faithfully as an old rule. Building them is the institution’s own choice and work, not ours
A written specification and a benchmark first, then the institution’s own team checks results before and after against them, with tests where the team chooses	The institution wants every upgrade to be checkable, and one application may be pinning the database	It costs money before anything is upgraded, and the checking is still the team’s work

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 with a written verdict	None, or from memory	Each has a verdict: moves as it is, needs a small change, or has to be rebuilt	The risk register
Rules kept inside the database	On nobody’s list	Each one listed and described in plain language, confirmed by the institution’s own experts	The specification
The application that pins the database	Marked “do not touch”	Its modules rebuilt one at a time, each accepted against the specification	The traceability matrix, module by module
Results before and after the upgrade	”It seems fine”	The institution’s own team checks the agreed results before and after, against the specification; a named person rules on each difference	The institution’s own check record
The next end-of-support date	Feared, and put off	Known, with the upgrade planned by the institution’s own team	The institution’s own plan

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.

A small part of a finished benchmark might look like this.

Application	Verdict	Who checks the upgrade
Admissions	Moves as it is	Your team, against the specification
Fees	Small change to one report	Your team or a firm you choose; the accounts office rules on differences
Examination application	Needs the old version: rebuilt module by module	Each module accepted against the specification before the upgrade
Learning platform	A packaged product	Outside our work

The rows above are an illustration, not taken from a real institution.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the last upgrade and what was found afterwards. 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 the applications that use the database, and what each of them should produce. 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, onto technology that is still supported. Here that means the application that keeps the database on the old version, where there is one. 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.

This has a price. You pay for the assessment before anything is upgraded, and the specification and the benchmark check nothing by themselves: your own team, or a firm you choose, does the checking and decides whether to write automatic tests. A case nobody thought of can still slip through. A result that matches the old one does not show the old result was right, and we give no view on whether any result is right. We do not upgrade, patch or migrate a database, or supply extended security updates. We do not handle student, fee or results records, or supply example cases taken from them; our confidentiality terms cover code. We do not carry out a security review, and until your team upgrades it the database is exactly as unsupported as before. We do not work inside a packaged student or finance product. We do not say we are empanelled with any government or university, 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 specification, the risk register, the benchmark, and the traceability matrix and code for every module we rebuilt. The upgrade, the checks and any tests are your team’s, or a firm you choose.

What changes for the business:

Role	What they gain
Head of institution	Keeping the database on a supported version becomes ordinary work for the institution’s own team, and stops being a crisis each time a date arrives.
Registrar	After an upgrade, the registry’s own outputs have been compared with the old ones, against a written specification, before any office relies on them.
Head of finance	Differences from an upgrade are found in a check the institution’s team runs beforehand, and not afterwards in corrections and overtime.
Head of IT	A written specification and an agreed benchmark, so the team can upgrade on a copy and see what changed before any office does.
Head of information security	The next end-of-support date can be met when it comes, because the institution has a way to check an upgrade.

None of these means the database is secure or cannot be attacked.

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

The case	What IOanyT does
MySQL 5.7 reached the end of its support on 31 October 2023 and 8.0 on 30 April 2026.	Our part is narrower. We do not upgrade databases or supply updates. We write down what each application should produce and agree the benchmark, so the institution’s own team can check each upgrade.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The upgrade and the checking are your team’s; we supply the specification and the benchmark to check them against.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →