One Old Application Can Keep Every Other on an Unsupported Database. Four Ways Out, Weighed.

The institution tried the upgrade last summer, on a test machine. Three of the four applications came up without complaint.

The fourth did not. It is the examination application, written fourteen years ago by a firm that has since closed. It opened, and every report it produced was blank.

So the test machine was switched off, and the database stayed where it was. Admissions, fees and the portal are ready for a newer version, and wait for the one that is not.

What We Found

For this article we went through the public record on what happens while a database stays on an old version: the published support dates of two widely used databases, one cross-sector survey of about five hundred IT professionals in the US (2025), and the University Grants Commission’s letter of 5 June 2026 on uploading academic records.

First, what we did not find: no college or university on record kept on an old database version by one application, no figure for what staying costs an institution, and nothing on which databases Indian institutions run.

Extended security updates buy time, and the time ends. For SQL Server 2012, a widely used database, extended support ended on 12 July 2022, and even 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 8.0 reached the end of its support on 30 April 2026. After such a date, a newly found flaw stays open unless updates are still offered and bought.

Organisations hold back for understandable reasons. In one survey of about five hundred IT professionals in the US, not about education and from a firm that sells related services, more than a third each named fear of disrupting operations and data migration concerns among their reasons for not upgrading old systems. Among the top challenges of those systems, about four in ten named high maintenance or support costs.

What the UGC wrote on 5 June 2026. 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 covers “academic records, including marksheets/grade sheets and corresponding credit data”, and says a timely upload 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 institutions’ own systems. What it means for an institution is for its own registrar, controller of examinations and advisers.

Our reading, and only that: the one application that keeps a database on an old version may be one that holds records of the kind the UGC’s letter of 5 June 2026 listed (“marksheets/grade sheets and corresponding credit data”). Any new connection built on that database then rests on a version its maker no longer fixes, unless extended security updates are bought. The letter makes no such link and says nothing about systems; whether any of this applies to your institution is for your own registrar and controller of examinations.

What One Application Holds Back

The application that pins the database is usually treated as a loose end. Our reading is that it holds back more than itself.

The database. A shared database cannot be half upgraded. While one application needs the old version, every application that uses it stays there too.

New connections. Our reading, not the UGC’s: any new connection built on the database, including one that sends out records of the kind the letter lists, rests on a version that receives no fixes from its maker unless extended security updates are bought. Which feeds of academic records an institution builds is for its registrar and controller of examinations.

The money. Extended security updates, the contractor who knows the old application and the old server are paid for each year, and none of it moves the institution forward.

The exception. The database stays on the list of exceptions, renewed in the same words.

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

Four Ways Out, Weighed

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

Option	When it fits	What it risks
Buy extended security updates and keep the old version	Updates are still offered, and a way off already has a date	They buy time, not an exit; some versions have none left. A purchase from the database’s maker or supplier, not something we sell
Upgrade anyway, and fix what breaks afterwards	The failing application is small, and someone can change it safely	Fixes are made under pressure, and a report that gives a different answer may not be noticed. The institution’s own team’s or database supplier’s work
Move everything at once: replace every application and the database in one programme	Funding for several years is assured	The cure is as large as possible, likely to be deferred, and everything waits meanwhile
Record what each application needs from the database, then rebuild the one application that keeps it on the old version, module by module, so the institution’s own team can upgrade	One application will not run on a newer version, and the rest are ready	It costs money before the database can move, and the database stays exactly as unsupported until the last module is accepted and the institution’s own team upgrades it

The honest costs. A rebuild costs more than one more year of waiting. Old and new parts run side by side for a time, kept running by your own team. More of the application may need the old version than anyone hoped. And when our part is done, the upgrade and the moving of the records are still for your people or a firm you choose.

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
Why the database stays on the old version	”One application failed the trial”	The application named, with what it needs and why	The map of the system as it stands
Parts of that application that need the old version	Unknown	Each named, with what it does, confirmed by the office that uses it	The specification and the risk register
Cost of staying against cost of rebuilding	Not compared	Set side by side, stage by stage	The cost comparison
That application, rebuilt	Marked “do not touch”	Rebuilt module by module beside the old one, each module accepted	The traceability matrix, module by module
Who does each part	”IT will upgrade when it can”	Named: your team or database supplier upgrades; your people move the records; we rebuild the application	Your plan, and our staged plan for our part

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 application that failed the trial. 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 application that keeps the database on the old version, and what the other applications need from the database. 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 pins the database, 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, handle student, fee or results records, or upload records to any platform; our confidentiality terms cover code. We give no advice on what the UGC’s letter, or any education, examination or data protection rule, requires. 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, or read COBOL, RPG, FoxPro or mainframe systems. 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.

What changes for the business:

Role	What they gain
Head of institution	The life of one old application stops setting the life of the database that every other system shares.
Registrar	The registry’s work moves one piece at a time, each compared with the old before it takes over, while everything else carries on as before.
Head of finance	Money goes to the one application that holds everything back, one accepted module at a time, and not to another year of standing still.
Head of IT	The application that needed the old version is rebuilt on current technology, so the team can upgrade the database in the ordinary way.
Head of information security	Each application that no longer needs the old version is one fewer reason for the exception, and there is a date for the rest.

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
Extended security updates for SQL Server 2012 ended on 8 July 2025; for SQL Server 2016 they are available to 17 July 2029.	Our part is narrower. We do not upgrade or patch databases or sell updates. We rebuild the institution’s own application that needs the old version, so its own team can upgrade.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We rebuild the application that pins the database, so your own team can upgrade it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →