Upgrading to Adobe Commerce 2.4.8: What Actually Breaks

The system requirements page for Adobe Commerce 2.4.8 — opens in a new tab will tell you what versions to run. It won't tell you which of those version bumps quietly wrecks a week of your timeline. That second part only shows up once you've actually done a few of these migrations, so here's what we've learned running them for clients moving off 2.4.6.

The environment, at a glance

Under the hood, a few of these carry more weight than a version number suggests. PHP 8.1 support isn't deprecated, it's removed, so there's no gradual runway here. Elasticsearch is the same story: OpenSearch is now the only supported search engine, not an alternative option. Core third-party libraries got bumped too (Monolog to 3.x, PHPUnit to 10, Composer to 2.8+), and Adobe changed the default indexer mode — opens in a new tab from "Update on Save" to "Update by Schedule" on new installs and upgrades, specifically to reduce load and cut down on performance bottlenecks during normal operation.

The part that actually eats your timeline

None of the version numbers above are the hard part. The hard part, consistently, is third-party module and extension breakage.

PHP 8.3/8.4 enforces stricter type handling than 8.1 did, Monolog 3.x changed its interface in ways older code doesn't expect, and code that was merely sloppy under PHP 8.1 starts throwing fatal errors under 8.3/8.4 instead of just a warning. Older custom modules and marketplace extensions that were never updated for strict typing are the single biggest time sink in almost every upgrade we've run. The fix usually means waiting on a vendor patch, forking the extension yourself, or in the worst cases replacing it entirely, and you generally don't know which of those three you're dealing with until you've actually tried running it.

Our advice, plainly: audit every third-party extension for PHP 8.3/8.4 compatibility before you touch anything else. Do this first, not last. It's the step most likely to blow up your timeline, and it's also the step you can start on before the rest of the environment is even ready.

What four upgrades actually looked like

This isn't a hypothetical risk. We've run 4 upgrades to 2.4.8 so far, and the pattern has held every single time: on average, 9 out of 10 installed extensions needed patching before the store worked correctly again. Extensions from major, well-established providers, Firebear and Amasty among them, broke consistently across those projects, not as one-off bad luck on a single build. It's worth being clear-eyed about this: reputable, actively-maintained vendors still aren't guaranteed to be compatible on day one. And it's not only third-party code. Our own internal custom extensions, code we wrote and maintain ourselves, also needed patching to run on 2.4.8. Nobody's code gets a free pass on this upgrade.

Other traps hiding in the version bumps

Three of them are worth knowing about before they surprise you mid-upgrade:

• MySQL 8.4's foreign key validation is stricter by default. restrict_fk_on_non_standard_key is now on out of the box, and it will break custom database tables or legacy modules built on non-standard keys that MySQL 8.0 never complained about.
• PHP's null-parameter handling got stricter too. Code that quietly passed null into a non-nullable internal function parameter under PHP 8.1 will now throw a deprecation notice at best, or a hard type error at worst.
• Elasticsearch to OpenSearch isn't a config flag. It needs real server provisioning, index mapping work, and testing before go-live, or you'll find out about catalog search failures from your customers instead of from your QA process.

If you're planning this upgrade

Start with the extension audit, and budget for it properly. If 9 out of 10 extensions needing patches is roughly what to expect, "check compatibility" isn't a quick pre-flight step, it's a project phase in its own right, with its own timeline and its own risk of vendor delays outside your control.

One more thing to put on the calendar early: book your Adobe support appointment at least 7 days ahead of when you actually plan to start the upgrade. Adobe's support team can be genuinely useful when something goes sideways mid-migration, but you don't want to be waiting on a scheduling slot at the exact moment you need them.

Once the upgrade itself is done, don't treat it as finished. Every feature and every integration needs to be retested against the new environment, not just the ones you expect to be affected. A version jump this size touches enough underlying dependencies that assuming "it deployed cleanly, so it's fine" is how issues make it to production instead of QA.

We've run this migration for enterprise Adobe Commerce clients with exactly this mix of custom modules and legacy database schemas. If you're planning an Adobe Commerce upgrade, talk to us.

---

Sources: Adobe Commerce system requirements — opens in a new tab and the 2.4.8 release notes — opens in a new tab (Adobe Experience League), plus our own migration experience across 4 upgrades.