PHP 8.2 End of Life: What to Upgrade Before December 31, 2026

Quick answer

PHP 8.2 reaches end of life after December 31, 2026: php.net lists that date as the end of security support for the 8.2 branch. As of October 28, 2026 the branch is still supported upstream, but only in its security-only phase. Ordinary bug fixes stopped at the end of 2024, and security releases continue: the most recent is PHP 8.2.35, released on October 21, 2026.

End of life describes the PHP project's release work, not the state of your server. Nothing on a PHP 8.2 site breaks or is compromised because the date passes; what changes is that a vulnerability found in 8.2 afterwards gets no fix from the PHP project. Assess first (what runs where, and what blocks a newer version), then pick a target, then upgrade.

PHP support timeline: 8.2 to 8.5

Dates from php.net's supported-versions page, checked on October 28, 2026:

Each branch passes through three phases:

• Active support. The branch receives regular point releases with bug fixes and security fixes.
• Security-only support. Bugs that are not security issues are no longer fixed; security issues still get releases.
• End of life. The PHP project publishes no further releases for the branch, whatever is found later.

Operating system vendors, Linux distributions and some managed hosts build their own PHP packages, and some of them keep backporting security fixes into a branch after upstream support ends. In October 2026, for example, php.net noted that Linux distributions and long-term support vendors received the patches in advance. Whether a vendor does this for 8.2, for how long and for which fixes is vendor-specific, so confirm it with yours in writing. It is not the same as upstream support: you depend on one vendor's packages, and your frameworks and libraries will still drop 8.2 on their own timetable.

8.2 vs 8.3 vs 8.4 vs 8.5: choosing a target

There is no single right target. A workable rule is to choose the newest version that every part of the stack supports today, then confirm your host offers it. For WordPress sites, WordPress itself recommends PHP 8.3 or greater. PHP 8.6 is still a release candidate, so it is not a production target.

What happens if you don't upgrade

A PHP 8.2 server is not automatically vulnerable on January 1, 2027. The risk builds with time, from several directions:

• No upstream security fixes. Any vulnerability found in 8.2 after December 31, 2026 will not be fixed by the PHP project. The October 21 releases show why that matters: they fix two critical vulnerabilities that can allow unauthenticated remote code execution, with a release for each branch from 8.2 to 8.5. After end of life, 8.2 would not get the equivalent.
• Packages move on. Frameworks and libraries raise their minimum PHP version with new releases; Laravel 13 already requires PHP 8.3. Staying on 8.2 gradually freezes your dependencies at old versions too.
• Maintenance gets harder. Fewer hosts, images and tools carry an unsupported branch.
• Technical debt compounds. Every year of delay adds another release's changes to the eventual upgrade.
• Continuity risk. An upgrade forced by an incident or a host retiring the version happens under time pressure.

A ten-step migration checklist

1. 1. Identify the actual PHP runtime. Record the version that serves web requests on every server, container, worker and scheduled job, plus staging. Example: the command line reports 8.3 while the PHP-FPM pool behind the site still runs 8.2.
2. 2. Check vendor patch status. If a distribution or host supplies your PHP, ask which security fixes its current package includes and how long it will patch the branch. Example: a package whose version string looks older than upstream but contains backported fixes.
3. 3. Inventory the framework and dependencies. List the framework version, Composer packages or plugins, and PHP extensions. Example: a PDF library whose last release supports nothing newer than 8.2.
4. 4. Select a compatible target version. Use the inventory and the matrix above. Example: everything supports 8.4 except one reporting package; either replace that package first or move to 8.3 now and schedule 8.4.
5. 5. Prepare backups and a rollback. Keep a tested database backup, the previous release and the previous PHP image or package, and write down the rollback steps. Example: a restore rehearsed on staging.
6. 6. Set up staging. Match production: the target PHP version, the same extensions and settings, the same web server, and a recent copy of the data with personal information masked.
7. 7. Upgrade dependencies. Move Composer packages, plugins and extensions to releases that support the target version, and clear the deprecation notices that appear. Example: an older HTTP client library upgraded one major version, with its changed method names updated in the code.
8. 8. Run application and integration tests. Cover the paths that earn money or hold data. Example: sign-in, payment callbacks, a CSV import and a CRM webhook, run against sandbox accounts on staging.
9. 9. Deploy in controlled stages. Move one server, one site or a small share of traffic first, in a quiet period, then the rest. Example: restart queue workers and cron jobs on the new runtime in the same step.
10. 10. Monitor errors and performance. Compare error logs, response times and failed jobs against the numbers from before the change. Example: watching through a full business cycle, including month-end jobs, before removing the rollback option.

Laravel applications

Laravel publishes the PHP range for each release in its support policy:

Patching the PHP runtime and upgrading Laravel are two different jobs. The runtime is the interpreter installed on the server or baked into the container image; Laravel is a package in your composer.lock. Running composer update changes packages and leaves the interpreter exactly as it was.

In practice: a Laravel 12 application on PHP 8.2 can move to 8.3, 8.4 or 8.5 without a framework upgrade. A Laravel 11 application can go as far as 8.4, but the framework itself has had no security fixes since March 2026, so both need planning. Moving to Laravel 13 requires leaving 8.2 first. The phases for the framework side are in our Laravel upgrade and modernization checklist.

WordPress sites

WordPress recommends PHP 8.3 or greater, and treats PHP 7.4 or later as acceptable only in legacy environments, which are end of life. Moving a WordPress site to a newer PHP version is normally a compatibility exercise, not a rebuild. Work through it in this order:

• Hosting. Find out which PHP versions your host offers and how it switches them: per site, per account, or only on request.
• Themes and plugins. Check each one for a current release that supports the target version, and look for plugins that are no longer maintained.
• Custom code. In-house plugins and child themes get no vendor updates, so they need a code review against the target version.
• Staging. Switch PHP on a staging copy first.
• Backups. Back up both files and database, and know how to restore them.
• Regression testing. Test forms, checkout, logins and email.
• Managed hosting. If a managed host patches or upgrades PHP for you, ask what it does for 8.2 and when it plans to change it.

PHP 5 and 7 systems

Older systems are a separate case. php.net says that PHP 8.1 and older no longer receive updates from the PHP project, so anything on PHP 5 or 7 has been outside upstream support for years. What fits depends on the system:

• Vendor-supported patching, where an operating system or extended-support vendor still maintains the branch you run. Confirm exactly what it covers.
• Interim risk reduction: limit who can reach the application and remove unused entry points. For what the October 2026 security releases meant for older branches, see our guide to the PHP2Shell vulnerabilities.
• Dependency modernization: replace abandoned libraries before the PHP version changes, so each step has fewer moving parts.
• Incremental migration: one PHP branch at a time with tests at each step, or parts of the application moved to new code while the rest keeps running.
• Full modernization, only where the code cannot be brought forward safely in steps.

What drives cost and timeline

The size of an upgrade depends on:

• Codebase size: how much code has to be checked against the target version.
• Age: how many PHP branches the code has to cross.
• Tests: whether there is a suite to catch regressions, or one has to be written first.
• Dependency compatibility: how many packages, plugins and extensions need upgrades or replacements.
• Database: driver, extension and server version changes.
• Hosting architecture: one server, several, containers, or a managed platform with its own PHP schedule.
• Third-party integrations: payment, CRM and other connections that need sandbox testing.
• Rollback requirements: how quickly the previous version must be restorable.

If you want these assessed for your application, our PHP upgrade and migration service starts with the runtime and compatibility review described above.

Last reviewed October 28, 2026, against the linked php.net, Laravel and WordPress pages. Support dates change only rarely, but vendor and hosting policies do, so confirm them before you plan. This guide summarizes published information; it is not an assessment of your system.