Magento 2.4.8 and 2.4.9 upgrades: what breaks, and what to check first

If you're upgrading a Magento store this year, the short answer is this. The core upgrade is rarely what breaks. What breaks is the ground underneath it. From 2.4.8, Magento no longer works with Elasticsearch, so search has to move to OpenSearch first. The server's PHP has to move too: 8.3 or 8.4 for 2.4.8, and 8.5 for 2.4.9. And the extensions and custom modules on the store meet new versions of the libraries they were written against. Get those three right on a copy of the store and the upgrade itself is mostly routine.

This piece goes through each of them with Adobe's own wording, says what I've found actually fails in real stores, and ends with the checks I run before anything touches production. It covers both versions, because the real question for most stores is which one to aim for. There's a separate piece on which Magento versions are still supported if you need to know how urgent your own upgrade is.

Where the versions stand

Adobe gives every 2.4 release three years of standard support from its release date. After that it stops shipping quality fixes, and then security fixes, for that line. The dates matter because they decide how long an upgrade buys you.

2.4.9 is the current release

2.4.9 came out on 12 May 2026 and is supported until 31 May 2029, according to Adobe's lifecycle policy. It's the version new builds should start on, and the one every other version is now measured against. Its patch releases will carry the security fixes for longest.

2.4.8 is the safe target for most stores

