Magento 2.4.9: What’s New and What Your Store Needs to Do Before May

12 May 2026 – Magento 2.4.9 released. This is not your typical security patch. This is the most significant architectural update to the Magento core since version 2.4.4 and for store owners there are three aspects that matter most right now:

1. If you are using Magento 2.4.6 your support ends on 11 August 2026. That’s 3 months out.
2. If you are using Magento 2.4.4 or 2.4.5 you are already passed end of life and running without security patches.
3. With Magento 2.4.9 there are breaking framework changes, so this is not a quick upgrade and needs some preparation.

This manual will walk you through what’s changed in the latest version of Magento, why it matters, and what your store really should do about it.

Before we go into what 2.4.9 offers, it’s important mapping out where we’re at in the version calendar.

Magento 2.4.8-p4 (released 10 March 2026) is the current recommended production version. It runs on PHP 8.3 or 8.4, supports MariaDB 11.4 and MySQL 8.4, uses OpenSearch 2.19, and carries support through April 2028. If your store is on 2.4.8 and up to date on patches, you are in good shape and there is no urgency to rush onto 2.4.9 on day one. For a breakdown of earlier Magento releases and version history, you can review the details here: Magento 2.4.8 Release Guide

Magento 2.4.7 is supported but is end of life in April 2027. 2.4.7 Stores are to plan to upgrade to 2.4.8 or 2.4.9 in 2026.

Magento 2.4.6 End of Life date is 11 August 2026. Adobe will not be releasing any security patches after that date. Stores still on 2.4.6 beyond August will be running known unpatched vulnerabilities. If your store is on 2.4.6, you need to upgrade.

Magento 2.4.5 and 2.4.4 are already EOL. If your store is on either of these versions this is urgent and has to be addressed now.

One of the most useful improvements coming in 2026 isn’t a version number at all — it’s how Adobe rolls out patches.

Starting January 2026, Adobe switched to monthly standalone security patches.  Gone are the days of the previous quarterly cycle, where you’d have to wait up to three months for a key security fix to be packaged into the next patch. Security vulnerabilities are now patched when needed each month with two larger aggregated patch bundles each year in May and November.

For shop owners this means two things:

First, the essential security exposure windows are reduced. A vulnerability found in March no longer has to wait until June to be fixed.

Secondly, patch management becomes a monthly discipline rather than a quarterly event. If you’re doing your own fixes, or you’re relying on a developer to do them reactively, that tempo has shifted. Stores who treat security patching as a quarterly duty are no longer meeting Adobe’s suggested standards.

We presently do patch cycles for 100+ real Magento stores on retainer. We’ve already included the change to monthly isolated patches into our maintenance process, but if you don’t have that type of constant oversight in place, now is the time to do so.

Magento 2.4.9 is mostly an infrastructure release. There are only small visible frontend modifications. The technical underpinning the platform runs on has changed, and some of those changes are severe enough to impact extensions, custom modules and hosting configurations.

Three Framework Components Replaced

The main change in 2.4.9 is the removal of three essential framework components that have been around since the early days of Magento 2.x:

Laminas MVC replaced with native PHP MVC. Native PHP MVC replaces Laminas MVC Magento 2 was developed on Zend Framework which became Laminas. Adobe has been dropping Laminas requirements across the 2.4.x line for a few releases. In 2.4.9 the MVC layer itself has been replaced for native PHP. Any extension that directly extends Laminas controllers, routers or request handlers will break on 2.4.9 without an upgrade.

HugeRTE is a replacement for TinyMCE. The WYSIWYG editor used in the admin interface for product descriptions and CMS content blocks has been updated. Support for TinyMCE versions 5 and 6 was discontinued and the license changed in TinyMCE 7, making it incompatible with Magento’s open-source license. HugeRTE is replacement open source and actively maintained. The basic editor functionality is still there, but extensions that alter TinyMCE’s toolbar or that rely on its JavaScript API will need to be looked at.

Replaced Zend_Cache with Symfony Cache – Replaced the legacy caching layer with Symfony Cache. Adobe says it speeds up cache operations from 30% to 50% and reduces the stress on the Redis (or Valkey) backend. Extensions directly hooking into Zend_Cache classes will need to be updated.

These three features together are why Magento 2.4.9 is not just another version bump. They are foundational things and they impact the extension ecology.

