Magento Open Source 2.4.8 is the current release line, and upgrading to it is now a requirement rather than an option. It needs PHP 8.3 or 8.4, drops Elasticsearch in favor of OpenSearch 2.x, and adds MySQL 8.4 support. The work that breaks during the move is almost always third-party extensions and custom PHP, not the core upgrade itself.
If your store is on 2.4.5, 2.4.6, or 2.4.7, this is the upgrade that will keep you on a supported, patchable platform. This guide walks through why the deadline matters, exactly what changed in 2.4.8, what tends to break, and a step-by-step process that gets you there without taking the store offline for days. It applies to both Magento Open Source and Adobe Commerce, since they share the same core.
We do these upgrades for a living at Bemeir, a Brooklyn Magento and Adobe Commerce agency, and the pattern is consistent: the platform upgrade is predictable, and the risk lives in your extensions, your custom code, and your test coverage.
Why the 2.4.8 upgrade is not optional
Adobe’s support model is time-boxed. The Adobe Commerce software lifecycle policy gives each version a standard support window of three years from its general availability date, with quality fixes and security patches during that window. Versions 2.4.6 and 2.4.7 each get one additional year of support at no extra cost, but that runway is short and it ends.
Two dates matter for most merchants right now:
- PHP 8.1 reached end of life on December 31, 2025. Any store still running PHP 8.1 is now on an unsupported language runtime, which is both a stability and a PCI DSS problem because unpatched software in the cardholder data environment fails compliance.
- The 2.4.6 support window is closing in 2026. Once a version leaves support, you stop receiving official security patches, and running an unpatched commerce platform that processes cards is the exact exposure that leads to breaches and failed audits.
The practical takeaway: if you are more than one or two versions behind, plan the upgrade now rather than during the next security scramble. Staying current is the cheapest form of security work you can do, and it is far less disruptive than an emergency patch on a version that no longer receives them. Our Adobe Commerce security and PCI DSS runbook covers why an unmaintained version is a compliance failure, not just a technical debt line item.
What actually changed in Magento 2.4.8
The 2.4.8 release notes list dozens of highlights and hundreds of fixed issues, but four changes drive the upgrade work. You can read the full detail in the official Magento Open Source 2.4.8 release notes.
| Area | Requirement in 2.4.8 | What it means for you |
|---|---|---|
| PHP | PHP 8.3 or 8.4 (8.4 recommended); 8.1 and 8.2 no longer supported | Your server needs a PHP bump, and code using deprecated PHP behavior will break |
| Search | OpenSearch 2.x; Elasticsearch is no longer compatible | You must stand up OpenSearch and reindex; Elasticsearch configs stop working |
| Database | MySQL 8.4 LTS or MariaDB 11.4 (MySQL 8.4 recommended) | Plan a database engine upgrade alongside the app upgrade |
| Cache and queue | Valkey 8.x cache support added; RabbitMQ 4.x | Infrastructure components move up a major version |
Beyond the infrastructure, 2.4.8 continues the framework modernization that has been running through recent releases: updated JavaScript libraries, a TinyMCE editor upgrade, and dependency bumps across the board. None of these are dramatic on their own, but together they are the reason a naive composer update rarely just works on a store with custom code.
What tends to break, and why
In our experience the core upgrade is the easy part. Here is where the real work sits, in rough order of how often it causes problems.
Third-party extensions. This is the number one source of upgrade pain. Every paid or free module you installed has to have a version that supports PHP 8.3/8.4 and Magento 2.4.8. If a vendor has gone quiet or the extension is abandoned, you either replace it, pay for a compatibility patch, or absorb the work of updating it yourself. Budget an extra 20 to 30 percent of the upgrade effort here if your catalog of extensions is large.
Custom PHP and modules. Code written against older PHP versions often relies on behavior that PHP 8.3 and 8.4 tightened or removed. Implicit nullable types, dynamic properties, and loose type juggling are common offenders. The compiler and static analysis will catch most of it, but only if you actually run them in a staging environment before go-live.
The Elasticsearch to OpenSearch swap. If your store still points at Elasticsearch, catalog search will not work on 2.4.8 until you configure OpenSearch 2.x and reindex. This is straightforward when planned and a nasty surprise when it is not.
Custom theme and admin JavaScript. The jQuery, RequireJS, and TinyMCE updates in recent releases can break custom admin widgets and theme scripts that depended on the older versions. If you are on a heavily customized Luma theme, this is also the moment to ask whether you should be rebuilding on a modern frontend instead of patching the old one.
Data and schema patches. Large catalogs and custom entities can make setup:upgrade slow and occasionally fragile. This is why you rehearse the upgrade on a full-size data clone, not a trimmed sample.
The upgrade itself: a step-by-step process
A disciplined upgrade keeps the live store untouched until the very end. This is the sequence we follow.
- Audit first. Record your exact current version, PHP version, search engine, database engine, and the full extension list with versions. A structured pass here prevents surprises later; our 47-point Magento technical audit checklist is built for exactly this.
- Clone to staging. Stand up a staging environment that mirrors production, including a full-size database copy. Never rehearse an upgrade on a partial dataset.
- Raise the infrastructure. Move PHP to 8.3 or 8.4, stand up OpenSearch 2.x, and align the database and cache layers to supported versions before touching the application.
- Upgrade the codebase. Update the Magento metapackage and dependencies through Composer 2.x, then run
setup:upgrade,setup:di:compile, andsetup:static-content:deploy, and reindex against OpenSearch. - Fix extensions and custom code. Resolve compatibility issues module by module. Replace abandoned extensions, apply vendor patches, and update your own code for PHP 8.4.
- Regression test the money paths. Test checkout, every payment method, tax, shipping, search, and any B2B workflows such as company accounts and quotes. These are the flows that cost real revenue if they break.
- Apply security patches and go live. Apply the latest security patches for 2.4.8, then cut over in a planned maintenance window with a rollback path ready.
Done this way, the customer-facing downtime is a short maintenance window, not a multi-day outage. Ongoing, the cleanest approach is to keep a support and patching retainer so you never fall this far behind again. Our guide to what a real Magento maintenance plan should cover lays out what that looks like.
Upgrade, or rebuild? Pairing 2.4.8 with a Hyva migration
An upgrade is a good moment to ask a bigger question. If your store runs the legacy Luma theme and scores poorly on PageSpeed, the version upgrade and a frontend rebuild can share a single QA and regression cycle instead of two.
On Magento and Adobe Commerce, the modern frontend is Hyva, which replaces Luma with a lighter, faster theme that consistently lifts PageSpeed and Core Web Vitals. As the first US-based Hyva Gold Partner, we often sequence a 2.4.8 upgrade and a Hyva rebuild together because the extension compatibility work overlaps. If you have many Luma-era modules, our guide to adapting third-party extensions to Hyva explains what carries over and what has to be rebuilt.
If instead you are questioning whether Magento is still the right platform at all, that is a legitimate conversation. We also build on Shopify, Shopware, and BigCommerce, and the honest answer for most established Magento merchants with real catalog and B2B complexity is that staying on Magento and keeping it current is cheaper and less risky than a replatform. The upgrade is the pragmatic move; a replatform is a strategy decision, not an upgrade shortcut.
How Bemeir runs upgrades
We work as an extension of your team, and our differentiator on upgrades is an unusually deep partner ecosystem with 60+ integrations, which means we have seen most extension and payment combinations break and be fixed before. That shortens the compatibility phase that dominates upgrade timelines. You can see that ecosystem on our technology partners page, and more about how we work on our about page.
FAQ
What PHP version does Magento 2.4.8 require?
Magento 2.4.8 requires PHP 8.3 or 8.4, and PHP 8.4 is recommended for production. PHP 8.1 and 8.2 are no longer supported on 2.4.8, and PHP 8.1 reached end of life on December 31, 2025. Upgrading PHP is one of the two infrastructure changes the upgrade forces, alongside the move to OpenSearch.
Does Magento 2.4.8 still support Elasticsearch?
No. Magento 2.4.8 is no longer compatible with Elasticsearch and is built for OpenSearch 2.x. If your store points at Elasticsearch, catalog search will not work until you stand up OpenSearch, update the configuration, and reindex. Plan this as part of the upgrade rather than discovering it at go-live.
When does support for Magento 2.4.6 and 2.4.7 end?
Adobe provides a three-year standard support window from each version’s general availability, and 2.4.6 and 2.4.7 each receive one additional year of support at no cost. In practice, stores on 2.4.6 should be upgraded well before its support window closes in 2026, and 2.4.7 stores should plan their move over the following year. Check the Adobe lifecycle policy for the exact dates that apply to your version.
How long does a Magento 2.4.8 upgrade take?
A clean upgrade on a store with modest customization can take a few weeks, most of which is extension compatibility work and regression testing rather than the core upgrade. Stores with large catalogs, many third-party extensions, or heavy custom code take longer. The single biggest driver of timeline is the state of your extensions and whether their vendors have released compatible versions.
Can I upgrade to 2.4.8 and migrate to Hyva at the same time?
Yes, and often you should. Running the version upgrade and a Hyva frontend rebuild in one project lets them share a single QA and regression cycle, and the extension compatibility work overlaps. For stores on an old Luma theme with poor performance, doing both together is usually more efficient than two separate projects.
Will the upgrade take my store offline?
Only for a short, planned maintenance window at cutover. The bulk of the work happens on a staging clone that mirrors production, so the live store keeps running while you upgrade, test, and fix extensions. A rollback plan should be ready before you cut over, so a problem at go-live is a quick reversal rather than an outage.
