PHP 8.2 End of Life: Upgrading to PHP 8.3, 8.4 or 8.5

PHP 8.2 stops receiving security fixes on 31 December 2026, less than three months away. If your Laravel, WordPress, Magento or custom PHP application runs on 8.2 or older, this is the window to move it.

Here are the dates, what each platform needs and how we approach the upgrade, checked against the vendors’ own pages on 3 October 2026.

PHP end of life dates, 8.1 to 8.5

Version	Released	Active support ends	Security support ends
8.1	25 November 2021	Ended	31 December 2025
8.2	8 December 2022	31 December 2024	31 December 2026
8.3	23 November 2023	31 December 2025	31 December 2027
8.4	21 November 2024	31 December 2026	31 December 2028
8.5	20 November 2025	31 December 2027	31 December 2029

During active support, “bugs and security issues that have been reported are fixed” in regular point releases. After that, PHP fixes “critical security issues only”, as needed. Then the version reaches end of life.

As of today:

• PHP 8.1 is already end of life. Its last release was 8.1.34.
• PHP 8.2 and 8.3 get security fixes only.
• PHP 8.4 leaves active support the day 8.2 reaches end of life.
• From 1 January 2027, PHP 8.5 is the oldest version in active support. PHP ships a new version every November, so the late-2026 release will be in active support too.

What end of life means

Nothing switches off on 1 January 2027. What stops is the fixes. php.net describes an end of life release as “no longer supported” and says its users “may be exposed to unpatched security vulnerabilities.”

A fully patched framework can still sit on a runtime that isn’t. Adobe spells this out: it “does not provide security and quality fixes for third-party services and software dependencies (such as PHP and MySQL)”, even while your Commerce version is in support.

Which PHP your platform needs

Your framework or CMS sets the ceiling, then every package, plugin and extension on top of it.

Laravel

Laravel	PHP	Security fixes until
10	8.1 to 8.3	4 February 2025
11	8.2 to 8.4	12 March 2026
12	8.2 to 8.5	24 February 2027
13	8.3 to 8.5	17 March 2028

Laravel gives each major release 18 months of bug fixes and two years of security fixes. A Laravel 12 application on PHP 8.2 has two deadlines eight weeks apart: PHP 8.2 on 31 December 2026 and Laravel 12 on 24 February 2027. Laravel 13 needs PHP 8.3 or later, so PHP has to move before or with the framework. We would plan them as one piece of work.

Laravel 11 and earlier are already past security support. More on our Laravel work.

WordPress

WordPress recommends PHP 8.3 or greater, and still runs on 7.4. Core added beta support for PHP 8.3 in WordPress 6.4, 8.4 in 6.7 and 8.5 in 6.9. Each starts as beta until plugins and themes catch up; 8.3 was raised to fully compatible in WordPress 6.8.

Core is rarely the blocker. WordPress’s handbook notes that it is “rarely used in isolation (without any theme or plugins)”, and each theme and plugin has its own PHP support. Check every one first. See WordPress development.

Magento and Adobe Commerce

Adobe’s system requirements tie each 2.4.x line to specific PHP versions. For the latest patch release of each line:

Magento line	Supported PHP
2.4.4 and 2.4.5	8.1
2.4.6	8.1, 8.2
2.4.7	8.2, 8.3
2.4.8	8.3, 8.4
2.4.9	8.5

That makes 2.4.6 the hard case. From 2027, neither of its PHP versions gets security fixes, so the PHP upgrade is also a Magento upgrade. A 2.4.7 store can move to PHP 8.3, which holds until the end of 2027. Adobe’s lifecycle page lists PHP 8.1 end of life on 31 December 2025 and 8.2 on 31 December 2026. Our Magento 2.4 end of life dates cover the platform side, and Magento upgrades covers how we do the work.

Custom PHP

With no framework, the limit is your own code and the extensions it uses, so the deprecations and removals below matter most. If nobody currently owns the codebase, start with what the first two weeks of an inherited PHP application look like.

PHP 8.3, 8.4 or 8.5?

Go as far as your stack allows.

• PHP 8.3 buys a year, to 31 December 2027. Choose it only if something pins you there, such as Magento 2.4.7.
• PHP 8.4 runs to the end of 2028, on Laravel 12 and 13, WordPress 6.7 or later and Magento 2.4.8.
• PHP 8.5 runs to the end of 2029, on Laravel 12 and 13, WordPress 6.9 or later and Magento 2.4.9.

Going straight from 8.2 to 8.4 or 8.5 is fine, but you still deal with every change in between.

Hosting and control panels

On managed hosting the PHP version is often just a setting. In cPanel, for example, MultiPHP Manager lets each domain use any PHP version installed on the server.

That makes the switch easy, which is the risk. The setting changes the runtime, not your code or its dependencies. Ask your host when it will remove 8.2, and test before you change production. Check cron jobs and queue workers too, because they don’t always run on the same PHP as the website.

A safe upgrade, step by step

1. Inventory

List every application, its server, its PHP version (php -v on the command line), its framework or CMS version and the PHP extensions it relies on, including jobs and scripts that run outside the website.

2. Audit dependencies

Composer shows what blocks the upgrade:

composer why-not php 8.4
composer outdated --direct

The first lists the packages whose requirements stop you running on PHP 8.4. The second lists direct dependencies with newer releases. Each blocker is a package to upgrade, replace or remove, and each upgrade can move something else.

3. Static analysis and automated refactoring

PHPCompatibility flags PHP features deprecated, removed or new in a target version. Its last stable release, 9.3.5, predates PHP 8, so its README installs the 10.0 development version:

composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer require --dev phpcompatibility/php-compatibility:"^10.0.0@dev"
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4 --ignore=*/vendor/*,*/node_modules/*

PHPStan analyses code as if it ran on the version set in its phpVersion parameter, such as 80400 for PHP 8.4.

Rector rewrites code. Its PHP sets apply rules version by version, and the PHP 8.4 set includes a rule that fixes the implicitly nullable parameters shown below. Preview before you apply:

composer require rector/rector --dev
vendor/bin/rector process --dry-run

The dry run only shows PHP upgrade fixes once your rector.php turns on the PHP sets for your target version, so set that up first; Rector’s documentation shows how.

On an existing project, Rector’s documentation advises raising the level one step at a time in small pull requests. We agree.

4. Deal with deprecations and removals

Deprecated code still runs, with an E_DEPRECATED notice. Removed features break.

From PHP 8.3:

• ++ on empty, non-numeric or non-alphanumeric strings, and -- on empty or non-numeric strings, are deprecated.
• Calling get_class() or get_parent_class() without arguments is deprecated.
• assert_options() and the assert.* INI settings are deprecated.
• range() now throws errors or warnings for several inputs it used to accept.

From PHP 8.4, the deprecation most codebases hit:

// Deprecated in PHP 8.4: the null default makes the type implicitly nullable
function find(User $user = null) {}

// Fine: the type says it can be null
function find(?User $user = null) {}

Also from PHP 8.4:

• trigger_error() with E_USER_ERROR is deprecated. Throw an exception instead.
• mysqli_ping(), mysqli_kill(), mysqli_refresh() and lcg_value() are deprecated.
• The IMAP, OCI8, PDO_OCI and PSpell extensions moved out of PHP to PECL. Code that reads a mailbox with imap_* functions stops working unless the extension is installed separately.
• The default bcrypt cost for password_hash() went from 10 to 12, so new password hashes take longer to compute.

PHP 8.5 adds its own list if you go that far, including the backtick operator, casts such as (integer) and (boolean), and using null as an array offset.

5. Test on the new version

Run the test suite on the target PHP version with deprecation notices logged. Then test what automated tests often miss: checkout, logins, scheduled jobs, imports, email and integrations. If coverage is thin, put tests around the paths that would hurt most first. On the new server, composer check-platform-reqs confirms the PHP version and extensions match what your installed packages need.

6. Roll out in stages

Staging first, on the same PHP build production will run. Then production at a quiet time, with the old PHP version still installed and a known way to switch back. Watch the error logs afterwards, because some code paths only run under real traffic.

If the site takes card payments

PCI DSS applies. Requirement 6.3.3 of PCI DSS v4.0 says system components are protected from known vulnerabilities by installing applicable security patches, with “critical or high-security patches/updates” installed “within one month of release.” Version 4.0.1, the only current version since 31 December 2024, narrowed the one-month rule to critical vulnerabilities.

Either way, the requirement assumes a patch exists. On PHP 8.2 after 31 December 2026, a critical PHP vulnerability can be disclosed with no patch for you to install, within a month or at all. Adobe’s lifecycle page marks PHP 8.2 as “PCI compliance at risk from end of 2026”. If unsure, talk to your qualified security assessor.

What we would do this month

• On PHP 8.1 or older: you are already unsupported. Start now.
• On PHP 8.2: run the dependency audit this week, to learn whether this is a version change or a framework upgrade.
• On PHP 8.3: plan the move to 8.4 or 8.5 alongside your next framework upgrade.
• On PHP 8.4 or 8.5: keep applying the point releases.

Two versions behind is routine maintenance. Six is a project. We will tell you which yours is before you commit budget to it. More on our PHP development work.

---

Sources: Supported versions, Unsupported branches, PHP 8 ChangeLog, PHP 8.3 deprecated features, PHP 8.3 backward incompatible changes, PHP 8.4 deprecated features, PHP 8.4 removed extensions, PHP 8.4 other changes and PHP 8.5 deprecated features (PHP), Laravel release notes and support policy (Laravel), WordPress requirements and PHP compatibility and WordPress versions (WordPress), Adobe Commerce system requirements and Adobe Commerce lifecycle policy (Adobe), Composer command-line interface, PHPCompatibility, PHPStan config reference, Rector documentation and ExplicitNullableParamTypeRector, cPanel MultiPHP Manager, PCI DSS v4.0 SAQ D for Merchants and Just Published: PCI DSS v4.0.1 (PCI Security Standards Council).