Magento 2.4.6 End of Life

Let's start with what doesn't happen, because this is where end-of-life dates get misunderstood in both directions. On 12 August 2026, a Magento 2.4.6 store will look exactly as it did the day before. Pages load, checkout works, orders come in. Nothing switches off. Anyone telling you your store will "stop working" is scaremongering.

What actually happens is quieter and, over time, worse. Under Adobe's published released-versions schedule, regular support for the Magento Open Source and Adobe Commerce 2.4.6 line, which originally shipped in March 2023, ends on 11 August 2026. From that date, Adobe publishes no further security patches and no quality fixes for 2.4.6. Every vulnerability discovered in the platform from that point on is fixed for supported versions and left open, permanently, on yours.

That has two practical consequences beyond the obvious hacking risk. First, new CVEs published after end of life will never be fixed on 2.4.6: the gap between your store and a patched store doesn't stay constant, it widens with every security bulletin Adobe releases. Second, PCI DSS compliance expects the software handling cardholder data to be supported and patched. An ecommerce platform that can no longer receive security patches is a compliance problem as well as a security one, and it's the kind of thing acquirers and assessors ask about.

So the honest framing is this: 11 August 2026 isn't the day your store breaks. It's the day your store starts silently accruing risk you can't patch away. The decision in front of you isn't whether to upgrade. It's which version to upgrade to, and whether you start now or under worse pressure later.

Before planning anything, confirm your exact version. Plenty of store owners are surprised by the answer. Either check the footer of your Magento admin panel, or run this from the Magento root directory on your server:

bin/magento --version

Note the patch level as well as the version, for example 2.4.6-p11 rather than plain 2.4.6. Being on a recent patch level is good news for your current security posture, but it doesn't change the deadline: every 2.4.6 patch level reaches end of life together on 11 August 2026.

And if the command comes back with 2.4.4 or 2.4.5: those lines are already past regular support. Everything in this article applies to you with the urgency turned up. You're not approaching the cliff edge, you're past it, and every Adobe security bulletin since your line went EOL contains fixes your store never received.

From 2.4.6 there are two sensible destinations, and they suit different situations.

Option A: Magento 2.4.8 is the recommended default. It's the current stable long-term line, supported through roughly April 2028, which buys you nearly two years of patched, compliant running before the next forced decision. Extension vendors have had time to confirm compatibility, which matters more than any other factor for upgrade speed. A typical 2.4.6 → 2.4.8 upgrade takes roughly 2–6 weeks depending on extension count and customisations. Started in mid-July, that comfortably beats the deadline. Started in late July, it's tight.

Option B: Magento 2.4.9 reached general availability on 12 May 2026 and is the biggest architectural shift in the 2.4.x line since 2.4.4: Valkey replaces Redis as the official cache backend, OpenSearch 3 is required, PHP moves to 8.4/8.5, MySQL to 8.4, and over 560 issues were fixed. It offers the best longevity, but it's early-adopter territory while extension vendors catch up, and the first aggregated patch (2.4.9-p1) is expected in the coming weeks and months. If you're curious about what the new stack involves, we've covered the Magento 2.4.9 hosting requirements and published a full Magento 2.4.9 upgrade guide.

Our honest advice for most 2.4.6 stores facing this deadline: go to 2.4.8 now, and plan 2.4.9 as a considered move later, once the extension ecosystem has settled and the first patch rounds have landed. An upgrade done under time pressure to a brand-new architectural line is how projects overrun past the deadline they were meant to beat.

If there's one thing to internalise from this article, it's this: the single biggest variable in a Magento upgrade timeline is your third-party extensions. Not the core upgrade itself. Magento's own upgrade tooling is well-trodden. It's the payment modules, shipping integrations, search enhancements, page builders and the extension somebody installed in 2023 whose vendor has since disappeared.

So before you book a single day of development time, audit every extension on the store. For each one, establish: is there a version compatible with your target Magento release? Is the vendor still active? Is the extension actually still used, or is it dead weight that can simply be removed? Every unmaintained extension is a fork in the road: replace it, pay for custom compatibility work, or drop the functionality. Each fork adds days or weeks.

