PHP 7.4 lost security support in 2022, yet a quarter of PHP websites still run PHP 7. The reason is rarely laziness: upgrading an old application can break it. Here's what that means for your business, and why the climb never really ends.
When a version of PHP, the programming language behind a large share of business websites, reaches its end of life, it stops receiving security fixes, even for serious flaws in PHP itself. The obvious answer is "just upgrade". Yet many businesses don't.
According to php.net, PHP 7.4, the last version of PHP 7, stopped receiving security fixes on 28 November 2022. As of 23 October 2026, W3Techs reports that 26.9% of websites using PHP still run PHP 7, and 7.7% still run PHP 5.
In most cases, this isn't neglect. Moving an older application to PHP 8 can break it, sometimes visibly and sometimes silently, and the cost of dealing with that was never in the budget. And once the upgrade is done, the next one is already on the calendar. For business owners and IT managers, this is a risk worth understanding: not a single flaw, but a cycle that an ageing application may struggle to keep up with.
Why upgrading an old application isn't a simple switch
PHP 8.0 was released on 26 November 2020. It was a major version, and the PHP project used it to clean up behaviour that had caused problems for years. Its official migration guide lists dozens of "backward incompatible changes": changes that can make older code behave differently or stop working.
Three kinds of change cause most of the difficulty:
- Silent changes. Some comparisons the code makes behind the scenes now give different answers. Nothing crashes and no error appears. The application simply makes a different decision than it used to, for example about whether two values match. These are the hardest to spot, because everything looks fine until a customer notices something wrong.
- Things that used to limp along now stop. Many problems that PHP 7 reported as warnings and then carried on past are treated as errors in PHP 8. A page that used to load despite a hidden fault may now fail entirely.
- Removed features. Some older ways of writing code were removed outright. Applications written in the PHP 5 era often rely on several of them, and the oldest may depend on a database feature that was removed back in PHP 7.0.
These changes were good for PHP. Most fixed behaviour that caused real bugs, including security bugs, and modern PHP is a stricter, better language because of them. But for an old application that nobody has kept current, every one of them is work.
Then the treadmill keeps moving. The PHP project releases a new version roughly every year, and each gets around two years of active support followed by two more years of security fixes only. As of today, php.net lists PHP 8.2 with security fixes until 31 December 2026, PHP 8.3 until 31 December 2027, PHP 8.4 until 31 December 2028 and PHP 8.5 until 31 December 2029. PHP 8.1 reached end of life on 31 December 2025, and PHP 8.0 on 26 November 2023.
That schedule is predictable and well documented, which is a good thing. But it means a business that upgraded to PHP 8.1 in 2022 is already out of support, and one that moves to PHP 8.2 now has less than two months before it needs to move again.
What could go wrong for your business
Falling behind on upgrades is rarely a crisis on the day it happens. The risks build up quietly:
- No security fixes. Once a PHP version reaches end of life, newly discovered flaws in it are not fixed by the PHP project. Your application keeps running, but on a foundation that is no longer maintained.
- Hidden errors after a rushed upgrade. If an upgrade is forced through quickly, for example because a hosting provider retires an old version, silent behaviour changes can affect pricing, logins, invoicing or reporting before anyone notices.
- Unplanned downtime. Pages that used to work despite hidden faults may stop working on a newer version.
- Rising costs. The longer an upgrade is put off, the more changes pile up, and the more expensive and risky the eventual project becomes.
- Awkward questions. Customers, auditors and partners may ask whether your software is supported. "We run a version that stopped receiving fixes in 2022" is a difficult answer.
Could your website be next?
The risk here isn't a single headline flaw. It's what happens when a website runs on software that no longer gets fixes.
Attackers commonly use automated tools to scan large numbers of websites for known flaws in outdated software. They don't need to pick out your business. If your site is reachable and runs an old version, it may simply turn up in their results. Being small or low-profile doesn't take you off those lists.
A clean history isn't a guarantee either. An application that has run without incident on PHP 7 for years was protected, in part, by fixes it no longer receives. Past calm says little about what happens when the next flaw is found in an unsupported version, because the PHP project won't be fixing it.
That doesn't mean every site on an old version will be attacked. It means the risk grows each year a site stays on unsupported software, and the upgrade it needs gets harder at the same time.
Why legacy PHP applications deserve attention
The difficulty of upgrading has less to do with PHP than with the age and condition of the application:
- The application is only part of it. An older site depends on a framework, plugins and libraries, often at old versions. Each has to support the new PHP version, and abandoned ones never will.
- Few safety nets. Silent behaviour changes are only caught by automated tests, and many older applications have few or none.
- The gap compounds. Moving from PHP 7.4 to 8.0 means handling one set of changes. Moving from PHP 5.6 to a current version means handling every change across many releases at once, in code written by people who may have left years ago.
- Hosting adds friction. On shared hosting, the provider often sets the PHP version, so testing a newer one safely may not be possible on the current plan.
- It never ends. With each version supported for about four years, a business has to repeat this work every couple of years.
No modern platform escapes regular upgrades. Node.js also ships major versions with breaking changes, and its own release page says long-term support versions typically get critical fixes for 30 months in total, with an annual release cycle from Node.js 27. The question isn't whether you'll upgrade, but whether your application makes upgrading routine or a crisis.
What this means for your organisation
If your business depends on a PHP application that hasn't been upgraded for a while, it's worth finding out where it stands before a hosting change, an audit or a security incident forces the question:
- Which PHP version does it run, and when did or will its security support end?
- What else would have to change alongside it: the framework, plugins, libraries or hosting?
- Does the application have automated tests that would catch silent changes?
- What would this upgrade cost, and what would the next two cost?
The last question matters most. A single upgrade can look affordable. The full treadmill, repeated every couple of years on an ageing codebase, often doesn't. Understanding the real condition of your application is the starting point for deciding whether a careful upgrade, extended support or a planned migration makes most sense.
Recommended next step
Don't wait for an end-of-life date or a hosting provider's deadline to find out how far behind you are. Our free Legacy PHP assessment looks at the PHP version your application runs, its framework, dependencies and hosting, so you can see what an upgrade would really involve and what risks you carry in the meantime.
Then talk to our team about your options. Sometimes the right answer is a careful upgrade. Sometimes it's a planned move to a modern Node.js stack, where typed code, automated tests and routine dependency updates can make regular upgrades more manageable, depending on what the application does and where your business is heading. Node.js needs upgrading and securing too; what matters is choosing a path your team can keep current.
Free Legacy PHP Risk Assessment
Not sure how far behind you are? We'll review your PHP version, framework, dependencies and hosting, and tell you plainly what an upgrade would involve and what your options are, whether that's an upgrade, long-term support or a migration.
