When one old package freezes your entire stack

Here is a conversation that happens in businesses every week. The IT team is asked why the server has not been patched, or why it is still on an operating system that went out of support years ago. The answer comes back: we cannot update it, because the application will not run on anything newer. Push a little further and it gets worse — the application needs an old version of its runtime, the runtime needs an old operating system, the database needs the old operating system too, and the whole thing is welded together. Nothing can move, because everything is holding everything else in place.

This is the compound problem, and it is one of the most dangerous situations a business can be in without realising it. It is not one piece of old software. It is a chain of dependencies in which each link refuses to move until the others do — so none of them ever does.

Why this is a compound problem, not an upgrade

Most technology problems can be tackled one piece at a time. This one cannot, and that is precisely what makes it so persistent. You cannot update the operating system, because the application will break. You cannot update the application, because it depends on a runtime that the new operating system does not support. You cannot update the database, because it needs the old operating system and the application was built against its specific behaviour. Every individual fix is blocked by another part of the stack.

So the work gets deferred — not out of negligence, but because there is no small first step. The only honest move is to unlock the whole chain at once, and that looks like a project nobody has budgeted for. The result is a frozen stack: functional, business-critical, and quietly rotting from the inside as the security world moves on without it. It is the system nobody will touch, scaled up to the entire server.

How the chain forms

The lock is easiest to understand with a real example. A business runs a web application built years ago on PHP. The application needs PHP 5.6, or PHP 7.4 — versions that reached end of life in 2018 and 2022 respectively. A current Linux distribution ships only PHP 8, and the application’s code, and the third-party modules it relies on, do not run on PHP 8 without changes. So the operating system cannot be updated, because doing so would change the PHP version and break the site. The application pins the runtime; the runtime pins the operating system.

The same shape appears across every technology. An application built on the old .NET Framework needs Windows, and cannot move to modern .NET without being rebuilt. A data tool written in Python 2 — which reached end of life in 2020 — needs the old system libraries that newer operating systems have dropped. An application built on Java 8 needs that specific runtime. In each case, one old component dictates what the layer beneath it is allowed to be. Add the database, and the chain closes into a loop that cannot be broken from any single point.

The operating systems you are probably stuck on

The bottom of the stack is the operating system, and the common ones holding businesses in place are well past their support dates. Windows Server 2008 R2 went out of support in January 2020. Windows Server 2012 and 2012 R2 followed in October 2023, with paid Extended Security Updates only as a stopgap, themselves ending in October 2026. On the Linux side, CentOS 7 — extremely widely deployed — reached end of life in June 2024, with the project discontinued entirely. Even Windows 10 reached end of support in October 2025, stranding the desktops that line-of-business applications often depend on.

An operating system past its support date still runs. It simply stops receiving security patches. Every vulnerability discovered after that date stays open. For a server exposed to the internet, that is not a theoretical risk — it is an accumulating one, and at the point of CentOS 7’s end of life, surveys found close to half of organisations still running it.

The runtimes that pin everything above the OS

Between the operating system and your application sits the runtime — PHP, .NET, Python, Java, and the libraries they depend on. This layer is usually the thing doing the pinning, because it is version-specific in ways that break loudly. PHP 5.6 and 7.4 are gone. The old .NET Framework is frozen while modern .NET moves on. Python 2 is years past its end. Underneath them, shared security components like OpenSSL went out of support too — OpenSSL 1.0.2 ended in 2019 — and an application bound to an old runtime is usually bound to those ageing libraries as well.

This is where the unlock has to start, because the runtime is what makes the application portable or not. The specifics depend on what your stack is built on: if the anchor is an old language or framework, the path runs through the kind of move covered in moving off Python 2 or migrating from .NET Framework; if it is the platform itself, it looks more like the rebuild described in the Drupal 7 end-of-life problem. The common thread is that the old runtime is rarely fixable in place — it has to be moved, and moving it is what frees the layer below.

The database is usually the hardest link

Of all the links in the chain, the database is the one that most often turns out to be the keystone — and it deserves separate attention, because it is where businesses underestimate the difficulty most badly.

The version problem is the same as everywhere else. SQL Server 2008 R2 went out of support in 2019, SQL Server 2012 in 2022, and SQL Server 2014 in 2024 — yet a meaningful share of servers still run them. MySQL 5.7 reached end of life in October 2023, and even MySQL 8.0 reaches its end in 2026. An unsupported database stops receiving security fixes, and it bundles its own third-party libraries — OpenSSL, curl, zlib and others — each of which then stops being patched too. The database does not just carry its own risk; it carries a small unpatched ecosystem inside it.

