“It works, why touch it?” is the sentence that keeps thousands of sites and management tools alive on long-abandoned PHP versions. It’s an understandable sentence: upgrading costs time, the site responds, customers don’t complain. The problem is that the risk of an end-of-life PHP is invisible: it doesn’t slow the page down, it doesn’t show errors, it doesn’t send warnings. Simply, from a certain day on, nobody closes the flaws that get discovered.

And flaws get discovered anyway. Vulnerability research doesn’t stop when support ends: only the distribution of fixes stops. Everything that surfaces after that date stays open forever, on every server running that version.

What end of support actually means

Every PHP version goes through two phases. In the first, active support, it receives fixes of every kind: bugs, performance, security. In the second, security support, it only receives patches for vulnerabilities. When that ends too, the version is end of life: the code keeps running, but it is officially abandoned.

The dates are public and non-negotiable: the entire PHP 7 family has been end of life since late 2022, PHP 8.0 since late 2023 and PHP 8.1 since late 2025. In the summer of 2026 only PHP 8.2 (which closes at the end of the year), 8.3, 8.4 and 8.5 receive fixes. Anyone still on PHP 7.4 is running software that hasn’t seen a security patch in almost four years. The same mechanism applies one floor down, to the server hosting everything: we cover it when discussing Proxmox VE 8 at end of life.

The concrete risks, beyond theory

The first risk is obvious: vulnerabilities with no remedy. A site exposed on the internet is probed continuously by automated scanners looking precisely for old installations, because they are the easiest to break into. You don’t need to be an interesting target: being reachable is enough.

The second is subtler: the ecosystem moves on. Libraries, frameworks and platforms drop old PHP versions long before their users do: new releases of WordPress, PrestaShop, Laravel and Composer dependencies require recent versions. Standing still on an old PHP means standing still on everything, payment modules and security plugins included.

The third concerns anyone handling personal data: under the GDPR security measures must be “appropriate to the state of the art”, and a component abandoned by its maker is hard to defend as appropriate, as we discussed in GDPR on the infrastructure side. In case of a breach, the PHP version ends up in the report.

Upgrading pays off even when it isn’t forced

Upgrading PHP is not just removing a risk: it’s one of the few changes that improves performance without touching a line of code. Every recent release runs the same program faster than the previous one, and on a dynamic site the difference is measurable, as our guide on speeding up a PrestaShop store shows. Less CPU time per request also means smaller servers for the same traffic: the upgrade often pays for itself on the hosting bill.

How to migrate without drama

The migration feared “because everything will break” is handled like any serious intervention: with a method, not with courage.

1. Inventory: which applications run, on which version, with which extensions and dependencies. Without this map every estimate is a bet.
2. Test on a separate environment: replicate the site on a staging environment with the target version and watch logs and deprecation warnings. Static analysis tools flag incompatible code in advance.
3. Gradual upgrades: better to climb one version at a time than to jump from 7.4 to 8.5 in one leap, fixing incompatibilities in small steps.
4. Safety net: before touching production, a verified backup and a rollback plan. If something goes wrong, you go back in minutes, not in all-nighters.

For an e-commerce store or a custom management tool the bulk of the work is almost never PHP itself, but the modules and custom code written years ago: that’s where you want people who do these migrations for a living.

In summary

An end-of-life PHP version doesn’t stop working: it stops being defended. New flaws stay open forever, the ecosystem of libraries and platforms drifts away, and GDPR compliance becomes hard to sustain. The migration, tackled with an inventory, a staging environment, gradual steps and backups, is an ordinary project rather than a leap into the void; in return you get a site that is safer, faster and free again to update everything else.

Sources

• Supported Versions - php.net
• PHP - endoflife.date
• OPcache - official PHP manual