Magento 2.4.9 GA is out, and it is the biggest framework jump the platform has shipped since 2.0. Laminas MVC is gone, Zend_Cache is gone, TinyMCE is gone, PHP 8.2 is gone. For studios running production Hyvä stores, this is the upgrade quarter you cannot quietly defer to next year.
What changed
Adobe Commerce 2.4.9 and Magento Open Source 2.4.9 reached general availability in May 2026. The Adobe Commerce release notes count 666 fixes in the Commerce core and the Open Source notes count 580 in the OSS core. The headline is the framework modernisation. Symfony 7.4 LTS is now an official target. Laminas MVC has been replaced by a native implementation. Zend_Cache is out, Symfony Cache is in. TinyMCE is out, HugeRTE is in. The third-party OAuth library got swapped for native PHP functions. JWT was upgraded across the stack.
The runtime surface moved too. PHP 8.5 and 8.4 are the supported versions. PHP 8.3 is allowed only for upgrade flows and not recommended for production. PHP 8.2 support is removed outright. On the data side, MariaDB 11.8 and 12.x are now supported, MySQL 8.0 and MariaDB 10.6 are off the matrix. OpenSearch 3.x is fully compatible, Valkey 9.x lands as a Redis alternative, and RabbitMQ 4.2 is short-term compatible with Apache ActiveMQ Artemis as the long-term direction.
On the surface that merchants actually touch, the wins are smaller
and concrete. The clearCart and clearWishlist
GraphQL mutations finally exist. Product gallery inheritance is
configurable per store view via REST. Apple Pay now works on Chrome
and Firefox via Braintree. Google Pay vaulting lives in the account
area. BLIK for Polish customers, ELO for Brazilian cards, Pay Upon
Invoice for German buyers. The "Product was viewed" customer segment
is officially deprecated for being a database hot path.
Why it matters for premium studios in Asia
Magento upgrades have been the silent killer of agency margins for a decade. A new minor release lands, the merchant defers it, then twelve months later it is suddenly a six-figure migration because three major dependencies are unsupported and half the third-party modules have not tracked the framework changes. The 2.4.9 jump is the kind of release that punishes studios who skipped the planning step.
Laminas MVC removal is the load-bearing change. Any custom module that subclassed or proxied a Laminas controller is going to need rework. Most legacy modules from the early 2.x era touched Laminas somewhere. So did half the payment integrations written before 2022. The native MVC replacement is leaner and faster, but it does not pretend to be drop-in compatible.
TinyMCE to HugeRTE is the second one to plan around. Every store that hooked custom plugins into the WYSIWYG, or that ships content-heavy CMS pages styled through admin, needs to verify HugeRTE renders the same output. The two editors share a common ancestor, but their plugin APIs diverge enough that a quick smoke test does not cover it. On content-heavy stores where editorial copy runs through the Magento WYSIWYG into Hyvä templates, this is the kind of change we audit by diffing rendered HTML before and after, not by clicking through the admin.
The PHP 8.2 removal hurts shops that are still on PHP 8.1 or 8.2 in production. It is one thing to bump PHP in a dev container. It is another to confirm every third-party module, every patched core class, every CI pipeline and every server image carries 8.5. The realistic minimum path is two engineering sprints with a parallel staging environment and full regression coverage.
What we would actually change this quarter
For merchants on Magento Open Source or Adobe Commerce, three concrete moves.
First, freeze the module inventory now. List every third-party module installed, every custom module, every patched core class. For each, mark its 2.4.9 readiness. The honest version of this list is usually 60 to 80 percent green, 15 to 30 percent yellow, and the remaining red items are the project. Without the inventory, the budget conversation is a guess.
Second, plan the database side independently from the application side. Dropping MySQL 8.0 and MariaDB 10.6 forces an infrastructure decision that has nothing to do with Magento itself. If you are running managed MySQL on a cloud provider that still defaults to 8.0, you need either a version bump or a migration to MariaDB 11.8. Valkey as a Redis alternative is worth exploring for any merchant whose Redis bill has crept up since the licence change two years ago.
Third, ship the Hyvä upgrade and the 2.4.9 upgrade in separate releases. Combining a frontend overhaul with a framework migration sounds efficient and is always slower. We have done this both ways on multiple Hyvä projects and the split version finishes faster every time because regressions can be attributed to the right layer.
For studios shipping Magento as a service, the 2.4.9 upgrade is also a moment to revisit how you charge for it. Bundling the upgrade into retainer hours is a generous reading of the contract that most merchants will quietly accept until the bill arrives in September. Pricing it as a discrete project, with the inventory step as a paid discovery, sets the relationship right.
None of this is dramatic. Magento upgrades never are. But 2.4.9 is the release where deferred decisions about PHP, MySQL and Laminas all come due at once. Studios that planned the calendar in May will ship in July. Studios that did not will be quoting emergency migrations in October.