2.4.8 came out on 8 April 2025 and is supported until 31 May 2028. It has had over a year of patch releases (2.4.8-p5 is listed in Adobe's system requirements), and most maintained extensions have released versions for it. For a store on 2.4.6 or older, that maturity is worth a lot.

2.4.7 and older are on the clock

2.4.7 has standard support until 31 May 2027. 2.4.6 lost standard support on 11 August 2026, and 2.4.5 and 2.4.4 are already past it. Adobe's lifecycle page lists extended and security-only periods after that for Adobe Commerce, so check what your own licence actually covers before you count on them.

What an upgrade actually buys

Moving from 2.4.6 to 2.4.8 buys roughly two more years of fixes. Moving to 2.4.9 buys three. The difference is smaller than it looks, because a store on 2.4.8 can make the later step to 2.4.9 from a supported, well-understood base. That's the argument I come back to in the decision section below.

Search: the move from Elasticsearch to OpenSearch

This is the change most likely to stop an upgrade, and the one people plan for least. Adobe's 2.4.8 notes put it plainly: "Adobe Commerce is now optimized for OpenSearch 2.19 and is no longer compatible with Elasticsearch." The same notes say all Elasticsearch 7 and 8 modules and classes are now deprecated in the codebase, and the admin marks both Elasticsearch options as deprecated.

What changed, version by version

OpenSearch support arrived back in 2.4.4, as a compatible fork of Elasticsearch, and 2.4.6 gave it its own module and admin settings. So for years a store could run either. 2.4.8 ended that choice, and 2.4.9's notes move the target again: 2.4.9 is fully compatible with OpenSearch 3. Elasticsearch 7.17 itself reached end of support on 15 January 2026, which Adobe flags for every store still running it.

Why it breaks the upgrade itself

Magento checks the search engine before it upgrades. If the configured engine isn't supported, it stops with an error that reads: "Your current search engine, <Engine Name>, is not supported. You must install a supported search engine before upgrading." That's from Adobe's upgrade troubleshooting guide. It means search can't be a job you tidy up after go-live. It has to be done, and working, before the upgrade runs.

What doesn't come across on its own

The catalogue index itself isn't migrated. Magento rebuilds it: you point the store at OpenSearch and reindex. That part is easy. The trouble is everything else that talked to Elasticsearch. In the stores I've upgraded, it's been third-party search extensions built on the Elasticsearch 7 module's classes, custom indexers for things like store locators or blog search, and reporting or feed scripts that query the search server directly with an Elasticsearch client. None of those change when Magento does. Each one needs checking against OpenSearch, and some need rewriting.

How the move is done

Adobe's migration guide sets out five steps: check the prerequisites, put the site in maintenance mode, optionally remove Elasticsearch, install and configure OpenSearch, then flush the cache and reindex catalog search. On a copy of the store, the commands run in this order.

The host, port and index prefix for OpenSearch are set alongside the engine, in the admin under catalog search or with config:set. Then search the storefront properly: category pages with filters, the search results page, and whatever your customers actually type. A reindex that finishes cleanly isn't the same as search that works.

My view: do search first, on its own

I move search to OpenSearch as a separate release, on the current Magento version, before the Magento upgrade. Any 2.4.6 or 2.4.7 store can do that today. It takes one of the biggest risks out of the upgrade, and if search misbehaves you know exactly why, because nothing else changed that week. Doing it inside the upgrade means that when search breaks, it could be any of forty things.

PHP: two moves in two versions

Every Magento upgrade in this range needs a newer PHP on the server, and 2.4.9 needs a newer one again. That's a hosting job before it's a code job, and on some managed hosts it's the slowest part of the whole project.

What each version needs

From the 2.4.8 release notes: PHP 8.4 is added, PHP 8.3 is still supported, PHP 8.2 is compatible only for upgrade purposes, and PHP 8.1 is removed from all project libraries. Adobe also says you must upgrade to PHP 8.3 before upgrading to 2.4.8. For 2.4.9, PHP 8.5 is fully supported, PHP 8.4 is allowed only for upgrading and isn't recommended for production, and PHP 8.2 and 8.3 are no longer supported.

The pattern PHP 8.4 deprecates

PHP 8.4 deprecates implicitly nullable parameters. The PHP manual gives the example: a declaration like function foo(T1 $a = null) should become function foo(?T1 $a = null). It's a small change to write, but it's everywhere in older Magento modules, because it was the normal way to write an optional argument for years. A deprecation doesn't stop the site. It fills the logs, it hides the warnings you actually need to see, and it becomes an error in a later PHP version.

Where it really bites: extension constraints

The hard stop is usually Composer, not PHP. An extension whose composer.json says it only runs on PHP 8.1 or 8.2 won't install on the new version at all, however well its code would actually run. The whole dependency tree then fails to resolve. You find that out in the first ten minutes of a staging upgrade, which is exactly why it belongs on staging.

The 2.4.9 hop

For a store going to 2.4.9, the path runs through PHP 8.4 to upgrade and PHP 8.5 to run. So the server needs PHP 8.5 available, and every extension needs a release that declares 8.5. In September 2026 that second part is the one to check carefully. Plenty of vendors have 2.4.8 releases and haven't yet shipped 2.4.9 ones.

The libraries underneath your extensions

Magento is built on other people's libraries, and both releases moved several of them by a major version. Code that goes through Magento's own interfaces barely notices. Code that extends or calls those libraries directly does.

In 2.4.8

Adobe's list of backward-incompatible changes names the ones with the widest reach. Monolog moved to 3.x, and custom log handlers now take a LogRecord object instead of an array, so any module with its own logger needs a small rewrite. The old TinyMCE 5 editor was removed, which takes custom admin editor plugins with it. MySQL now defaults to utf8mb4 collation. On MySQL 8.4 the restrict_fk_on_non_standard_key setting is on by default, which blocks foreign keys on non-unique or partial keys, and 2.4.8 adds a unique key on option_id and store_id in the eav_attribute_option_value table.

In 2.4.9

2.4.9 goes further. The deprecated Zend_Cache implementation is replaced by the symfony/cache component. Magento has its own MVC implementation, replacing the legacy Laminas MVC. All Symfony dependencies move to Symfony 7.4, and Adobe's note is direct: custom classes that extend Symfony core classes must have updated type declarations and method signatures. The admin editor moves again, to the open-source HugeRTE.

Why a unique key can stop the upgrade

A database can't add a unique key over rows that already break it. If a catalogue has two values for the same attribute option in the same store view, which years of imports and extensions can leave behind, that schema change has nothing clean to apply to. Checking the table for duplicates takes one query, and it's far cheaper on a Tuesday afternoon in staging than halfway through a production deployment.

How I find these before they find you

Adobe's Upgrade Compatibility Tool compares your custom code against the target version and lists what uses removed or changed core code. It's a good start and it misses things, mostly in third-party code and in anything that calls libraries dynamically. So after the tool, I read the modules that matter by hand: anything touching search, logging, cache, the admin editor and the checkout.

Admin and operations changes that catch people out

Some of what breaks isn't code at all. It's a process someone runs twice a year, or a setting nobody remembers configuring.

Encryption keys move to the command line

From 2.4.8, changing the encryption key in the admin is no longer supported. Adobe added CLI commands for changing keys and re-encrypting system configuration instead. If your security runbook, or your agency's, says to rotate keys from the admin screen, it's out of date the day you upgrade.

Two-factor authentication needs attention

2.4.8 moves Duo two-factor authentication to Duo's Web SDK v4, and the release notes say merchants must add a Client ID and Secret in the admin settings. The one-time password library also changed how its window is worked out: a leeway in seconds replaces the old window multiplier. Either can lock admin users out on the morning after go-live if nobody checks it on staging.

Features and payment methods that went

2.4.8 removed the System > Support > Data Collector tool, TinyMCE 5, and the Sofort and Giropay payment methods, which Adobe says are no longer supported. If a store takes payment through either, that's a checkout conversation to have well before the upgrade, not after.

New limits for headless front ends

2.4.9 adds validation that limits GraphQL requests to ten aliases, and a configurable limit on query length of about 1 MB by default. Ordinary storefronts won't notice. A headless front end or an integration that builds very large queries might, so run its real traffic against staging. 2.4.8 also changed ProductInterface.gift_message_available from a string to a non-nullable boolean, which can trip a strictly typed front end.

2.4.8 now, or straight to 2.4.9?

This is the question most store owners actually ask me. It doesn't have one answer, but it does have a usual one.

The case for 2.4.8

2.4.8 has been out for well over a year. It's on its fifth patch release, the extension market has caught up with it, and PHP 8.3 and 8.4 are widely available from hosts. It's supported until 31 May 2028. For a store on 2.4.6 or older, it gets you onto a supported version with the least number of unknowns.

The case for 2.4.9

2.4.9 is supported a year longer, until 31 May 2029, and it gets the Zend_Cache and Laminas MVC changes over with in one go instead of in a second project later. A store that's already clean on 2.4.8, with maintained extensions and little custom code, has little reason to wait.

The other view, fairly

Some developers argue for always going to the latest release, on the basis that two upgrades cost more than one. For a small store with a short extension list, that's right, and I'd go straight to 2.4.9. The argument weakens as the extension list grows, because every extension without a 2.4.9 release becomes a blocker you can't fix yourself.

My view

For a store on 2.4.6 or older, with a typical list of twenty or more extensions, I'd go to 2.4.8 now and plan 2.4.9 for next year. For a store already on 2.4.8 with maintained extensions, I'd plan 2.4.9 once every extension has a release for it. Either way, the extension list decides, so read it before you pick.

The checks before production

None of these are clever. They're the order that stops surprises, and I don't skip any of them.

List every extension

Every module installed, its vendor, whether it's still maintained, and whether a release exists for the target version and its PHP. This is where most upgrades are won or lost, and it's also where the cost of the job is decided. Anything abandoned needs a replacement or removing.

Move search and PHP first, one at a time

Put OpenSearch in on the current version, as its own release. Then move PHP, on staging, and fix what the logs show. Each change is small enough on its own that a problem has one obvious cause.

Scan and read the custom code

Run the Upgrade Compatibility Tool against the target version, fix what it finds, then read by hand the modules that touch search, logging, cache, the admin editor and checkout. Check the attribute option table for duplicates while you're there.

Rehearse on a copy with real data

Upgrade a staging copy with a recent copy of the real catalogue and orders, then test the storefront, search and filters, checkout with every payment method, customer accounts, admin logins with 2FA, imports, feeds and every integration. Time the deployment and the reindex, because that's your maintenance window.

Plan the release, and the way back

A deployment window, a tested backup and rollback, and someone watching orders and error logs for the first hours afterwards. If the rollback has never been tried, it isn't a rollback.

What it comes down to

The version number is the easy part. What decides whether a Magento upgrade goes quietly is whether search is already on OpenSearch, whether the server has the right PHP, and whether every extension has a release for where you're going. Sort those on a copy of the store, one at a time, and the upgrade itself is a routine deployment. Skip them, and they surface together on the day you can least afford it.

More on how I work on Magento is on the Magento development page. The health check explains the outside read, and the backend audit covers the code, the extensions and the servers.