But the database is harder than the other links for three reasons beyond its version. First, old database versions are frequently not supported on new operating systems, so the database and the OS pin each other directly. Second, applications are built against version-specific behaviour — the way a particular database sorts and compares text, the exact dialect of its query language, the connection drivers it uses — so moving the database forward can break the application even when nothing else changes. MySQL changing its default text handling between major versions is a classic example. Third, and most importantly, a database holds your data. You cannot simply replace it; the data has to be preserved, migrated and reconciled, with no loss and no corruption, often while the business keeps running.

That combination is why the database tends to be both the thing that locks the stack and the thing that must be planned first. In data-first terms, it is the foundation everything else is standing on, and the unlock is usually sequenced around it. Get the data and its model right, and the rest of the chain becomes movable. Treat the database as an afterthought, and the project stalls exactly where it matters most. The same root cause shows up when the wordpress plugin problem meets an ageing database underneath it.

The fallout

A frozen stack is not a tidy problem sitting quietly in a corner. The consequences spread across the business.

Security is the obvious one, and it compounds. You are not exposed to one unpatched vulnerability but to a growing list of them, across the operating system, the runtime, the database and every bundled library — all on a system that, if it is internet-facing, is reachable. A compromise on one frozen server is also a foothold into everything else it can reach.

Compliance is the one that turns a technical problem into a legal one. Running unsupported software makes it hard to claim you have appropriate technical measures in place — the standard GDPR expects. Payment-card rules require supported, patched systems. Sector regimes, from the EU’s operational-resilience expectations to CySEC’s requirements for regulated firms, increasingly ask directly about end-of-life technology. An auditor who finds an unsupported operating system and database underneath a business-critical system will not treat it as a footnote.

Cyber insurance has quietly made this worse. Insurers now ask whether you run unsupported software, and a frozen stack can raise your premium, narrow your cover, or give the insurer grounds to question a claim at the worst possible moment. The thing you were deferring to save money becomes the reason the policy does not pay out.

And then the practical erosion. Third-party software keeps dropping support for old operating systems regardless of whether you are paying for extended security updates, so you progressively lose the ability to install or integrate anything new. The pool of people who know the old stack shrinks. The system becomes more fragile and more frightening to touch. Extended Security Updates, where they exist, are a rising rent — they buy time, not a solution, and they cost more each year until migrating would have been cheaper all along.

Why patching around it does not work

Faced with the lock, businesses reach for partial measures: isolate the server, take it off the public internet, buy extended security updates, wrap it in extra monitoring. These have their place as temporary risk reduction, and sometimes they are the right holding action while a proper plan is built. But none of them resolves the underlying position. An isolated server still cannot be updated, still runs ageing software, and still has to connect to something to be useful. Extended updates still end. The stack is still frozen; you have simply made it slightly less dangerous while it stays that way.

Mistaking a holding action for a solution is how businesses spend money every year to remain in exactly the same place — which is a particular form of technical debt, paid as rent rather than addressed as principal.

How to break the lock

The chain looks immovable because it is viewed as one undifferentiated lump. It is not. Breaking it is a matter of seeing it clearly and unlocking it in the right order.

The first step is to map the chain: every layer of the stack, its version, its support status, and crucially what each layer forces on the one below it. That map almost always reveals an anchor — the one component whose age is dictating everything else. Sometimes it is a single application. Sometimes it is the database. Sometimes it is a third-party tool nobody thinks about. Until you know what the anchor is, every plan is guesswork.

From there it becomes a sequence of real decisions. For each anchor component: is it migrated to a current version, replaced with something else, or, where genuinely justified, deliberately isolated for a defined period while the rest moves? Because the database both locks the stack and holds the data, the unlock is usually planned around it first — establish where the data lives and what depends on it, then move the layers in an order that lets the stack come back up together rather than collapsing mid-migration.

This is also the moment infrastructure choices get made properly rather than by accident — the kind of decision discussed in moving off shared hosting — because the destination should fit where the business is going, not just unfreeze where it has been.

The work needs an independent view. The lock is exactly the kind of problem where each vendor sees only their own layer, and where the team living inside it has lost the perspective to see the chain whole. Someone whose job is the outcome — not the sale of any one component — maps it, finds the anchor, and sequences the unlock so the business is not paying twice or migrating in the wrong order.

If your team has told you the server cannot be updated because of what runs on it, you do not have a patching problem. You have a frozen stack, and the risk it carries grows every month it stays locked. We will map the chain, find the anchor, and work out the order in which it comes apart.

Start a Conversation

Related reading

• the rewrite hiding behind a name
• the end-of-life nobody scheduled time for
• the platform that became a new platform
• the “new version” that is a new product
• crossing the .NET divide
• the re-platform behind the “cloud move”
• the upgrade that is really a rebuild