Web Development

PHP versions and support dates: upgrading an old PHP site safely

8 min readBy Jaskirat Singh Talwar

Hands opening an old beige computer tower beside a small modern computer and a toolbox

As of 29 October 2026 the PHP project supports four branches: 8.4 and 8.5 get full bug and security fixes, while 8.2 and 8.3 get critical security fixes only. PHP 8.2 reaches end of life on 31 December 2026, and anything older (8.1, 8.0, every 7.x and 5.x) already gets no fixes at all. If your site runs on one of those, plan an upgrade now: check compatibility with tools, upgrade one version at a time on a copy of the site, and test before you switch production.

Key takeaways

  • Each PHP branch gets two years of active support and then two years of security-only fixes, then it reaches end of life (php.net).
  • Today the safe targets are PHP 8.4 (active until 31 December 2026, security until 31 December 2028) and PHP 8.5 (active until 31 December 2027, security until 31 December 2029).
  • End of life does not mean your site stops working. It means newly found security holes in PHP itself will not be fixed for your version.
  • Scan first with PHPCompatibility, automate the routine code changes with Rector, and test on a staging copy before you change the server.
  • Upgrade the framework, CMS, plugins and Composer packages together with PHP; they usually set the real limit.

Which PHP versions are supported right now?

The official table on php.net lists these supported branches (checked 29 October 2026):

Branch First released Active support until Security fixes until Status on 29 Oct 2026
8.5 20 Nov 2025 31 Dec 2027 31 Dec 2029 Active support
8.4 21 Nov 2024 31 Dec 2026 31 Dec 2028 Active support
8.3 23 Nov 2023 31 Dec 2025 31 Dec 2027 Security fixes only
8.2 8 Dec 2022 31 Dec 2024 31 Dec 2026 Security fixes only, ends in about two months

And these are already past end of life, according to php.net's unsupported-branches page:

Branch End of life Last release
8.1 31 Dec 2025 8.1.34
8.0 26 Nov 2023 8.0.30
7.4 28 Nov 2022 7.4.33
7.3 6 Dec 2021 7.3.33
7.2 30 Nov 2020 7.2.34
5.6 31 Dec 2018 5.6.40

Dates move on, so always check the live table at php.net/supported-versions.php before you plan.

What does "end of life" actually mean for my website?

It means the PHP project has stopped releasing fixes for that branch. The php.net definition is that users of an end-of-life release "should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities."

In practice four things happen:

  1. Security. When a flaw is found in PHP itself, there is no patched version for you to install.
  2. Software support. Frameworks, CMSs and libraries drop old PHP versions in their new releases, so you get stuck on old, unpatched versions of those too. WordPress, for example, recommends PHP 8.3 or greater and warns that PHP 7.4 has reached end of life.
  3. Hosting. Hosts and operating systems stop offering old PHP builds, sometimes with little notice, which can force an emergency move.
  4. Compliance. Security reviews and payment-card or customer audits often ask whether you run supported software.

The site keeps serving pages the day after end of life. The risk builds up quietly, which is why it is easy to put off.

Should I move to PHP 8.4 or 8.5?

For most business sites in late 2026, aim for 8.4 or 8.5, whichever your framework, CMS and plugins officially support. Both have years of security support ahead. PHP 8.5, released on 20 November 2025, added a pipe operator (|>), a built-in URI extension, "clone with" for updating properties while cloning, and the #[\NoDiscard] attribute, among other changes. You do not need these features to justify the upgrade; the support window is the main reason. If a key plugin or package is not yet ready for 8.5, 8.4 is a sound target.

Avoid upgrading to 8.2 or 8.3 as a final destination: 8.2 is out of support at the end of 2026 and 8.3 at the end of 2027, so you would repeat the work soon.

How do I upgrade an old PHP site safely?

