Upgrading to Magento 2.4.9: system requirements and a step-by-step checklist

Magento Open Source and Adobe Commerce 2.4.9 were released on 12 May 2026. It is a larger step than most minor releases: it drops PHP 8.2 and 8.3, moves the cache layer to Symfony Cache, replaces Laminas MVC with a native implementation, switches the cache and session tooling from Redis to Valkey and swaps the TinyMCE editor for HugeRTE. Stores that skip the preparation work tend to find out about these changes in production.

At the same time, support deadlines are moving. Standard support for the 2.4.6 line ended on 11 August 2026, and Adobe's lifecycle policy now ends standard support for 2.4.7 on 31 May 2027. If you run anything older than 2.4.8, an upgrade plan is overdue.

This guide collects what changed, the exact service versions Adobe has tested, the support dates and a step-by-step checklist based on Adobe's Composer upgrade procedure. All facts come from Adobe's Experience League pages as published in October 2026.

Which version should you target?

Adobe's released-versions page lists the current patch for each supported line. All of them were released on 12 May 2026.

Extended support applies to Adobe Commerce customers and includes quality and security patches for the core application. Lines 2.4.4 and 2.4.5 are in a one-time "security-only transitional period" that ends on 31 May 2027. Adobe says not to treat it as a support tier but as migration time.

For most stores the target is 2.4.9: it has the longest support window and is the only line tested with PHP 8.5. Choose 2.4.8-p5 if a critical extension does not yet support 2.4.9, and plan the next step.

Tested system requirements

Adobe supports only the combinations listed in its system requirements tables, and its support team may ask you to align your environment before investigating an issue. These are the on-premises requirements for the three newest lines (page updated 18 September 2026):

Two rows deserve attention. First, the 2.4.7-p10 column lists MySQL as not supported, and Redis no longer appears for the latest patches of 2.4.4 to 2.4.7; Valkey takes its place. Second, Adobe's own example is explicit: 2.4.9 is tested with MariaDB 12.3, so upgrade MariaDB before you upgrade the application. Note also that the 2.4.9 release notes allow PHP 8.4 "for upgrade purposes only (not recommended for production)", so you can step through 8.4 but should finish on 8.5.

What changed in 2.4.9 that can break a store

Adobe's 2.4.9 release notes describe 580 fixed issues in the Open Source core and a long list of platform updates. These are the ones most likely to affect custom code and extensions:

• PHP 8.5 only for production. PHP 8.2 and 8.3 are no longer supported. Check every extension's PHP constraint in composer.json.
• Symfony Cache replaces Zend_Cache. Adobe says existing cache backends and commands keep working, but code that called Zend_Cache classes directly must be updated.
• Native MVC replaces Laminas MVC. Extensions that depend on Laminas MVC classes need a compatible release.
• Symfony 7.4 LTS. Custom classes that extend Symfony classes, such as console commands, must match the newer type declarations and method signatures.
• Valkey replaces Redis in CLI tooling. setup:config:set now uses --cache-backend=valkey, --page-cache=valkey and --session-save=valkey.
• HugeRTE replaces TinyMCE as the WYSIWYG editor, because of TinyMCE 5 and 6 end of support and licensing issues with TinyMCE 7. Extensions that add TinyMCE plugins need attention.
• PHPUnit 12 is now the test framework dependency, which affects your own unit tests.
• Message queues. RabbitMQ 4.2 support was added as a short-term path; Adobe recommends Apache ActiveMQ Artemis (over STOMP) as the long-term broker.
• Admin 2FA. Admin users now need to configure only one of the enabled two-factor providers rather than all of them.

Before the upgrade: the preparation checklist

1. Inventory your extensions. List every package in composer.json and every module in app/code. For each, record whether the vendor has published a 2.4.9-compatible release.
2. Upgrade services first. Bring PHP, MariaDB or MySQL, OpenSearch, Valkey and Varnish to the versions in the table, in a staging copy of production.
3. Move cache and sessions to Valkey if you still run Redis, and update app/etc/env.php.
4. Update Composer to 2.10 and install the current magento/composer-root-update-plugin, which Adobe's upgrade prerequisites require for the require-commerce command.
5. Take backups of the database, app/etc/env.php, composer.json, composer.lock and media.
6. Run your tests on PHP 8.5 against the current version to separate PHP issues from Magento issues.
7. Plan the maintenance window and tell customer service. On Adobe Commerce on cloud infrastructure, read the Cloud upgrade guide instead of this procedure.

Running the upgrade with Composer

Adobe's upgrade procedure applies to installations created with composer create-project or from an archive. Do not use it on a Git clone of the repository. First, confirm which versions Composer can see:

composer show magento/product-community-edition 2.4.* --available | grep -m 1 versions

Enable maintenance mode, stop cron and drain the message queues. Adobe warns that starting an upgrade while asynchronous processes such as queue consumers are running may corrupt data. Run the consumers once by hand, and repeat the ps check until no queue processes remain. Then back up composer.json.

bin/magento maintenance:enable
bin/magento cron:remove
bin/magento cron:run --group=consumers
ps aux | grep 'bin/magento queue'
cp composer.json composer.json.bak

Require the new version without updating yet, then update dependencies. --interactive-root-conflicts lets you review values in your root composer.json that differ from the new release; --force-root-updates overwrites them with Adobe's values.

# Magento Open Source
composer require-commerce magento/product-community-edition 2.4.9 --no-update
# Adobe Commerce
composer require-commerce magento/product-enterprise-edition 2.4.9 --no-update

composer update

Clear generated files and caches, then upgrade the database schema and data. If your cache is in Valkey, flush it there too, because removing var/cache only clears the file cache. In production mode, compile and deploy static content before leaving maintenance mode, then reinstall the crontab you removed earlier.

rm -rf var/cache/* var/page_cache/* generated/code/*
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
bin/magento maintenance:disable
bin/magento cron:install

If you use Varnish, restart it as Adobe's guide suggests, then open the storefront and the Admin. If the application shows an error page, Adobe's guide recommends resetting file system ownership and permissions and clearing var/cache, var/page_cache and generated/code again.

After the upgrade: verification

• Run bin/magento indexer:status and make sure no indexer is stuck as invalid.
• Check var/log/exception.log and var/log/cron.log for new errors.
• Place test orders with each payment and shipping method.
• Edit a CMS page and a product description to confirm the HugeRTE editor works with your content.
• Sign in to the Admin with two-factor authentication.
• Compare response times and error rates with the week before the upgrade.

Testing strategy and timeline

A realistic upgrade has three phases, and skipping any of them is where most failed upgrades come from.

1. Compatibility phase. On a developer machine or a disposable environment, run the Composer upgrade against a copy of your codebase. Composer will refuse to resolve dependencies when an extension pins an older PHP or framework version, and that list becomes your work queue. Contact each extension vendor early: some will need weeks to publish a 2.4.9 release.
2. Staging phase. Restore a recent, anonymised copy of the production database into staging, run the full upgrade and let cron run for at least a day. Test checkout, refunds, imports, exports, every integration (ERP, payment, shipping, email) and your Admin workflows. Time the setup:upgrade step, because that is the minimum length of your production maintenance window.
3. Production phase. Repeat the exact commands from staging, in the same order, ideally from a script kept in version control. Keep the backups and the previous code release ready so you can roll back if a blocking issue appears.

Write down the PHP, database, search, cache and queue versions for each environment in a simple table. Mismatched service versions between staging and production are a common reason why an upgrade that passed every test still fails on the night.

Summary

Upgrading to 2.4.9 gives you support until 31 May 2029, PHP 8.5 and a modernised framework, but it changes enough of the stack that extensions and services must be ready first. Upgrade PHP, the database, OpenSearch and Valkey in staging, confirm every extension, then follow Adobe's Composer procedure with maintenance mode, drained queues and a clean setup:upgrade. Keep the support table above in your planning documents: the 2.4.7 standard support deadline of 31 May 2027 is closer than it looks.