Upgrading Magento 2.3 to 2.4: The Jump Nobody Warned You About

Most upgrade guides assume you are one or two versions behind. If you are on Magento 2.3, you are not one or two versions behind — you are behind a PHP major version, a mandatory search engine you have never run, and two separate framework replacements, all of which happened while you were not upgrading.

This is why "we're on Magento 2, so it's just a version bump" turns into a bad quarter. The version numbers are adjacent. The platforms underneath them are not.

Where 2.3 actually stands

Magento 2.3 reached end of support on September 8, 2022. No official security patches have shipped for the line since. A store still running it has roughly four years of published, unpatched vulnerabilities behind it — and published is the operative word, because disclosure tells attackers precisely where to look.

The compliance dimension is the same one that applies to any end-of-life platform: PCI DSS requires critical patches within a defined window, and a version that receives no patches makes that impossible to satisfy rather than merely difficult.

So the question is not whether to move. It is how to sequence a move that crosses more infrastructure than a normal upgrade ever does.

What actually changed between you and current

Four things, and each is a project rather than a flag.

1. PHP 7 to PHP 8. Magento 2.3 ran on PHP 7.x. Current 2.4 releases require PHP 8.3 or 8.4, with 2.4.9 moving to 8.4 or 8.5. This is a language major version, not a point release: removed functions, stricter type handling, and changed error semantics. Any custom module or extension written casually against PHP 7 will need work, and the failures are frequently silent rather than fatal.

2. Search stopped being optional. Magento 2.4.0 removed the MySQL catalog search engine outright and made Elasticsearch a hard requirement. If you are on 2.3 using MySQL search, you are not configuring a new option — you are standing up, tuning, and operating search infrastructure your store has never had. Then 2.4.8 replaced Elasticsearch with OpenSearch, so the full journey passes through three distinct states:

3. Zend Framework became Laminas. Magento 2.4.0 replaced Zend Framework with Laminas. Any code importing Zend_ classes directly — which is a great deal of older third-party code — breaks. Then 2.4.9 replaced Laminas MVC with native PHP MVC, meaning a 2.3 store arriving at 2.4.9 crosses two framework migrations rather than one. We covered what that second one costs in 2.4.8 versus 2.4.9.

4. Two-factor authentication became mandatory for admin access in 2.4.0. This is minor engineering and a real operational change — every admin user needs enrolling, and any automation logging into the admin needs rethinking.

Pick your target before you pick your path

The instinct is to go straight to the newest release. For a store coming from 2.3, that is usually the wrong call.

2.4.8 is the sensible target for most 2.3 stores. It is a mature line, its edge cases have been found by other people, extension compatibility is broad, and it carries support to May 31, 2028. Critically, it means you cross one framework migration rather than two.

2.4.9 is the right target if you have few third-party extensions, a team comfortable being an early adopter, or you are rebuilding enough of the store that the extra disruption is absorbed anyway. It buys support to May 31, 2029.

Coming from four years behind, the argument for taking the extra year of runway is weaker than the argument for landing on proven code. You can take 2.4.9 as a planned project in 2027, by which point it will be the mature line. Skipping ahead is fine; arriving on a new framework with a decade-old extension estate is where projects stall.

The staged path

Do not attempt this as one Composer command. Each infrastructure change should be independently verifiable, so that when something fails you know what caused it.

Stage 1 — get current within 2.3. Move to the final 2.3 patch level first. This is same-line work, low risk, and it gives you a known-good starting point rather than an arbitrary one.

Stage 2 — take the inventory. Before touching versions, produce the list that is your actual risk profile:

# What you're really running
bin/magento --version
composer show magento/product-community-edition | grep versions

# Everything third-party, which is where the risk lives
composer show | grep -v "^magento/"

# Find direct Zend imports — these break on 2.4.0
grep -rn "Zend_" app/code/ --include="*.php" | head -50

That last command is the cheapest early warning you can run. Every hit is a decision.

Stage 3 — PHP first, on 2.3 where possible. Move as far up the PHP range as your 2.3 patch level supports before changing Magento versions. Isolating the language migration from the platform migration means PHP-related breakage surfaces on a codebase you still understand.

Stage 4 — stand up search. Provision and tune Elasticsearch or OpenSearch as a discrete piece of infrastructure, with its own verification, before it becomes a hard dependency mid-upgrade. Our Redis and OpenSearch tuning notes cover the configuration that matters under real load — the defaults are not what you want.

Stage 5 — cross into 2.4. Now the Magento version change happens against known PHP and known search infrastructure, which reduces it to the thing it should have been: an application upgrade.

Stage 6 — regression test the revenue paths. Checkout hardest and first, every payment and shipping method, guest and logged-in. Then catalog and layered navigation, which are the surfaces most affected by the search-engine change. The full methodology is in our Magento 2 upgrade guide.

What this realistically costs

Scope it as a project, not a maintenance task. On a store with a customized theme, twenty-odd extensions, and four years of drift, the extension audit and remediation dominate — routinely more than the upgrade work itself. Infrastructure provisioning is a known quantity. Regression testing is proportional to how much of your checkout is custom.

The number that surprises people is not the engineering. It is that a four-year gap means several of your extension vendors no longer exist, and each of those is a build-or-replace decision that nobody can make for you.

What we'd do

Run the Zend_ grep and the extension list today. Twenty minutes of work tells you whether this is a contained upgrade or a partial rebuild, and it is the difference between a plan and an estimate.

Then target 2.4.8, stage the infrastructure changes so each one can fail on its own terms, and treat the extension audit as the critical path it actually is. The stores that get through this cleanly are the ones that stopped calling it an upgrade early enough to plan it properly — and the thing that keeps you from being here again in 2030 is ongoing Magento support and patching between versions, not the next big jump.

Emyrix upgrades stranded Magento stores — extension audits, staged infrastructure migration, and the Magento 2 development work when an extension has to be rebuilt rather than replaced. If you're on 2.3 and want to know what your upgrade actually involves, get in touch.

Version support dates and platform requirements come from Adobe's software lifecycle policy and release notes, which are the authoritative sources and worth checking directly for your edition and license type.