PHP 8.5 Support and Things Being Dropped

Magento 2.4.9 is the first release with day-one support for PHP 8.5. PHP 8.4 remains the recommended production version. PHP 8.3 is only supported for upgrade reasons. PHP 8.2 is completely unsupported.

You must upgrade to PHP before you can upgrade to 2.4.9 if your store is on PHP 8.2.

PHP 8.5 brings major performance improvements. Now, if you upgrade to PHP 8.5 with PHP 8.5, then you will experience real speed increases, not marginal ones.

Database Requirements Change

Magento 2.4.9 removes support for MySQL 8.0 and MariaDB 10.6. The updated minimum requirements are MySQL 8.4 LTS or MariaDB 11.4.

Timing is important here. MySQL 8.0 end of life was April 2026, two weeks before 2.4.9 GA. Stores still utilising MySQL 8.0 are unsupported databases and must migrate irrespective of their Magento version.

Upgrading MySQL or MariaDB is not a trivial matter. This also means evaluating the schema compatibility, checking the stored procedures and confirming the replication setups if your solution includes database replication. This is work that has to be done in a staging environment before impacting production.

OpenSearch Replaces Elasticsearch Entirely

If you still use Elasticsearch for your store, Magento 2.4.9 completes the loss of Elasticsearch support that started in earlier releases. OpenSearch 3.x is now the default search engine for 2.4.9. OpenSearch 2.19 continues to be supported on 2.4.8.

OpenSearch 3.x has modifications to the index format from 2.x. Stores with vast product catalogues may need to budget for reindexing time as part of the upgrade.

Valkey Replaces Redis as the Default Cache Backend

In 2024, Redis modified its open source license, creating Valkey – a community fork of Redis maintained under an open-source license. Valkey was introduced in Adobe 2.4.8, and is the preferred default as of 2.4.9. Valkey 8 is wire-compatible with Redis therefore the switch is operationally simple for most stores. While Redis 7.2 may still operate, it is not listed in Adobe’s official system requirements for 2.4.9.

This implies your hosting provider has to support Valkey 8 for store owners to upgrade to 2.4.9. Valkey has already been migrated or is being migrated to by several managed Magento hosting setups.

Magento 2.4.9 includes multiple significant security improvements, in addition to the March 2026 patch bundle:

API CAPTCHA enforcement: With CAPTCHA enabled for the client registration form, account creation requests via REST and GraphQL are now protected with the same protection. This addresses a loophole that allowed bots to create accounts via API without invoking CAPTCHA.

Enhanced JWT token authentication: The security of the JSON Web Token mechanism used for API integrations has been improved.

Native OAuth: Replaced the third-party OAuth library with native PHP OAuth routines, removing a dependency and decreasing the attack surface.

USPS shipment switch: The USPS integration has been upgraded from the legacy XML API to the new RESTful API with OAuth 2.0 authorisation. The legacy USPS API will be decommissioned on January 25, 2026. This upgrade is needed for stores using USPS shipping on older versions of Magento.

Bug Fixes: 500+
Magento 2.4.9 provides over 500 fixes, while Adobe Commerce includes over 560 fixes in Magento 2.4.9. Notable changes are: Bulk operations (large catalogue updates, inventory syncs) are now faster API errors now return proper error codes instead of generic crashes It is no longer possible to create orders via API without a billing address (this used to cause admin dashboard crashes) Multiselect product attribute updates via REST API no longer overwrite store-specific labels

Magento 2.4.9 introduces additional Braintree payment features:

• Braintree promo codes now support checkout flows for Google Pay and Apple Pay
• We have expanded our local payment method support to specific markets

If you use Braintree to accept payments in your store, make sure you try these out in staging before upgrading.

This is the question that most store owners really want addressed. The honest answer is contingent upon your scenario.

If you are on Magento 2.4.8: Stick with 2.4.8 for now. 2.4.9-p1 to be released in about 30 to 45 days after the GA release of May 12. It’s the first patch after a big release where extension providers catch up. It’s the time where the early-adoption edge cases get fixed. 2.4.8 is supported till April 2028 No security urgency to move on day one

If you’re using Magento 2.4.7, plan an update to 2.4.8 in 2026. You can go straight from 2.4.7 to 2.4.9 once it is stable. But the safer route is 2.4.8 first then 2.4.9 once you checked that extensions are working with framework changes in 2.4.9.

