End of support under the shop: OS and database

When people talk about shop updates, they usually mean three things: the core of the shop system, the extensions and the theme. Underneath lies a second chain that comes up less often in day-to-day maintenance, even though everything stands on it. At the bottom is the Linux distribution with kernel, system libraries and package management. On top of it runs the database server, usually MariaDB or MySQL, which holds orders, customer accounts, products and sessions. Next to it sits the PHP runtime that generates every page, and the web server that accepts requests and hands them to PHP. Each of these layers has its own vendor, its own release rhythm and its own end date.

The tricky part of this chain is that its deadlines do not show up in the shop. The back end of a shop system displays its own version and reports available updates for the core and extensions. Whether the distribution underneath is still maintained is something it never learns. The database server answers queries after its end date just as quickly as before. The only difference is that no fix is published for newly discovered vulnerabilities - and that only becomes apparent once such a vulnerability is exploited.

How far "it runs" and "it is maintained" can drift apart is shown by the WordPress requirements page. It recommends PHP 8.3 (WordPress.org) or greater and MariaDB 10.11 or MySQL 8.0 (WordPress.org) or greater. The same page also states that WordPress still runs in legacy environments with PHP 7.4 and MySQL 5.5.5 (WordPress.org) - with the explicit note that these versions have reached their official end of life and may expose the site to security vulnerabilities. A shop on such a foundation works. It is simply no longer maintained. For WordPress maintenance that covers the server, this means the check does not stop at the core and plugins.

Debian 12 completed its regular maintenance on 11 July 2026 (Debian) and has since been in long-term support, which ends on 30 June 2028 (Debian). Debian 13 was released on 9 August 2025 (Debian), and its LTS phase runs until 30 June 2030 (Debian). Anyone upgrading from Debian 11 in autumn 2026 therefore has two targets with very different remaining lifetimes: the jump to Debian 12 buys just under two years, the jump to Debian 13 just under four. The effort differs less than the lifetime, because both targets require a rehearsal with a new PHP version.

Servers on Ubuntu follow the same logic with a different calendar. Ubuntu 22.04 LTS receives standard security maintenance until May 2027 (Canonical), expanded security maintenance runs until May 2032 (Canonical) and is delivered through the Ubuntu Pro (Canonical) subscription. Ubuntu 24.04 LTS is in standard support until May 2029 (Canonical), Ubuntu 26.04 LTS was released in April 2026 and is maintained until May 2031 (Canonical). Expanded maintenance is a separate component that has to be booked and activated on every server. A server on which it is planned but not set up receives no security fixes from standard maintenance after May 2027.

For MariaDB, the next major deadline concerns 10.11: community maintenance ends on 16 February 2028 (MariaDB Foundation). This is the version Debian 12 ships and the one WordPress names as its minimum recommendation. It therefore affects every server running Debian 12 with the database from the distribution.

After version 11.4, the MariaDB Foundation changed its rule. Up to and including 11.4, binaries were published for five years (MariaDB Foundation). For later long-term releases, it provides community binaries for only three years (MariaDB Foundation) after general availability and then delivers fixes for critical and security issues for two additional years (MariaDB Foundation) as source code. The consequence is in the same table: MariaDB 11.8 is newer than 11.4 but receives community binaries only until 4 June 2028 (MariaDB Foundation), while 11.4 gets them until 29 May 2029 (MariaDB Foundation). The youngest version in the table, 12.3, was released in May 2026 and is maintained as a community release until 12 June 2029 (MariaDB Foundation) - barely longer than 11.4.

The inventory becomes a calendar. Each row holds a component, its version, the end date with its source and the date on which preparation has to start. That second date is the one that really matters. A version jump underneath the shop needs a rehearsal, an approved date, a maintenance window outside peak trading hours and room for a second attempt if the first one is aborted. Anyone who only starts on the end date is already working in an unmaintained state.

How much lead time is needed depends on the scope. A database jump on an otherwise unchanged server can usually be completed in one window. A jump of the operating system with a new PHP version and changed web server defaults usually needs several rehearsals. Shops with seasonal business also have a change freeze to consider: if an end date falls in late autumn, the upgrade belongs before the Christmas season, not after it.

The calendar is only as good as its upkeep. Vendor deadlines can be moved or clarified, and with its releases after 11.4 the MariaDB Foundation has shown that even the rule by which deadlines are set can change. Every row therefore needs checking against its source regularly, at least once a quarter. Under security updates as an ongoing service, we monitor the components in use down to the operating system, web server and PHP version. Such a calendar can be built into that work, so that lead times are reported and upgrades scheduled before maintenance ends.

Each of these jumps is made on a copy first. The copy has to match the production server in the points that matter: the same distribution, the same database version, the same PHP modules, a current data set. A staging environment that nobody has touched for a year tests the jump from a state that no longer exists in production. How such an environment is set up and kept current is described in our article on the staging environment for safe updates.

The rehearsal follows a script that is later repeated step by step in production. It includes the commands in their order, the duration of each step and the checks afterwards: home page, category, product, search, basket, checkout with a test payment, customer account, back end, export to the ERP system and scheduled tasks. The total duration is measured too, because it determines the length of the maintenance window without lost revenue.

A special case is the rebuild. Instead of raising the existing server version by version, a new server is set up at the target state, the shop is transferred to it and the old server is left standing as the way back until the new one has proven itself in operation. That takes more preparation and a data move, but the starting state stays fully intact. For jumps across two distribution versions, it is often the calmer route. What happens if an update fails despite the rehearsal is answered in our FAQ on what happens if an update fails.

The bill for a postponed upgrade looks cheap at first: no rehearsal, no maintenance window, no project time. It tips as soon as a vulnerability becomes known in a component for which no fix is published any more. Exploitation of vulnerabilities is now the most common initial access vector, accounting for 31% (Verizon) of analysed incidents with an identified initial access vector, ahead of credential abuse. And even where fixes exist, full resolution of critical vulnerabilities takes a median of 43 days (Verizon).

The other side is faster. Between a vulnerability being added to the catalogue of actively exploited vulnerabilities and its mass exploitation lies a median of five days (Verizon, 2025 report). A server without maintenance no longer takes part in this race at all: no fix is coming for it, however long one waits. Ongoing shop monitoring reports outages and anomalies, but it does not replace the calendar - an end date triggers no alarm.

On top of that comes an effect that only appears when catching up. The longer a server stands still, the bigger the jump becomes: a move from Debian 11 to 12 turns into one across two versions, a PHP change by one minor version turns into one across several. Every extra step increases the number of places where extensions, configuration or database queries can break. The postponed upgrade does not get cheaper but more expensive - and it then often falls into a period nobody planned for it.