PHP 8.2 support ends 31 December 2026: how to plan the upgrade

If your company runs a web application, a customer portal or an internal tool on PHP, one date matters this year. According to the PHP project's supported versions page, security support for PHP 8.2 ends on 31 December 2026. After that date the branch is end of life, and the project says users of such a release "should upgrade as soon as possible" because they may be exposed to unpatched security vulnerabilities.

This article is for the person who decides what happens to that application: which version, in what order, and what if the move is not finished in time.

What the PHP calendar actually says

PHP gives each branch two years of active support, then two more years of fixes for critical security issues only. The current table on php.net reads like this:

PHP 8.2 has been in security-only mode since the end of 2024, and a move to 8.3 buys only one more year.

In our reading, the real task is not "install a newer PHP" but finding what your application, framework and hosting each allow, then choosing the newest version all three accept.

Step 1: find out what you actually run

Most upgrade delays start with a wrong assumption about the version. Write down, for every environment (production, staging, developer machines, the CI runner, the scheduled-jobs server), the PHP version the application really uses. Check the command line and the web server separately: they can differ. If you also maintain .NET applications, our deployed-runtime check after .NET 8 and 9 support ends explains why a host update may leave an application's bundled runtime unchanged.

Then list who controls each one. If a hosting provider or an agency runs the server, ask them in writing which PHP version is configured and what their own end date is. Their policy is theirs to state; do not assume it matches php.net.

Step 2: check what your framework allows

The framework sets the upper and lower bounds, so read its policy before choosing a target. Three common cases, all from the projects' own documentation:

• Laravel. The Laravel 12 support policy lists PHP 8.2 to 8.5, with security fixes until 24 February 2027. Laravel 11 security fixes ended on 12 March 2026. Laravel 13, released on 17 March 2026, supports PHP 8.3 to 8.5 and has security fixes until 17 March 2028; its release notes state a minimum of PHP 8.3. So a Laravel 11 application on PHP 8.2 has two clocks running, and the framework one has already stopped.
• Symfony. The Symfony releases page lists 6.4 (LTS) with a minimum of PHP 8.1 and security fixes until the end of November 2027, and 7.4 (LTS) with a minimum of PHP 8.2 and security fixes until the end of November 2029. The page gives months, not exact days.
• WordPress. The WordPress requirements page recommends PHP 8.3 or greater. It says WordPress also works with PHP 7.4 and newer, but warns that end-of-life versions may expose a site to security vulnerabilities. Plugins and themes carry their own requirements.

For a custom framework or older codebase, the check becomes a dependency check: every package in the lock file needs a release that supports the target version.

Step 3: choose the target

With the facts in hand, the choice is a short comparison:

In our reading, 8.4 is the sensible default for most teams, because it gives two years without being the newest release, so more libraries have had time to catch up. That is judgement, not a rule: if your framework version or your hosting stops at 8.3, take 8.3 and put the next upgrade in the calendar now instead of discovering it in late 2027.

PHP 8.4 leaves active support on 31 December 2026 but keeps security fixes for two more years; for a business application, the security date is the one that matters.

Step 4: run the upgrade in small, reversible steps

The PHP project publishes migration guides for each release, with sections for backward incompatible changes and deprecated features. Read the 8.3 guide and the 8.4 guide before touching the code. One example from the 8.4 deprecations: a parameter whose type is written without a question mark but whose default is null is now deprecated, and the guide says to write the type as nullable explicitly. Older code often contains this pattern.

A workable order:

1. Make the current version reproducible: the same PHP version and extensions in staging as in production.
2. Run the automated tests, and add a handful of checks for the paths that earn money or hold data: login, checkout or ordering, file upload, scheduled jobs, e-mail sending.
3. Move staging to the target version and read the logs for deprecation notices, not just for errors.
4. Upgrade one minor version at a time if you are jumping from 8.2 to 8.4 and the test coverage is thin, so a failure points at one change.
5. Deploy to production at a quiet hour, with the previous runtime still installed and a written way back: which command switches the version back, who runs it, and how long it takes.
6. Keep the old environment for a short, named period, then remove it.

Keep the runtime change separate from other changes. If a release also needs a database migration, such as building an index on a large table, do that on its own day; our note on when to wait or retry a concurrent PostgreSQL index build covers that side.

If you cannot finish by 31 December

Sometimes the upgrade will not fit: a plugin has no compatible release, a vendor must rewrite a module, or a holiday freeze removes the deployment window. Staying on 8.2 for a while should be a decision, not an accident:

• Name one owner who accepts the risk, and write the end date next to it.
• Ask your host or distribution vendor whether they offer their own extended support for PHP 8.2, and what it covers. That is their commitment to describe, and it differs from the PHP project's.
• Reduce exposure meanwhile: patch everything else, restrict what is reachable from the internet, and watch security advisories for your framework and packages.

This plan does not fit every case. If the application is a packaged product run by a vendor, the upgrade belongs in their roadmap, and your job is to ask for the date. And we have not checked the extended-support terms of any specific hosting provider or Linux distribution; read those on their own sites.

What to do this week

Spend one hour listing every PHP environment and its version, and send the question about the vendor's PHP end date to every external party that runs one. Then pick a target from the framework policy above and book the staging upgrade before the end of November. If the application is old enough that the upgrade looks risky, the safer route is often to modernise it in stages rather than in one jump; our guide to choosing the first module when modernising a legacy system in pieces shows how to start, and the monthly routine for updates and patches with one owner and a rollback plan is a good home for making this kind of upgrade recurring instead of urgent. If you want a second pair of eyes on the plan, White Veil Industries builds and maintains custom software and can review your upgrade path.

Sources

• PHP Group, "Supported Versions", 2026 (read 14 November 2026): php.net/supported-versions.php
• PHP Group, "Migrating from PHP 8.2.x to PHP 8.3.x", PHP manual, 2023, still the current guide for that step: php.net/manual/en/migration83.php
• PHP Group, "Migrating from PHP 8.3.x to PHP 8.4.x" and "Deprecated Features", PHP manual, 2024, current guide for that step: php.net/manual/en/migration84.php, deprecated features
• Laravel, "Release Notes, Laravel 12.x" (support policy), 2026: laravel.com/docs/12.x/releases
• Laravel, "Release Notes, Laravel 13.x" (support policy, PHP 8.3 minimum), 2026: laravel.com/docs/13.x/releases
• Symfony, "Symfony Releases", 2026 (months only, no exact days): symfony.com/releases
• WordPress.org, "Requirements", 2026: wordpress.org/about/requirements