If you are using Magento 2.4.6: You have until 11 August 2026. You’ve got a hard deadline. Instead of trying to go right to 2.4.9, upgrade to 2.4.8 now while it is still an early release. The upgrade from 2.4.6 to 2.4.8 is fully tested and suppliers have had time to test their extensions.

If you are on Magento 2.4.5 or 2.4.4: You are already past end of life. If you don’t upgrade every day, then every day your store is running without security fixes. The need for an upgrade is urgent.

If you are on Magento 1: Magento 1 hit end of life in June 2020. If you’re still on Magento 1, you’re exposing yourself to some pretty major security risks and you need to get a migration plan in place, yesterday.

So here’s a candid evaluation of the amount of work necessary for stores who want to switch to 2.4.9 once things settles down.

Audit Extension: All extensions that make direct use of Laminas MVC, TinyMCE JavaScript APIs or Zend_Cache classes need to be checked for compatibility. Talk to your extension vendors immediately and ask them when they expect to be compatible with 2.4.9. Don’t wait until after the GA. Most suppliers will disclose compatibility information in the weeks after the May 12 release.

PHP upgrade: If your store is running PHP 8.2, you need to upgrade to PHP 8.3, 8.4 or 8.5 before updating Magento. This is a server change that must be coordinated with your hosting provider.

Upgrading database: If your store is on MySQL 8.0 or MariaDB 10.6, you’ll need to upgrade to MySQL 8.4 LTS or MariaDB 11.4. This is not a modification to settings. This is a migration of the database itself, which requires proper staging, testing and rollback strategy.

OpenSearch upgrade: OpenSearch 2.x stores need to be migrated to OpenSearch 3.x to align with 2.4.9. If you have vast catalogues, allow for the time it takes to re-index.

The upgrade command has been altered: In 2.4.9, the Composer command changes from composer require magento/… to composer require-commerce magento/…. Older upgrade scripts should be modified accordingly.

Test in staging environment: 2.4.9 has significant modifications to the framework, and testing on staging (which is a copy of production) is not an option. If you have bespoke modules, plan for 7 to 14 days of staging testing and start your developers running the beta in staging now.

With Magento 2.4.9 you should understand that Adobe is systematically modernising the technical basis of the platform. We aren’t adding features by removing Laminas, replacing Zend_Cache with Symfony Cache, or moving to native PHP MVC. We are reducing debt and future-proofing the platform from PHP version changes for years to come.

Alongside version 2.4.9, Adobe has been constructing Adobe Commerce as a Cloud Service (ACCS), a multi-tenant SaaS version of Commerce that released in June 2025. ACCS is Adobe’s vision for managed infrastructure for enterprise eCommerce, faster feature delivery and decreased operational cost for major retailers. It’s not the ideal match for every organization (deep customisation is limited by the SaaS model) but it’s the direction Adobe is investing most significantly in.

For the majority of UK shops running Magento Open Source or on-premises Adobe Commerce, the 2.4.x LTS line remains the ideal platform. The framework update in 2.4.9 ensures Magento 2.4.x will be a credible choice until 2028 and beyond.

Our recommendation is simple, we are an Adobe Commerce Certified agency supporting 100+ real Magento stores.

See what version you are on now. If you are on 2.4.6 or earlier you need a plan now for your upgrade timeline, it is urgent. If you are on 2.4.7, expect 2.4.8 this year. If you’re on 2.4.8 then you’re in good shape focus on extension compatibility testing against 2.4.9 beta in staging.

Don’t update production stores to 2.4.9-GA on day one. Wait for 2.4.9-p1 (June 2026), check your extensions for compatibility, and schedule your update for the June-September 2026 window.

Think of the new monthly patch frequency as a process shift. If you don’t have a monthly patch review as part of your existing maintenance, time for an update. The monthly cycle of patches means a Magento store running on an outdated security patch is becoming an increasing liability.

Have your hosting stack evaluated. No matter what Magento version you’re on, any updates to your infrastructure are required if your store is running on PHP 8.2, MySQL 8.0, or MariaDB 10.6.

If you need an evaluation of where your store is at the moment and what your upgrade path should be, our professional experts can perform a Magento audit and provide you with a clear, honest suggestion. We’ve done this on 250+ Magento sites and the complexity of update varies a lot based on how your shop has been created and what extensions are in play.