This is why the honest answer to "how long will our upgrade take?" is always "show me your extension list first." A store with eight well-maintained extensions is a very different project from a store with forty of mixed provenance. It's also why starting the audit this week costs you nothing and tells you almost everything about whether your 11 August plan is realistic. If the audit reveals a problem extension, you want to know in July, not the first week of August.

A Magento version upgrade is never just application code. Each release line has its own system requirements: PHP version, search engine, cache backend, database. Moving up a line usually means moving the stack too. 2.4.8 expects a newer PHP than many 2.4.6-era servers run; 2.4.9 goes further, requiring OpenSearch 3, PHP 8.4/8.5, MySQL 8.4 and swapping Redis for Valkey. We keep a current reference of the Magento 2 server prerequisites for each version if you want to check your target against your current server.

This is where upgrades quietly stall. The application work finishes on staging, and then it turns out the production host can't provide the required PHP version, or doesn't offer OpenSearch, or won't touch the cache backend. If your host can't run the target stack, no amount of application work gets you over the line. Confirm this before the project starts, not at deployment time.

The cleanest pattern we see is upgrading onto fresh infrastructure: build the target stack (correct PHP, search, cache, Varnish) on a new server, deploy and test the upgraded store there as staging, then cut over. You get a known-good environment, a genuine rollback path (the old server keeps running untouched), and no risky in-place stack surgery on a live store. That's exactly how our free Magento migration service works when it's paired with an upgrade, and it's the approach our managed Magento 2 hosting is built around: the stack is prepared for your target version before your code ever lands on it.

There's a twist of timing that makes this particular EOL date sting more than previous ones. From 14 July 2026, four weeks before 2.4.6 support ends, Adobe moves to twice-monthly security bulletins, landing on the second and fourth Tuesdays of each month. For supported Magento versions, that's a clear improvement: security fixes arrive sooner and on a predictable rhythm, shrinking the window between a vulnerability being fixed internally and the fix reaching your store.

But that benefit only flows to supported lines. A store on 2.4.6 after 11 August gets none of it. In fact the contrast gets starker: stores on 2.4.8 and 2.4.9 will be patched twice a month, while the gap between them and an EOL 2.4.6 store widens at double the old rate. Attackers read security bulletins too. Every published fix is also a public description of a hole that still exists on unpatched and unsupported stores.

Put simply: staying supported has just become more valuable at exactly the moment 2.4.6 stops being supported.

Assuming you're reading this around publication (mid-July 2026), here's a realistic plan:

• This week: confirm your exact version (bin/magento --version). Start the extension audit: list every third-party extension, its vendor status, and its compatibility with 2.4.8. Pick your target version.
• This month: confirm your hosting stack meets the target version's requirements (PHP, search engine, cache backend), or arrange infrastructure that does. Run the upgrade on staging first, never directly on production. Resolve extension incompatibilities as the audit surfaces them, and put the store through real testing: checkout, payment methods, shipping rates, order emails, admin workflows.
• By 11 August: plan and execute the production window, ideally a quiet trading period, with a tested rollback path. The goal is to be on a supported line before the first post-EOL security bulletin lands, not to scrape in on the day.

If the audit tells you the timeline doesn't work (too many problem extensions, no development resource available), then the fallback is to compress risk, not ignore it: harden the store, restrict admin access, and schedule the upgrade for the earliest realistic date. An upgrade in September is far better than one deferred indefinitely.

Honest framing first: a Magento upgrade is application work as well as hosting work. The extension audit, code compatibility and theme testing are Magento development tasks, done by your team, your agency, or with our upgrade support. What we remove entirely is the infrastructure half of the problem.

EveryHost provides UK Magento hosting where the stack (PHP, OpenSearch or Valkey, Varnish) is prepared for your target Magento version before your code arrives, with UK-based engineers who do this work every week. Our Magento migration service is free and zero-downtime, which makes the upgrade-onto-fresh-infrastructure pattern described above genuinely practical: we build the new environment, you (or your agency, or we together) upgrade onto it as staging, and the cutover happens without your store going dark. Have a look at our Magento hosting plans to see what's included, or just call and describe your store. We'll tell you honestly what the upgrade involves.