The database risk hiding under everything

Of all the technology a business runs, the database is the one most likely to be quietly out of date — and the one where that matters most. It holds your customers, your orders, your financial records, the actual information the business runs on. And it is precisely because it holds the data that nobody wants to touch it. The application can be rebuilt, the server can be replaced, but the database has the crown jewels inside it, so it gets left alone long after its version has stopped being supported.

That instinct is understandable and dangerous. An unsupported database is a security and compliance exposure sitting under everything else, and it is frequently the component that locks the rest of your systems in place. Here is what has actually gone end of life, why databases are uniquely hard to move, and how to do it safely.

The versions that are already unsupported

For Microsoft SQL Server, the line has moved past several widely used versions. SQL Server 2008 and 2008 R2 went out of support in 2019. SQL Server 2012 followed in July 2022, and SQL Server 2014 in July 2024. The next dates are close: SQL Server 2016 reaches end of support in July 2026 and SQL Server 2017 in October 2027. Even SQL Server 2019 has passed the end of its mainstream phase, with only security patches continuing until 2030. Surveys of live estates still find significant numbers of servers on 2014 and 2017, quietly past or approaching the edge.

For MySQL, the most consequential date is recent: MySQL 5.7 reached end of life in October 2023, so any system still on it has been without security patches for some time. MySQL 5.6 went earlier, in 2021. And the one catching teams out now is MySQL 8.0, which reaches its end in 2026 — many businesses upgraded to 8.0 believing they had solved the problem for a decade, and are closer to the next deadline than they realise. The current long-term release to aim for is MySQL 8.4.

An unsupported database keeps answering queries. It also stops receiving security fixes, and it quietly carries a further problem: databases bundle their own third-party libraries — components such as OpenSSL — and once the database version is unsupported, those bundled pieces stop being patched too. The database does not just carry its own risk; it carries a small unpatched ecosystem inside it.

Why databases are harder to move than anything else

Upgrading a database is not like upgrading an application, and underestimating the difference is how these projects go wrong. Three things make it uniquely hard.

First, the data itself. You cannot simply install the new version over the top and move on. The data has to be migrated — preserved, validated, and reconciled — with no loss and no corruption, often while the business continues to operate against it. The value locked in the database is exactly what makes the move careful and slow.

Second, applications are built against version-specific behaviour. The precise way a database sorts and compares text, the exact dialect of its query language, the way it handles dates and characters — applications quietly depend on all of it. Move the database forward and the application can break even though nothing in the application changed. MySQL altering its default text handling between major versions is a well-known example: a migration that looks routine surfaces subtle failures across the application that relied on the old behaviour. The connection drivers the application uses are version-specific too, and they pin the runtime around them.

Third, the database and the operating system pin each other. Old database versions are frequently not supported on current operating systems, and current database versions will not run on the old ones. So an out-of-support SQL Server can be the very thing keeping a business on an out-of-support Windows Server — the pairing covered in Windows end of support — and neither can move without the other. The database is, more often than not, the keystone of the whole frozen stack described in the compound problem.

The fallout

Because the database holds the most sensitive information in the business, the consequences of leaving it unsupported are the most severe of any layer.

Security is acute: a database is the highest-value target in any breach, and an unpatched one — with its unpatched bundled libraries — is where the most damaging compromises happen. This is the system whose contents you would least want exposed, running on software that no longer gets fixed.

Compliance is direct and unavoidable. Data-protection law expects appropriate technical measures around personal data, and running it on unsupported database software is hard to defend. Payment-card rules require supported, patched systems. There is also a data-sovereignty dimension that regulated firms increasingly face: knowing where your data lives and being able to evidence how it is protected — questions an ageing, poorly mapped database struggles to answer.

Cyber insurance applies here too. Insurers ask about unsupported software, and an unsupported database holding customer records is exactly the kind of exposure that affects whether a claim is honoured.

Why “it still queries fine” is the trap

A database gives almost no warning. It performs identically the day after its support ends as the day before. There is no slowdown, no error, nothing visible to prompt action. That smooth surface is precisely why databases get left longest — and why the move, when it is finally forced, tends to be an emergency rather than a plan. Paying to leave it as-is, year after year, is a quiet form of technical debt accruing on the most important asset you have.

How to move a database safely

The right approach is data-first, which is the only sensible way to treat the thing the whole business depends on. It runs in a clear order.

Start by understanding the data and what depends on it: what the database holds, which applications read and write to it, what version-specific behaviour they rely on, and which connection drivers are in play. This is the step that surfaces the surprises — the application quirk, the reporting tool, the integration nobody documented. It is also the moment to confirm the data is consistent in the first place, because migrating data that already disagrees with itself just carries the problem across, as set out in why your reports show different numbers.

Then decide the destination. Often it is simply a current, supported version of the same database. Sometimes the forced move is the moment to reconsider — to move from an unsupported MySQL to a maintained alternative, or to a managed, cloud-hosted database that takes the patching burden off the business entirely. That is a genuine decision, not a formality, and it should be made with a clear view of cost and fit.

Finally, migrate with the data treated as sacred: a tested process, validated against the original, with a way back if something is wrong, and sequenced so the database, the application and the operating system come up together rather than one breaking the others. Because the database so often pins the rest of the stack, getting it right is usually what unlocks everything else.

If your business runs on an old SQL Server or MySQL — or you are on MySQL 8.0 or SQL Server 2016 with the next deadline approaching — the database deserves a plan before it becomes a crisis. We will map the data, the dependencies, and the safest route forward.

Start a Conversation