Out of Extended Support

1. At a Glance

Issue study · From the public record. The university described here is a very large university abroad, and the case is an older one, from 2021; it concerns a packaged student record product, which is not IOanyT’s kind of work. We found no public record of an Indian institution, or of one of our readers’ size, on this issue. The case is reported as the public record gives it, without judgement on the university or anyone in it.

Organisation type	A very large UK university whose core system was reported to run on a database version out of extended support, set beside a college, university or school group whose own applications keep a database on an unsupported version
Size band	The case: a very large university. Our reader: a small or mid-size college or university, a group of colleges or schools, a coaching institute or a training body
Region	The case: UK. The reader: anywhere
The decision at stake	What to do about a database its maker no longer supports: buy extended security updates, upgrade and fix what breaks, replace everything in one programme, or find what each application needs and rebuild the one that keeps the database on the old version
The public outcome	A programme worth tens of millions of pounds, begun in the mid-2010s, to bring in a packaged student record product was scaled back after the university said the product could not be joined to its existing system as planned. The trade press reported that system’s database version as out of its maker’s extended support since the end of 2020. The university did not say the database was the reason
Why it matters to a mid-size institution	If an old system at the centre of a very large university can decide what is possible around it, a smaller institution whose applications share one old database faces the same question with fewer people

2. The Business Problem, in the Buyer’s Words

“Our main database went out of support some years ago. Everyone agrees it should be upgraded, and every year it is in the plan. We tried once, on a test machine: three of the four applications came up, and the examination application printed blank reports. Nobody here can change that application; the firm that wrote it has closed. So the database stays, and with it the exception I sign each year. I cannot say what an upgrade would break, what it would cost, or how we would know afterwards that everything still comes out the same.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The institution is caught between a database it cannot keep supported and applications it cannot move, because nobody has written down what each application needs from the old version, or what each one should produce.

3. What We Found

Method. We went through the public record on databases kept past their makers’ support dates: trade press reporting in 2021 on one large UK university, the support dates of two widely used databases, one monitoring service’s spring 2026 report, one cross-sector survey of about five hundred IT professionals in the US (2025), one developer’s account and a developer survey (2025), and the University Grants Commission’s letter of 5 June 2026. The sector research holds no Indian institution and none of our readers’ size on this issue.

One older case, at a very large university. One large UK university began a programme in the mid-2010s to bring in a packaged student record product, a project worth tens of millions of pounds. In 2021 the trade press reported, from information passed to it, that the university’s existing central information system ran on a database version that had been out of its maker’s premium support for years and out of extended support since the end of 2020. A university spokesperson said the new student record product could not be joined to the existing central system as first planned, and the project was scaled back. The trade press asked whether the out-of-support database was behind the problem; no answer was reported, and we do not say it was. A packaged product is not IOanyT’s kind of work; we use the case only to show that an old system at the centre can decide what is possible around it.

The dates. Support for widely used databases ends on published dates. For SQL Server 2012, 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, version 5.7 reached the end of its support on 31 October 2023 and version 8.0 on 30 April 2026. These dates are cross-sector.

Old versions stay in use. Among the customers of one database monitoring service in spring 2026, SQL Server 2014 and older, together with SQL Server 2016, made up about one in seven: versions now out of support. The sample is one firm’s own customers, and the report gives no geography.

Why organisations hold back. In one survey of about five hundred IT professionals in the US, not about education and from a firm that sells related services, most organisations said they still use legacy systems. Half said the biggest reason they had not upgraded is that the current system still works; more than four in ten named budget limits, and more than a third each fear of disrupting operations and data migration concerns. Among the top challenges of those systems, about four in ten named security weaknesses, a similar share high maintenance or support costs, and about a third a lack of vendor support or updates.

How changes are checked. One developer wrote that nothing is more frightening than changing a critical old system that has no tests. In a tool maker’s survey of more than a thousand developers whose main language is PHP, about a third said they still write no tests at all.

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”. 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 of why the database stays. These four are our reasoning from the record above. None is a finding of any source, and none is said to explain the university’s case.

1. Nobody has a list of what stands on the database. Applications, the rules kept inside the database and the jobs that run at night were written for the old version, and nobody has written down what each needs from it.
2. One application will not run on a newer version. While it needs the old one, every application that shares the database stays with it.
3. An upgrade cannot be checked. Nothing records what each application should produce, so afterwards nobody can say whether anything changed.
4. The cure is offered in one size. Leave it alone, or replace everything.

Our reading, and only that: the 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”). The link is ours; the letter says nothing about institutions’ systems. Whether it applies to an institution is for its own registrar and controller of examinations.

4. The Options an Institution in This Position Had

