PHP compatibility is two questions, not one
Most teams treat PHP compatibility as a single check: does Magento support this version? That is only half the question.
The other half is whether every third-party extension on the store supports it too. A platform can run happily on PHP 8.3 while one extension quietly fatals on a specific code path.
This article covers what each Magento 2.4.x version actually supports, how extension gaps hide, and how to check both before an upgrade turns into an incident.
What each 2.4.x version actually supports
Adobe pins each Magento minor version to a specific PHP range. Running outside that range is unsupported, whether or not it appears to work:
- 2.4.4 and 2.4.5 run on PHP 8.1.
- 2.4.6 adds PHP 8.2, alongside 8.1.
- 2.4.7 supports PHP 8.2 and 8.3, and drops 8.1.
- 2.4.8 supports PHP 8.3 and 8.4.
Confirm what the store runs with php -v on the CLI and the web SAPI, since those two are not always the same version. Match them to the range for your exact Magento version before anything else.
A mismatch between those two is its own source of upgrade surprises. A fix verified on the CLI can still fail on the storefront when the web server runs a different PHP than your terminal does.
The extension gap
An extension declares the PHP versions it supports in its composer.json, through a constraint like "php": "~8.1.0". When that constraint does not include the version you are moving to, Composer will refuse the upgrade, or the extension will run untested on a PHP it was never built for.
This is where inherited stores get stuck. One old extension with a narrow PHP constraint can hold the entire platform on a version Adobe no longer supports.
Deprecations that do not fatal, but flood the logs
Not every incompatibility is a hard crash. PHP 8 deprecated several patterns that older extension code relies on, and the store keeps running while writing a warning every time it hits one.
The common ones are dynamic property creation, deprecated in 8.2, along with the long-removed each() function and curly-brace array access. Code using them may work, but it fills system.log with deprecation notices on every request.
That noise is a problem of its own. It grows the logs, hides real errors underneath, and signals code that will eventually break when the next PHP version removes the pattern entirely.
How to check compatibility before upgrading
You do not have to upgrade and hope. Composer can tell you in advance which packages conflict with a target PHP version:
composer prohibits php 8.3The output lists every installed package whose constraints exclude PHP 8.3. That list is your gap, and it is far cheaper to read now than to discover mid-deploy.
For code that runs but is not clean, a static scan with the PHPCompatibility ruleset for PHPCS flags deprecated and removed syntax across custom modules and extensions. It catches the problems that constraints alone do not describe.
Why "it runs" is not "it is supported"
An extension often runs on a PHP version its composer.json never claimed. Composer only enforces constraints during install, so code copied straight into app/code, or installed with --ignore-platform-reqs, runs on whatever PHP is present.
Running is not the same as being supported. The extension may work for months and then fail on the one code path that uses a removed function, at which point there is no vendor release to fall back on.
This is why the constraint check and the static scan matter together. One tells you what the vendor promised, the other tells you what the code actually does on your PHP version.
What to do with an incompatible extension
An extension that blocks your PHP target has a short list of outcomes. Update it if the vendor shipped a compatible release, replace it if they did not, or isolate and remove it if the feature is no longer worth the drag.
The one option that is not real is leaving it in place and upgrading anyway. That trades a visible blocker now for an intermittent failure later, on a code path nobody remembers.
Whichever path you take, resolve it before the platform upgrade, not during. Fixing an extension gap under deploy pressure, with the store half-migrated, is how a planned upgrade becomes an emergency rollback.
Alignment is the foundation
PHP and extension alignment is not glamorous work, but almost every other upgrade depends on it. You cannot move Magento versions, apply current security patches, or trust a staging test while the runtime underneath is unsupported.
Knowing exactly where your PHP version and your extensions disagree is the first fact any upgrade plan needs. It is also one of the fastest checks a structured review can give you a clear answer on.