Treat it as a small project with a rollback plan, not a switch you flip on the server.

  1. Take stock. Record the current PHP version, the framework or CMS version, every plugin, extension and Composer package, and the server setup. Note which ones are abandoned.
  2. Make a staging copy. Copy the code and a recent database to a separate server or container running the target PHP version. Never test an upgrade on the live site.
  3. Scan for incompatible code. Run PHPCompatibility (below) against your code with your target version. It lists functions, syntax and features that were removed or changed.
  4. Update dependencies first. Upgrade the framework or CMS and packages to versions that support the target PHP. This often fixes more problems than editing your own code.
  5. Automate the routine changes. Use Rector to apply known code upgrades, review every change it proposes, and commit in small steps.
  6. Go one major step at a time on very old code. From PHP 5.6 or 7.x, read the official migration guides for each version you cross (7.0, 7.1 and so on through 8.x); each lists backward-incompatible changes and deprecations.
  7. Test properly. Run automated tests if you have them. If you do not, write a checklist of the money paths (forms, checkout, login, search, admin tasks) and click through them. Turn on full error reporting on staging and read the logs for deprecation warnings.
  8. Switch with a rollback. Change production PHP in a quiet period, keep the old version available to switch back, and watch error logs for a few days.

Our PHP development team does this kind of upgrade, and if the site also needs a new design or platform, our website redesign and migration page covers that route.

Which tools help with a PHP version upgrade?

Two free, open-source tools do most of the heavy lifting.

PHPCompatibility is a set of rules for PHP_CodeSniffer that finds code that will not work on the PHP versions you target. Installed with Composer, you run it like this (the 8.4- means "8.4 and newer"):

vendor/bin/phpcs -ps . --standard=PHPCompatibility --runtime-set testVersion 8.4-

Check the project page for the current release before you install: as of October 2026 its README documents the 10.x branch, published as alpha versions on Packagist, while the last stable release is 9.3.5.

Rector describes itself as "fast, deterministic PHP code upgrades and automated refactoring". It rewrites code for you rather than just reporting. Install it with composer require rector/rector --dev, add a rector.php file, and preview changes before applying them:

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpSets(); // uses the PHP version in composer.json

vendor/bin/rector process --dry-run

Rector's documentation suggests raising its rule levels one step at a time on legacy projects rather than applying everything at once.

A static analyser such as PHPStan is a useful third check: it catches type and logic errors that both tools above can miss. Our older post on security tips for PHP developers covers coding habits worth fixing while you are in the code.

What if the site uses an old framework or CMS?

Then the framework, not PHP, sets the plan. An old Laravel, Symfony, CodeIgniter or WordPress version often cannot run on a supported PHP at all, so you upgrade it in steps alongside PHP. Sometimes the cheaper route is to rebuild key parts on a current framework. We build with Laravel among other stacks, and our article on Laravel in 2026 explains when it suits business applications. If you are weighing a full platform change, our guide to choosing a tech stack walks through the trade-offs.

Custom code with no tests, no documentation and abandoned packages is the hardest case. Start with the scan and an inventory; together they tell you whether you are looking at an upgrade or a rewrite.

How long does a PHP upgrade take?

It depends on the size of the codebase, how far behind it is, how many third-party packages it relies on and whether it has tests. A small site already on PHP 8.x with maintained plugins can be a short job. A large custom application on PHP 5.6 with abandoned libraries can take much longer. Running the compatibility scan first gives you a list of issues to estimate from instead of a guess.

FAQ

Which PHP version should I use in late 2026?

PHP 8.4 or 8.5, as long as your framework, CMS and plugins support it. Both receive security fixes until at least the end of 2028.

Will my site break when PHP reaches end of life?

No. It keeps running. What stops is the supply of fixes for security issues in PHP itself, and over time your host and your software stop supporting that version.

Is PHP 8.2 still safe?

It still gets critical security fixes until 31 December 2026, then none. Plan to move off it now.

Can I jump straight from PHP 7.4 to 8.5?

You can change the server in one step, but the code changes span every version in between. Read the migration guides for 8.0 through 8.5, scan with PHPCompatibility for the target version, and test on staging.

Do Rector and PHPCompatibility do the whole job?

No. They find and fix known patterns. You still need to update dependencies, review the changes and test the site's real tasks.

How do I find which PHP version my site runs?

Your hosting control panel usually shows it, or a developer can run php -v on the server. Check the version the website actually uses, which can differ from the command-line version.

Sources (10 links)
Share this article