PHP isn't a legacy language — your version might be

“We should probably get off PHP” is one of the more expensive sentences a business owner can say, and it is almost always a misdiagnosis of something real.

The real thing is usually this: the application was written against PHP 7.2, nobody has touched it since, and the version it runs on stopped receiving security fixes several years ago. That is a maintenance problem with a number attached to it. Rewriting the whole application in something more fashionable is a way of solving that problem at roughly twenty times the price.

Worth separating the two, because they routinely get quoted as the same job.

The language did not stand still

The PHP people picture when they say “legacy” is PHP 5. Loose typing, no real error handling, mysql_query() scattered through the templates, and a reputation earned honestly over about a decade.

That version has been dead since the end of 2018. What replaced it has proper type declarations, enums, readonly properties, exceptions that actually behave like exceptions, and — as of 8.4 — property hooks. It is also considerably faster than the PHP most people are remembering; a good deal of the “PHP is slow” folklore predates work that landed in 7.0 and again in 8.0.

Meanwhile it is still what most of the web runs on. WordPress, Drupal, Laravel, Magento, and an enormous number of custom business applications that quietly do their job every day. Releases arrive on a published schedule. This is not an abandoned language.

So “our PHP is legacy” is not really a claim about PHP. When it’s true, it’s a claim about one specific installation — and unlike most things in this conversation, that one is checkable in about a minute.

Where the versions actually stand

Each PHP branch gets two years of active support, then two more years of security-only fixes, then nothing at all. The dates are published years ahead, which means none of this is ever a surprise. It is only ever a thing nobody looked at.

As of this writing:

• PHP 8.5 — released 20 November 2025. Current, actively supported through 31 December 2027.
• PHP 8.4 — actively supported through 31 December 2026, security fixes through 31 December 2028.
• PHP 8.3 — security fixes only, through 31 December 2027.
• PHP 8.2 — security fixes only, and they stop on 31 December 2026.
• PHP 8.1 — end of life on 31 December 2025. Already unsupported.
• PHP 8.0 — unsupported since 26 November 2023.
• PHP 7.4 — unsupported since 28 November 2022.

Two things are worth pulling out of that list.

PHP 8.1 is the one catching people right now. It was the default on a lot of shared hosting for a long stretch, it still feels modern, and it has received no fixes of any kind since the last day of 2025.

PHP 8.2 is the deadline that’s actually on the calendar. If your site runs 8.2 — an extremely common place to be — security support ends on 31 December 2026. That is not an emergency today. It is a thing to schedule now instead of discovering in January.

What “unsupported” actually costs

It is easy to shrug this off, because an unsupported PHP install doesn’t stop working. It keeps serving pages exactly as it did the day support ended. Nothing visibly changes, which is the entire trap — it’s the same failure shape as a contact form that silently swallows leads.

What changes is that newly discovered vulnerabilities in that version stop being fixed, and they stay public. A disclosed flaw in a dead branch is permanent, indexed documentation of how to attack every site still running it.

It surfaces in less dramatic ways too:

• Compliance. If you take card payments, running unsupported software is a straightforward PCI DSS failure. Cyber insurance questionnaires have started asking the same question in plainer words.
• Everything downstream stops upgrading with you. Current versions of WordPress plugins, Laravel, Composer packages, and payment SDKs drop old PHP. Eventually you can’t apply a security update to your CMS, because that update requires a PHP version you’re not on.
• The gap compounds. Moving up one branch is routine work. Moving up four at once, after the whole ecosystem around you has moved on, is a project.

The upgrade is usually smaller than the rewrite

Here’s the part that surprises people who have been quoted for both.

Most PHP applications that haven’t been touched in years upgrade with far less work than expected. The genuinely painful breaking changes were concentrated in the 5.x to 7.x transition, which most surviving sites are already past. What’s left is usually a short and boring list:

• An abandoned third-party library nobody has replaced.
• Code relying on behavior PHP has since made stricter — implicit type juggling, ${var} string interpolation, passing null where a string was expected.
• One old payment or shipping integration written against an API that no longer exists.

That list is finite and discoverable. You find it by running the codebase against the target version and reading the errors, not by guessing.

Compare it to a rewrite, where you have to re-specify every business rule the original developer encoded over eight years, most of which nobody ever wrote down. A rewrite isn’t just more expensive. It’s the option with genuinely unknown scope.

There are honest reasons to replace a PHP application: the code is unreadable and its author is unreachable, the architecture can’t do something the business now needs, or six different people have patched it and every change breaks two other things. Those are real. “It’s PHP” is not one of them.

How to find out what you’re on

Faster than everything above:

1. Check your hosting control panel. Most show the PHP version per site, and many let you change it from a dropdown.
2. Or ask the server. php -v over SSH gives you the command-line version, which is not always the version your website runs. The web one is what matters.
3. Test on a staging copy before you move production. A dropdown that changes PHP versions in one click is also a dropdown that takes a site down in one click.

If you put up a phpinfo() page to check, delete it the moment you’re done. It publishes your full server configuration to anyone who finds the URL, and those paths get scanned for constantly.

---

If you’ve inherited a PHP codebase nobody has looked at in years, that’s routine work here rather than a job we’d rather avoid — including an honest read on whether it’s worth upgrading or worth replacing, which are different answers and we’ll tell you which one we think you’ve got.

And if the goal is never to be four versions behind again, that’s what server maintenance is for: somebody whose job includes knowing that 8.2 goes dark on 31 December 2026, before it does.