Nobody Can Say What a Database Upgrade Would Break. Here Is What the Public Record Shows.

The auditor’s list of questions has one about software. Is the database that holds the institution’s records supported by its maker?

The honest answer is no. Support for that version ended years ago.

Then why have we not upgraded it? Because four applications use that database, each written for that version, and nobody knows what an upgrade would do to any of them.

What We Found

For this article we went through the public record on databases kept past their makers’ support dates: the published dates of two widely used databases, one monitoring service’s 2026 report, and one cross-sector survey of about 500 IT professionals in the US (2025).

First, what we did not find: no college or university on record harmed because its database was out of support, nothing from India or the Middle East, and no figure for what an upgrade or extended security updates cost an institution. Which databases institutions run was not part of the research.

Support ends on a published date. For SQL Server 2012, a widely used database, extended support ended on 12 July 2022 and its extended security updates ended on 8 July 2025. For SQL Server 2016, extended support ended on 14 July 2026, with extended security updates available to 17 July 2029. For MySQL, another widely used database, version 5.7 reached the end of its support on 31 October 2023 and version 8.0 on 30 April 2026.

Old versions stay in use. Among the customers of one database monitoring service in 2026, a small share ran SQL Server 2014 or older and a slightly larger share SQL Server 2016: together about one in seven on versions now out of support. The sample is one firm’s own customers, with no geography given.

Old systems are kept because they still work. In one survey of about 500 IT professionals in the US, not about education and from a firm that sells related services, about six in ten organisations still used legacy systems. Half said the biggest reason they had not upgraded is that the current system still works, and more than four in ten named budget limits. Among top challenges, more than four in ten named security weaknesses and about a third lack of vendor support or updates.

Our reading: the upgrade is put off because nobody has listed what stands on the database: the applications, the rules kept inside it, the jobs that run at night, and what each needs from the old version. Without that list, the only way to size the upgrade is to try it.

What Waits While Nobody Can Say

Our reading is that several things cannot move until someone can say what stands on the database.

The upgrade cannot be sized. An estimate from memory is a range: “a few weeks, or most of a year”. Finance cannot approve a range, and the auditor’s question keeps its answer: “planned”.

The exception cannot end. The same exception is renewed each year, because nobody can say which application keeps the old version.

One application may be holding all of them. If one needs the old version, every application that shares the database stays with it.

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

Four Ways to Find Out What an Upgrade Would Break, Weighed

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

Option	When it fits	What it risks
Try the upgrade on a test copy and see what fails	The applications are few, recent and well understood	A program that stops is found; one that gives a different answer may not be. A failed trial often ends the trying. This is the institution’s own team’s or database supplier’s work
Ask the people who look after each application for an estimate	A first view is needed quickly, and those people are still there	A range made from memory; rules kept inside the database are on nobody’s list
A check of the database itself, version against version, by the institution’s team or database supplier	The worry is the database’s own features and settings	It shows what the database uses, not what each application does with it
An assessment that reads each application, records what it needs from the database version, and gives a verdict for each	The upgrade must become a plan, a budget line and a date	It costs money before anything is upgraded, and upgrades nothing: the database is exactly as unsupported the day after

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 and jobs that use the database	Known in part, from memory	Every one named, with what it needs from the version	The map of the system as it stands
Rules kept inside the database	On nobody’s list	Each one listed in plain language, confirmed by the institution’s own experts	The specification
A verdict for each application	”We will find out when we try”	Moves as it is, needs a small change, or has to be rebuilt, with the reason	The risk register
The upgrade as a budget line	A range, carried forward	Sized jobs, beside the cost of staying	The cost comparison
The exception for the old version	Renewed every year	Tied to the application that keeps it, with a planned end	The risk register and the staged 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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the database and the applications that use it. 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 admissions, fee and examination applications the institution built or had built, and what each needs from the database under it. 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, rebuilt so that your own team can upgrade the database. 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 we do not do: we do not upgrade, patch or migrate a database, or supply extended security updates; your own team or database supplier does the upgrade. We do not move or check records, and we do not handle student, fee or results records; our confidentiality terms cover code. We do not carry out a security review or keep the old application secure, 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, and the old technologies we read are VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, and .NET Framework and classic ASP. We do not say we are empanelled with any government or university, and we give no advice on procurement rules: how an assessment and the stages after it are 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	An unsupported database stops being a thing the institution hopes will last, and becomes a list the governing body has seen, with a decision beside each line.
Registrar	The registry knows which of its registers, certificates and returns rest on the old database, and which an upgrade would touch.
Head of finance	The upgrade has a size, so it can be budgeted against the cost of staying, and is no longer an open line in every year’s plan.
Head of IT	For each application, a written list of what it needs from the database, with a verdict: moves as it is, needs a small change, or has to be rebuilt.
Head of information security	A question about unsupported systems can be answered with a list: which database, what stands on it, and what is planned.

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

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We cannot make an unsupported database safe, and will not claim to; we can tell you what stands on it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →