Skip to main content
MagentoSeptember 28, 20269 min read

How to Upgrade Magento 2.4.8 to 2.4.9 and What Changes

Get technical support

We measure your store before touching it

Magento 2.4.9 needs PHP 8.5, OpenSearch 3 and, for MariaDB users, version 12.3, and Adobe's own pages disagree on four of its requirements. This covers the upgrade order that 2.4.8-p5 makes possible, the commands Adobe documents, the library changes that break extensions, and the security patches a fresh 2.4.9 install still lacks.

Magento Open Source and Adobe Commerce 2.4.9 became generally available on May 12, 2026. Adobe supports it until May 31, 2029, a year longer than 2.4.8, whose standard support ends on May 31, 2028. Nothing forces the move this month, but the upgrade is bigger than the version number suggests. It moves the platform to PHP 8.5, lists OpenSearch 3 as the only search engine, asks MariaDB users for 12.3, and replaces several libraries that extensions are built on.

What follows is an order that keeps every step small, the commands Adobe documents, the changes people notice after the upgrade, and the security patches a fresh 2.4.9 install still needs.

What 2.4.9 Requires

Adobe's system requirements page, last updated on September 18, 2026, lists these versions for on-premises installations:

Dependency2.4.8 at release2.4.8-p52.4.9
PHP8.4, 8.38.4, 8.38.5
Composer2.9.3+2.102.10
MySQL8.48.48.4
MariaDB11.411.4, 11.812.3
OpenSearch2.1933
Elasticsearch8.178not listed
RabbitMQ4.14.34.3
ActiveMQ Artemisnot listed22
Valkey88.19
Varnish7.688
nginx1.261.301.30

Redis does not appear in any of the three columns. Valkey does, and 2.4.9 adds a dedicated setting for it, bin/magento setup:config:set --cache-backend=valkey.

The middle column is the useful one. 2.4.8-p5, the latest 2.4.8 security release, already runs on the same Composer, MySQL, OpenSearch, RabbitMQ, ActiveMQ Artemis, Varnish and nginx versions as 2.4.9. Most services can therefore move while the code is still on 2.4.8, one at a time, which leaves only PHP, MariaDB and Valkey for the upgrade itself.

Where Adobe's Own Pages Disagree

Four requirements read differently depending on which Adobe page you open.

  • PHP. The requirements table lists only PHP 8.5. The release notes say PHP 8.4 is allowed for upgrade purposes only and is not recommended for production, and that PHP 8.2 and 8.3 are no longer supported. Magento's own composer.json at the 2.4.9 tag still accepts ~8.3.0||~8.4.0||~8.5.0, so Composer will install 2.4.9 on PHP 8.3 without a word. A clean composer update is not proof that your PHP version is supported.
  • Composer. The table says 2.10. The release notes describe 2.4.9 as compatible with Composer 2.x, including 2.9.
  • RabbitMQ. The release notes add support for RabbitMQ 4.2 and call it a short-term path, while the table lists 4.3. For the long term Adobe recommends Apache ActiveMQ Artemis, which it supports on every release line from 2.4.6 to 2.4.9.
  • Elasticsearch. The upgrade prerequisites page says 2.4.8 and later no longer support Elasticsearch. The OpenSearch migration page says on-premises installations continue to support it. The 2.4.8-p5 column still lists Elasticsearch 8, the 2.4.9 column does not, and 2.4.9 still ships an Elasticsearch 8 module.

This guide follows the requirements table, the most recently updated of these four pages, and plans on OpenSearch 3.

The Order That Keeps Each Step Small

  1. Get to 2.4.8-p5 first, together with the monthly isolated security patches released since. Adobe tests isolated patches only against the latest -p release, so this is also where you need to be to stay patched until the upgrade is done.
  2. Move the services both versions list. OpenSearch 3, Composer 2.10, RabbitMQ 4.3 or ActiveMQ Artemis 2, Varnish 8 and nginx 1.30 are supported on 2.4.8-p5 and on 2.4.9. If you still run Elasticsearch, switch to OpenSearch now and reindex while nothing else is changing.
  3. Switch PHP to 8.4. 2.4.8-p5 supports it, and it is the version Adobe allows for the upgrade itself.
  4. Handle the database. Adobe's requirements page tells MariaDB users to upgrade to 12.3 before upgrading to 2.4.9, yet the 2.4.8-p5 column lists only 11.4 and 11.8, so for a short while you run a combination the table does not cover. Rehearse that step on staging with a full checkout test. MySQL needs nothing, because both versions require 8.4. If your MySQL is still 8.0 on Amazon RDS, move it to 8.4 with a blue/green switch before anything else.
  5. Upgrade the code with the commands below.
  6. Move PHP to 8.5 and Valkey to 9, the two versions that only the 2.4.9 column lists.

Check Extensions Against the Libraries That Changed

Upgrades usually break in extensions rather than in Magento itself, and 2.4.9 changes more of the ground they stand on than a typical minor release. From the release notes and Adobe's list of backward-incompatible changes:

  • Laminas MVC is removed and replaced by a native MVC implementation.
  • The deprecated Zend_Cache component is replaced by Symfony Cache. Extensions that depend on Zend_Cache classes or interfaces have to move to the Symfony cache APIs.
  • Symfony moves to 7.4 LTS, so custom classes that extend Symfony classes need matching type declarations and method signatures.
  • The WYSIWYG editor moves from TinyMCE to HugeRTE, because TinyMCE 5 and 6 reached end of support and the license of TinyMCE 7 is incompatible.
  • web-token/jwt-framework moves from version 3 to 4, a third-party OAuth library is replaced with native PHP code, and PHPUnit moves to 12.

One change appears in neither document. Magento 2.4.8 installs magento/magento-zf-db, which provides the Laminas\Db namespace. 2.4.9 no longer installs it and pulls in php-db/phpdb instead, which uses the PhpDb namespace and declares a conflict with laminas/laminas-db. An extension that requires laminas/laminas-db will stop composer update, and one that uses Laminas\Db classes without declaring them will fail when that code runs. The older Zend_Db classes that Magento's own MySQL adapter extends are still installed.

A few searches before the upgrade show how exposed your own code and third-party modules are:

# run from the Magento root while still on 2.4.8
grep -rlE 'Laminas\\(Mvc|Db)|Zend_Cache' app/code app/design
grep -rliE 'tinymce' app/code app/design
grep -rlE 'Laminas\\(Mvc|Db)|Zend_Cache' vendor --include=*.php | grep -vE '^vendor/(magento|laminas)/'
grep -lE 'laminas/laminas-db|magento/magento-zf-db' vendor/*/*/composer.json | grep -vE '^vendor/(magento|laminas)/'

Every file those commands list is a question for the extension's vendor or your developer, and it is far cheaper to ask it before the upgrade than after. Adobe Commerce licensees can also run Adobe's Upgrade Compatibility Tool, which is not offered for Magento Open Source.

Run the Upgrade

These are Adobe's steps for an on-premises Composer installation, with the build steps from its deployment guide placed where they belong. Take a real backup first. The built-in backup commands are deprecated, and Adobe points to binary backup tools such as Percona XtraBackup instead.

# once, if the plugin is not installed yet
composer require magento/composer-root-update-plugin ~2.0 --no-update
composer update

bin/magento maintenance:enable

# stop cron so no queue consumer runs during the upgrade
bin/magento cron:remove
# let the consumers work through what is already queued
bin/magento cron:run --group=consumers
# repeat until no 'bin/magento queue' process is left
ps aux | grep 'bin/magento queue'

cp composer.json composer.json.bak
# Adobe Commerce uses magento/product-enterprise-edition here
composer require-commerce magento/product-community-edition 2.4.9 --no-update
composer update

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

# Adobe's upgrade page ends before this, so put cron back yourself
bin/magento cron:install

The cron step is not optional. Adobe warns that starting the upgrade while asynchronous processes such as message queue consumers are running may corrupt data, which is why cron comes out before Composer runs.

What Changes for the Store

Most of the release is invisible, fixes to 666 issues in the core code. A few changes reach people directly.

  • Headless storefronts and integrations. GraphQL now rejects, by default, requests with more than 10 aliases and queries longer than 1,048,576 characters. Both limits can be raised, and the alias limit sits under Stores > Configuration > Services > Magento Web API > GraphQL Input Limits. Run your PWA or mobile app against staging before you switch.
  • CAPTCHA on the API. When CAPTCHA or reCAPTCHA is enabled for the Create Account form, creating an account through REST or GraphQL now has to pass the same check. reCAPTCHA also covers the applyCouponsToCart, updateCustomer, updateCustomerV2 and contactUs mutations when it is enabled for the matching storefront forms. An app that creates accounts or applies coupons through the API has to send a token.
  • Admin sign-in. Admin users now configure only one of the store's enabled two-factor providers, and a new setting, admin/security/minimum_password_length, enforces a minimum length for admin passwords.
  • Content editors get HugeRTE in place of TinyMCE. Check any custom editor plugins on staging.
  • Carts at sign-in. A new Cart Merge Preference under Stores > Configuration > Sales > Checkout decides how a guest cart combines with a customer's saved cart. The default, Merge Quantities, adds the two together.

A Fresh 2.4.9 Is Not a Patched 2.4.9

The 2.4.9 package that Composer installs is the May release, and Adobe has changed how it ships security fixes since then. Between the -p releases it now publishes monthly isolated patch files, with no Composer packages alongside them. Each one builds on the ones before it, so they are applied in release order, and only on top of the latest -p release for your line. Security bulletins now describe the fixed state with a date, such as 2.4.9-2026-aug.

For a store upgrading now, that means the isolated patches from July onwards, applied in order, plus the hotfix for CVE-2026-75650 from bulletin APSB26-146. Adobe says that vulnerability has been exploited in the wild, lists 2.4.9-2026-aug and earlier as affected, and requires rotating the encryption keys as well as applying the patch. We walked through that hotfix and the key rotation when it came out.

On a Composer installation an isolated patch is applied from the Magento root with patch -p1 < file.patch, followed by a cache refresh. Each monthly patch also carries Adobe's Commerce Version Tool, which reports which patches are in place.

An upgrade changes the search engine, the cache backend and PHP underneath the store, which makes the week after it a good time to measure speed again. Magento 2 Speed Optimization starts with exactly that kind of audit.

Or read how we handle it in Magento 2 Speed Optimization.