About Half of PHP Websites Run a Version the PHP Project No Longer Fixes. The Reason Is Rarely Neglect.

A notice arrives from the company that hosts your shop. From the first of next month, its servers will no longer offer the version of PHP your shop runs on.

Your developer tries the newer version on a copy. The home page loads. The checkout shows a blank screen. That is fixed in a day. Then you ask the real question. Is that everything? Nobody knows.

What We Found

For this article we went through the public record on websites left on old versions of PHP, the language many online shops are written in, and of MySQL, the database many keep their orders in: published end dates, shares of websites on each version, the US government’s list of flaws known to be exploited, and one survey of PHP developers, from 2018 to 2026. Every figure is about websites or developers in general, not shops alone, and we name no retailer.

Five findings stand out.

The end dates are published, and they keep arriving. PHP version 5.6 lost its security fixes on 31 December 2018, version 7.4 on 28 November 2022, version 8.0 on 26 November 2023 and version 8.1 on 31 December 2025. MySQL 5.7, the last of its 5.x line, reached the end of its support on 31 October 2023. Nothing stops working on the day. The fixes stop coming.

About half of all PHP websites are past those dates. By our own sum from the published shares of each PHP version, read on 12 October 2026, about half of all websites written in PHP run a version that no longer gets security fixes.

Sites on the most common website software are no exception. Among websites on the most widely used website software, which many small shops run with a shop add-on, more than a third run a version of PHP that no longer gets security fixes, and about one in six run MySQL 5.x, an out-of-support database line. Both come from that software’s own live usage feeds, read on 12 October 2026.

The language itself is on the list of exploited flaws. Three flaws in PHP itself are on the US government’s list of flaws known to be exploited, and two are marked there as used in ransomware. The most recent, in PHP on Windows in CGI mode, lets an attacker run commands and was added on 12 June 2024. The other two date from 2012 and 2019.

Much old PHP code has nothing around it to check a change. In one survey of more than a thousand developers whose main language is PHP, about a third said they still write no tests at all. A test is a small program that puts a known input in and checks the answer.

The record does not explain why sites stay. Our reading is that they rarely stay out of neglect. They stay because nobody has written down where the shop’s code depends on the old versions, so every upgrade is a gamble.

What Waits While Nobody Knows What Depends on What

An old language version is usually discussed as a security problem. Our reading is that it also holds the shop still.

The first cost is the deadline with no decision. A notice, a scan or an audit asks for an upgrade, nobody can say what it would take, and the old version is kept a little longer again.

The second cost is the failed attempt. The visible errors are fixed on a copy and the live shop is upgraded on a quiet night. Then a discount is rounded differently or an export stops, with no error shown. The shop goes back, and the upgrade is marked “too risky”.

The third cost is that every attempt makes the next harder to approve. After two bad nights, the upgrade is something the firm does not do.

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

Four Ways Forward, Weighed

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

Option	When it fits	What it risks
Upgrade in place, by your own team or agency	The code is recent, little changed, and has tests around it	Without tests or a list, silent changes are found later, by customers or the accounts team
Pay the hosting company to keep the old version a while longer	An upgrade already has a firm date	The PHP project issues no more fixes for the old version; any fixes depend on the hosting company. It buys time and nothing else
Rebuild the whole shop at once	Most of the shop no longer fits the business anyway	It pays to rewrite code that would have upgraded without trouble, under one deadline
Write down the dependencies first, then rebuild only the parts that block an upgrade, module by module	The shop is old, much changed, and earlier upgrades failed	It costs money before anything is upgraded, and may show more blocking parts than hoped

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own shop, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
Places where the code depends on the old language version	Found by trying, one failure at a time	Every one written down, part by part	The specification
Logic held inside the database	Unknown, or known to one person	Written down in plain words	The specification
Outside packages	Installed, never reviewed	Each listed, with whether its maker still maintains it	The list beside the specification
What each dependency touches	Discovered on the night of an upgrade	Linked to the jobs it affects: checkout, export, invoices	The risk register
A verdict on each part	One verdict for the whole shop: too risky	Each part marked: upgrades as it is, needs a small change, or blocks and must be rebuilt	The staged plan

The starting points above are what the public record suggests and 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 a retailer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the shop, the versions under it and the upgrade that keeps being rolled back. 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 shop’s own code and the database beneath 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. 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. Here that means the parts that block an upgrade, rebuilt on technology that is still supported. 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.

We do not upgrade in place: the upgrade of the language version and the database is done by your own team or agency. We patch nothing: we do not apply security fixes or fix flaws while the shop waits. We do not host the shop or run its servers, and we do not secure, scan or monitor it; the assessment leaves it exactly as exposed as it was the day before. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP; PHP is a language we read, not one we build in. We say nothing about what card-payment or data protection rules require, and we have no published case of this work for a retailer.

What changes for the business:

Role	What they gain
CEO	A notice that came with no way to act becomes a plan with a known first step.
CTO or CIO	A list of every place the code leans on the old language version or the old database. An upgrade stops being a leap in the dark.
CFO	The work has a size, so it can be budgeted against the cost of staying and is no longer deferred as “too risky”.
CISO	The out-of-support layers are named, with what stands on each, so the exposure can be ranked and reported.
COO	Operations knows in advance which daily jobs an upgrade touches: the order export, the stock update, the invoices.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
About half of all PHP websites run a version that no longer gets security fixes.	Our part is narrower than this. We do not upgrade the language or apply fixes. We write down where a shop’s code depends on the old versions, so its own team or agency can plan the upgrade.
Three flaws in PHP itself are on the US government’s list of exploited flaws, two marked as used in ransomware.	Our part is narrower than this. We do not patch, secure or monitor a shop, and we promise no protection from attack.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start with what the shop’s code needs from the old versions, because that is what turns an upgrade from a gamble into a list of jobs.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →