PHP 8.1 is end-of-life: how to migrate to PHP 8.4

PHP 8.1 is no longer supported. The branch got its last release, 8.1.34, on December 31, 2025, and has not received even security fixes since. If your site or service still runs on 8.1 (let alone 8.0 or 7.4), every new PHP vulnerability stays in it for good. Here is which version to move to, what breaks along the way and how to make the switch without surprises in production.

PHP support timelines

Each PHP branch gets full support for two years and security fixes only for two more. As of October 2026:

• PHP 8.1: support ended on December 31, 2025.
• PHP 8.2: security fixes only, until December 31, 2026. In a couple of months 8.2 will be where 8.1 is now.
• PHP 8.3: security fixes only, until December 31, 2027.
• PHP 8.4: active support until December 31, 2026, security fixes until December 31, 2028.
• PHP 8.5: active support until December 31, 2027, security fixes until December 31, 2029.

Why an unsupported version is risky: the PHP2Shell example

In October 2026 two critical vulnerabilities were found in PHP, PHP2Shell (CVE-2026-109618 and CVE-2026-109619): code execution on the server without authentication. The PHP team released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There were no official releases for 8.1 and older, only minimal source fixes that you have to build yourself or wait for your distribution vendor to ship. Details are in our PHP2Shell news post.

That is what life on an outdated branch looks like: with every serious vulnerability you depend on whether someone ships a backport, and when. Some Linux distributions and commercial vendors extend support for old versions, but that is a stopgap and one more dependency.

Which version to move to: 8.4 or 8.5

Moving to 8.2 now makes no sense: its support ends on December 31, 2026, and you would have to repeat the upgrade in two months. The real choice is between 8.4 and 8.5.

• PHP 8.4 is the sensible default for existing projects. Every major platform supports it: Magento 2.4.8, Laravel 11, 12 and 13, Symfony 7.4 LTS and 8.1, and current WordPress. Security fixes run until the end of 2028.
• PHP 8.5 if the project runs Magento 2.4.9 (which requires PHP 8.5), or if you are starting a new project and want the longest support window, until the end of 2029. Before choosing it, check that every extension and library the project depends on already works on 8.5.

Platform compatibility as of October 2026:

• Magento / Adobe Commerce: 2.4.9 runs on PHP 8.5; 2.4.8 on PHP 8.4 and 8.3; 2.4.7 on 8.3 and 8.2; 2.4.6 on 8.2 and 8.1. Standard support for 2.4.6 ended on August 11, 2026, so a store on 2.4.6 and PHP 8.1 has to upgrade both Magento and PHP.
• Laravel: 12 supports PHP 8.2–8.5 (security fixes until February 24, 2027), 13 supports PHP 8.3–8.5. Laravel 10 and 11 no longer get security fixes.
• Symfony: 6.4 LTS requires PHP 8.1+ (security fixes until November 2027), 7.4 LTS requires PHP 8.2+, 8.1 requires PHP 8.4+.
• WordPress: recommends PHP 8.3 or newer. It still runs on 7.4, with the caveat that such versions may expose your site to security vulnerabilities. In practice the limit is usually set by plugins and the theme, not by core.

What breaks when moving from 8.1 to 8.4

There are three branches between 8.1 and 8.4, and each brings changes that affect real code. Most of them first show up as deprecation notices, but frameworks and test suites often turn those notices into errors.

• PHP 8.2: dynamic properties. Creating a property that is not declared on the class now raises a deprecation notice. This is the most widespread change in older code. Fix it by declaring the property, adding the #[\AllowDynamicProperties] attribute, or using a WeakMap for objects you don't own.
• PHP 8.2: "${var}" interpolation is deprecated; use "$var" or "{$var}". utf8_encode() and utf8_decode() are deprecated (use mb_convert_encoding()), and so are callables like "self::method" passed to call_user_func().
• PHP 8.3: get_class() and get_parent_class() without arguments, ++ and -- on empty and non-numeric strings, and assert_options() are deprecated.
• PHP 8.4: implicitly nullable parameters. function foo(Bar $bar = null) is deprecated; write ?Bar $bar = null explicitly. You will find this in almost every older project and in many dependencies.
• PHP 8.4: extensions moved to PECL. IMAP, OCI8, PDO_OCI and PSpell are no longer part of PHP. If the project reads mail over IMAP or talks to Oracle, install the extension separately or switch libraries.
• PHP 8.4: stricter argument checks. exit() is now a function and throws a TypeError on a wrong type, round() throws a ValueError on an invalid mode, and PDO attributes like PDO::ATTR_EMULATE_PREPARES are now booleans. E_STRICT, trigger_error() with E_USER_ERROR, the default escape parameter in CSV functions and several session settings are deprecated.

Dependencies are a story of their own. Older Composer packages may not support the new PHP, and then the PHP upgrade pulls in a framework upgrade with its own changes.

Tools

• Rector rewrites code for a newer PHP version automatically, for example adding explicit nullable types. Configure it with RectorConfig::configure()->withPhpSets(): with no arguments Rector takes the version from composer.json. Review Rector's changes like any other code review.
• PHPCompatibility for PHP_CodeSniffer finds incompatible constructs without running the code: vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4. Its authors don't claim full coverage, so it complements tests rather than replacing them.
• PHPStan at a strict level catches type errors that newer PHP versions turn from silent into explicit.
• Deprecation logs on a staging environment running the new PHP are the most honest source: they show what actually executes in your code and your dependencies.

Migration plan

1. Inventory. Which servers, PHP versions and modes (PHP-FPM, mod_php, CLI for cron and queues), which extensions are enabled, which framework and package versions are installed.
2. Pick the target version. 8.4 or 8.5, based on the compatibility matrix of the platform and key packages. If the platform itself needs an upgrade (like Magento 2.4.6), plan both upgrades together.
3. Static analysis and automated fixes. PHPCompatibility and PHPStan show the scope of work, and Rector handles the mechanical part.
4. Update dependencies. Running composer with the target PHP version in config.platform shows which packages block the move.
5. Staging environment. A copy of production on the new PHP: automated tests, manual checks of key flows (checkout, payment, customer account, import and export, cron), and deprecation logs.
6. Roll out with a rollback plan. Keep the old PHP version available, switch at a quiet time, and watch logs and errors after the rollout.

How long it takes

There is no universal number; the effort depends on a few things. How well the code is covered by tests. How much custom code there is and how old it is: a project that already runs on 8.1 without deprecation notices moves much more easily. Whether every package and module supports the new PHP; for Magento and WordPress, third-party modules and plugins are most often the bulk of the work. And whether the platform itself needs an upgrade too. A code audit and a test run on the new PHP over a few days give you a real estimate instead of a guess.

We have been working with PHP, Magento and Laravel for more than ten years. We will audit compatibility, move the project to PHP 8.4 or 8.5 together with its dependencies and platform, verify it on staging and roll it out with a rollback plan.

Sources: PHP supported versions, unsupported PHP branches, migration guides for PHP 8.2, PHP 8.3 and PHP 8.4, Adobe Commerce system requirements, Adobe Commerce lifecycle policy, Laravel support policy, Symfony releases, WordPress requirements, Rector, PHPCompatibility.