Option	When it fits	What it risks	Our view
Buy extended security updates and keep the old version	Updates are still offered, and a way off already has a date	Buys time, not an exit; some versions have none left, and the application that pins the database is no nearer leaving	Right only as a bridge to a dated exit; a purchase from the maker or supplier, not ours to sell
Upgrade anyway, and fix what breaks afterwards	The failing application is small and someone can change it safely	Fixes under pressure; a report that runs but gives a different answer may not be noticed	Right where the applications are few and well understood; the institution’s own team’s or database supplier’s work
Replace every application and the database in one programme, or bring in a packaged product	Funding for several years is assured, and a packaged product fits the institution’s way of working	The cure is as large as possible, likely to be deferred, and everything waits meanwhile	Right for some institutions; a packaged product is not our kind of work
Record what each application needs from the database, then rebuild the one application that keeps it on the old version, module by module, against a specification and a benchmark, so the institution’s own team can upgrade and check the upgrade	One application will not run on a newer version, and the rest are ready	Costs money before the database can move; the database stays exactly as unsupported until the institution’s own team upgrades it	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the applications an institution built or had built (admissions and enrolment, fee collection and receipts, examination and results, registers and certificates): read each application that uses the database, and write down what it needs from the old version, including the rules and jobs kept inside the database, with a verdict for each: moves as it is, needs a small change, or has to be rebuilt. Where one application keeps the database on the old version, rebuild it one module at a time onto current technology, beside the old application, with a traceability matrix to show each module does what the old one did. Agree a written specification and a benchmark before the upgrade, so the institution’s own team, or a firm it chooses, can carry out the upgrade and check the results before and after against them, with automatic tests if it decides to write them. The upgrade and the moving of records are the institution’s own team’s or its database supplier’s. How each stage is bought is the institution’s own decision under its own rules.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the institution’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Applications with a written verdict	None, or a verdict from memory	Every application that uses the database has a verdict: moves as it is, needs a small change, or has to be rebuilt	The map of the system as it stands and the risk register
Rules kept inside the database	On nobody’s list	Each listed 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
Reports and outputs before and after the upgrade	”It seems fine”	The institution’s own team compares the agreed outputs before and after, against the specification	The specification and the institution’s own check record
The exception for the unsupported version	Renewed each year, with no end	Tied to the application that keeps the old version, with a planned end	The risk register and the staged plan
Who does each part	”IT will upgrade when it can”	Named: the institution’s team or database supplier upgrades and checks; its people move the records; IOanyT rebuilds the pinning application	The institution’s plan, and IOanyT’s staged plan for its part

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the database, the applications that use it and what has been tried. 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 study 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.
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. 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.
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.

8. What the Client Would Own

• The map and the specification: each application that uses the database, what it does and what it needs from the database version, in writing. The institution can show it to any supplier, subject to its own contract with its present supplier, and its own team can check an upgrade against it.
• The risk register: a verdict for each application, and the application that keeps the database on the old version, named.
• The benchmark: the results to be compared before and after, agreed in advance, and each measure filled in as the work goes on.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the institution’s. No runtime or platform fee.

The upgrade, the checks before and after, any automatic tests and the moving of records belong to the institution’s own team, its database supplier or a firm it chooses.

9. What This Approach Does Not Cover

• IOanyT does not upgrade, patch or migrate a database, or supply extended security updates. The research’s suggested answer to this issue was a database upgrade or migration; the institution’s own team or database supplier does that.
• IOanyT does not move, convert, clean or check records, and does not handle student, fee or results records, or supply example cases taken from them. Its confidentiality terms cover code.
• IOanyT does not carry out a security review, and does not keep the old application running or secure while it is rebuilt. Until the institution’s own team upgrades it, the database is exactly as unsupported as before. IOanyT does not claim that its work prevents an attack.
• IOanyT does not write or run tests or checks for an upgrade; they are the institution’s own team’s option, or a firm it chooses. A case nobody thought of can still slip through.
• IOanyT gives no view on whether any result is right, and does not upload records to any platform.
• IOanyT does not implement, configure or upgrade a packaged student, finance or learning product, which is what the public case involved, and does not read COBOL, RPG, FoxPro or mainframe systems. The old technologies it reads are VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, and .NET Framework and classic ASP.
• IOanyT offers no compliance, audit or legal service, and says nothing about what the UGC’s letter or any education, examination or data protection rule requires of an institution.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any government, university or board, or that it meets the conditions of any tender. It gives no advice on budget or procurement rules.
• This study does not say IOanyT would have prevented or changed anything described in it. IOanyT has no published case of this work for an education body.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
The Register, 2021	One large UK university: the programme, the reported support dates, what the university said, the scaled-back project
Microsoft lifecycle, SQL Server 2012; SQL Server 2016; endoflife.date/mysql	Support dates
A monitoring service’s population report, 2026	The share of one service’s customers on old versions
A vendor’s survey, 2025	Why organisations keep old systems
A developer’s post, 2025; a tool maker’s developer survey, 2025	Changes without tests; tests among developers
UGC public notice and letter, 5 June 2026	The Examination Year 2025 upload window

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what stands on your database and rebuild the application that keeps it on the old version; the upgrade, and the checking of it, stay with your own team.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →