Moving Magento to PHP 8.5: What Breaks and How to Fix It

Magento 2.4.9 requires PHP 8.5, and 2.4.8 runs on PHP 8.4 or 8.3. Moving a store to PHP 8.5 rarely breaks Magento core itself, because Adobe tests core against it. What breaks is the code around it: older extensions, custom modules, Composer dependencies that do not allow PHP 8.5, and server configuration. Most of these problems can be found on a staging server before customers ever see them.

Below is the PHP version for each 2.4.x line, the typical failure types when moving up, and how to detect and fix each one.

Which PHP version does each Magento version support?

The table lists the PHP versions for the latest patch on each 2.4.x line, from Adobe's system requirements page, alongside the date each PHP version stops getting security fixes from the PHP project.

Two points stand out. First, Adobe's 2.4.9 release notes say PHP 8.4 is allowed on 2.4.9 for upgrade purposes only and is not recommended for production. Plan to run 8.5 in production. Second, stores on 2.4.6 or older are already on, or close to, a PHP version with no security fixes. Adobe's lifecycle policy says it does not fix third-party dependencies such as PHP once they reach end of life.

PHP 8.5 is the headline change in 2.4.9, but not the only one. Our overview of what's new in Magento 2.4.9 covers the database, search and cache changes that come with it.

What typically breaks, and how to detect it

The table groups the problems you are most likely to meet when moving a Magento codebase up to PHP 8.5, roughly in the order you will discover them.

Composer constraints come first

Composer is usually the first wall you hit, which is good, because it fails loudly. These two commands, run on your upgrade branch, show which packages block the move and whether the server has what Composer needs:

# Which installed packages do not allow PHP 8.5?
composer why-not php 8.5.0

# On the PHP 8.5 server: are all platform requirements met?
composer check-platform-reqs

Each blocking package is a decision: update, replace or fix. That decision is the same one you face when weighing whether to build or buy a Magento extension. An abandoned extension that blocks PHP 8.5 is often the moment to replace it with something maintained or with a small custom module.

PHP 8.5 deprecations that show up in Magento code

Deprecated features still work in PHP 8.5, but they raise notices and may be removed in a future version. These are the ones most likely to appear in older Magento modules, based on the PHP manual's list:

• Non-canonical casts:(integer), (boolean), (double) and (binary) should become (int), (bool), (float) and (string).
• Null as an array offset:$array[null] and array_key_exists(null, $array) are deprecated.
• __sleep() and __wakeup(): soft-deprecated in favor of __serialize() and __unserialize(). Watch for these in classes that are cached or stored in sessions.
• Backtick shell execution: the backtick operator is deprecated; use shell_exec(), or better, avoid shell calls in web requests.
• A semicolon after case:case 1; should be case 1:.
• PDO driver constants: for example PDO::MYSQL_ATTR_INIT_COMMAND becomes Pdo\Mysql::ATTR_INIT_COMMAND. This matters for custom database connections, such as ERP sync scripts.
• Explicit free functions:curl_close(), imagedestroy() and finfo_close() are deprecated because objects are freed automatically. They are common in older image and import modules.

Backward-incompatible changes worth checking

A few PHP 8.5 changes alter behavior rather than just adding notices:

• Casting a float that cannot be represented as an integer now emits a warning. Price, weight and quantity calculations in custom code are worth testing.
• Destructuring a non-array value (other than null) with [] or list() now emits a warning.
• Opcache is always built into PHP. A leftover zend_extension=opcache.so line in php.ini now produces a warning, so clean up server config.
• The disable_classes INI setting has been removed. If your hardening relied on it, review that with your host.

A safe order of work

1. Audit Composer dependencies on a branch with composer why-not php 8.5.0, and list every blocker.
2. Build a PHP 8.5 staging server that matches Adobe's requirements for 2.4.9, including Valkey 9, OpenSearch 3 and a supported database.
3. Update or replace blocking packages, then run the Magento upgrade and a full compile.
4. Turn up error reporting in developer mode, click through the store and Admin, and read the logs.
5. Run automated tests and test imports, exports, payments and integrations by hand.
6. Fix, retest and deploy together with the 2.4.9 upgrade.

FAQ

What PHP version does Magento 2.4.9 need?

PHP 8.5. Adobe's release notes allow PHP 8.4 only for upgrade purposes, not for production.

Can I move to PHP 8.5 without upgrading Magento?

No. Adobe lists PHP 8.5 only for 2.4.9. Earlier lines are not supported on PHP 8.5, so the PHP move and the Magento upgrade happen together.

Will PHP 8.5 make my store faster?

Newer PHP versions often bring performance improvements, but the effect on a real store depends on your code, caching and hosting. Measure before and after rather than assuming a gain.

Getting help with PHP 8.5

Most PHP 8.5 work is finding and fixing problems in extensions and custom modules. Mistri's Magento upgrade services cover the full upgrade, and our Magento extension development team can rebuild or replace modules that no longer have a maintained version.

Sources

System requirements (Adobe Experience League); Adobe Commerce 2.4.9 release notes (Adobe Experience League); Deprecated features in PHP 8.5 (php.net); Backward incompatible changes in PHP 8.5 (php.net); Supported PHP versions (php.net).