PHP 8.2 reaches end of life on 31 December 2026: an upgrade checklist

PHP 8.2 receives its last security fixes on 31 December 2026. After that date the PHP project stops publishing patches for the 8.2 branch, so any server still running it will collect unfixed vulnerabilities from January 2027 onwards. If you run a SaaS product, a client site or an internal tool on 8.2, the upgrade now has a fixed deadline.

The good news is that the step from 8.2 to a current branch is usually smaller than the jump from PHP 7 to PHP 8 was. Most of the work is finding deprecated patterns, checking that your Composer dependencies support the new version and testing in a staging environment before you switch production.

This guide gives you the current support picture as published on php.net on 7 October 2026, helps you choose a target version, and then walks through a practical checklist you can copy into your own ticket tracker.

Which PHP versions are supported in October 2026

The official supported-versions page lists four branches today. As the dates show, each branch gets about two years of active support (bug and security fixes with regular point releases) followed by about two years of security-only fixes, which the PHP project releases as needed.

All four point releases listed above were published on 24 September 2026 and were announced as security releases, so if you are on any supported branch, the first action is simply to apply the latest patch.

PHP 8.6 is not yet stable. Release candidate 2 was published on 24 September 2026, and the PHP 8.6 release schedule on the PHP wiki targets general availability on 19 November 2026. Release candidates are for testing only; do not deploy them to production.

Choosing your target: 8.4 or 8.5

If you are leaving 8.2, you can technically move to 8.3, but it only buys security support until the end of 2027. For most teams the realistic choice is between 8.4 and 8.5.

• PHP 8.5 is in active support until 31 December 2027 and receives security fixes until 31 December 2029. It has been stable for almost a year and has had eleven patch releases. Choose it if your framework, CMS and key libraries declare support for it.
• PHP 8.4 leaves active support on 31 December 2026 but stays on security support until 31 December 2028. It is a sensible target if an important dependency has not yet confirmed 8.5 compatibility.
• PHP 8.6 is worth testing in CI now so that your next upgrade is easier, but wait for the stable release and the first few patch releases before you plan production use.

Whichever version you choose, check the require section of your framework's or CMS's own composer.json and its release notes rather than relying on blog posts. That is the single most common blocker.

The upgrade checklist

Work through these steps in order. Each one is small, and doing them in sequence keeps surprises out of production.

1. Take an inventory

• List every place PHP runs: web servers, PHP-FPM pools, queue workers, cron jobs, CLI scripts, Docker base images and CI runners. A forgotten cron host on 8.2 is a common gap.
• Record the exact version on each host with php -v, and the loaded extensions with php -m.
• Note where PHP comes from: the operating system's packages, a third-party repository, an official Docker image or your hosting provider's control panel. That determines how you will install the new version.

2. Tell Composer about the target version

Composer resolves dependencies against the PHP version it is running on unless you tell it otherwise. During the upgrade, raise the PHP requirement in your project and, if your local machine runs a different version from production, pin the platform version in the config section:

{
    "require": {
        "php": "^8.4"
    },
    "config": {
        "platform": {
            "php": "8.4.26"
        }
    }
}

The Composer documentation warns that a faked platform version means dependencies are no longer checked against the PHP you actually run, so it recommends also running composer check-platform-reqs as part of your deployment. Do that on the target server image before you switch traffic.

3. Update dependencies

• Run composer outdated --direct to see which of your direct dependencies have newer releases.
• Update your framework first, following its own upgrade guide, then the rest of the packages.
• Run composer audit afterwards to make sure none of the versions you landed on has a known security advisory.

4. Fix deprecations before they become errors

Deprecation notices are the PHP project's advance warning of future breaking changes. Turn them on in development and CI (error_reporting = E_ALL) and log them in staging. The migration guides on php.net list every change. Some that commonly appear when moving from 8.2:

The implicitly nullable parameter change is the one most codebases hit, and it is easy to fix mechanically:

// Deprecated as of PHP 8.4
function sendInvoice(Customer $customer, ?string $note = null, Mailer $mailer = null) {}

// Explicit and future-proof
function sendInvoice(Customer $customer, ?string $note = null, ?Mailer $mailer = null) {}

Static analysis tools and automated refactoring tools can find most of these patterns across a whole codebase. Run them against the target version rather than fixing files by hand.

5. Check behaviour changes, not only deprecations

Some changes in the "backward incompatible changes" sections do not emit a notice first. Moving to 8.5, for example, a warning is now emitted when a float that cannot be represented as an integer is cast to int, destructuring a non-array value with [] or list() now warns, and the disable_classes INI setting has been removed. If your hosting configuration relies on disable_classes, plan another control before you upgrade. Read the full list for every version you are crossing: an upgrade from 8.2 to 8.5 crosses three migration guides (8.3, 8.4 and 8.5).

6. Review the PHP configuration

• Copy your php.ini and PHP-FPM pool settings across deliberately, rather than reusing an old file without reading it.
• From PHP 8.5, OPcache is always built into the PHP binary and always loaded; the opcache.enable and opcache.enable_cli settings are still honoured. Review any zend_extension=opcache line carried over from an old configuration, because the build no longer produces a separate opcache.so file, and check the startup log after the switch.
• The JIT has been disabled by default since PHP 8.4 (opcache.jit=disable). If you want it, enable it explicitly and measure the effect on your own workload.
• Keep production error display off (display_errors=Off) and logging on.

7. Test properly

• Run your automated test suite on the target version in CI. Add the target version to your CI matrix first, so that both versions are tested while you migrate.
• Build a staging environment from the same image you will deploy, including the same extensions.
• Exercise the parts that tests rarely cover: payment callbacks, file uploads, scheduled jobs, PDF generation and email sending.
• Watch the logs for new warnings and deprecations during a few days of staging use.

8. Roll out and keep a way back

• Upgrade one server, one pool or a percentage of containers first, and watch error rates and response times.
• Keep the previous runtime image available for a quick rollback, and make sure database migrations made during the upgrade are compatible with both versions.
• Upgrade queue workers and cron hosts in the same window, so that the whole application runs on one version.

Shared hosting and managed platforms

If you use shared hosting or a managed platform, you may only need to select a new PHP version in the control panel. The checklist still applies: update dependencies locally against the target version, test on a staging copy if the host provides one, and then switch. Ask your provider which date they will stop offering 8.2, because hosts set their own timelines and some may keep an end-of-life version available longer with their own patches. That does not replace upgrading.

Keeping current after this upgrade

Once you are on 8.4 or 8.5, avoid the next deadline crunch:

• Apply patch releases routinely. In recent months the PHP project has published them about every four weeks for supported branches.
• Keep the next minor version in your CI matrix so that incompatibilities appear early.
• Put the end-of-security-support date of your current branch in your team calendar.
• Subscribe to the release announcements on php.net.

Summary

PHP 8.2 loses security support on 31 December 2026. For most projects the best target today is PHP 8.5, with 8.4 as a fallback when a dependency is not ready. Take an inventory of every place PHP runs, align Composer with the target version, fix deprecations from each migration guide you cross, review your configuration (especially OPcache in 8.5), test on staging and roll out gradually. Then keep patching, so that the next upgrade is routine rather than urgent.