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 2.4.6 line, which originally shipped in March 2023, ended 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 was not the day your store broke. It was the day your store started silently accruing risk you cannot patch away, and it has been doing that for four weeks. The decision in front of you is not whether to upgrade. It is which version to upgrade to, and whether you do it on your own schedule or after an incident picks the date for you.

This is the part most coverage of the deadline gets wrong, and it decides how urgent your situation actually is.

Adobe offers an extended support window on the 2.4.6 line, running to 30 August 2027, followed by a security-only transitional period. If you read that and relaxed, check which product you are running first, because extended support is available to licensed Adobe Commerce customers only. It has never applied to the Magento Open Source code base.

Most self-hosted UK Magento stores run Open Source. If that is you, the extended support headlines are not about your store. You have been running without security patches for four weeks, and the number of unpatched vulnerabilities on your store only goes up from here.

There is a timing problem on top of that. Peak trading is weeks away, and most stores freeze code at the end of October. An upgrade that does not start soon does not get to happen until January, which means trading the whole of Black Friday and Christmas on an unsupported platform. We covered how that freeze works in the peak season security guide.

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 anything: every 2.4.6 patch level reached end of life together on 11 August 2026, including the last one.

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 to 31 May 2028, which buys you well over a year 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 to 6 weeks depending on extension count and customisations. Every week you wait is another week unpatched, so the useful question is no longer whether you beat a deadline. It is how short you can make the exposure.

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. It has now been generally available for four months and, as of early September 2026, Adobe has not yet published a 2.4.9-p1 aggregated patch. 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 now past the deadline: go to 2.4.8, and plan 2.4.9 as a considered move later, once the extension ecosystem has settled and the first patch rounds have landed. Jumping an already-late store straight onto a brand-new architectural line is how a four-week exposure quietly becomes a six-month one.

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 you can be supported again before the peak trading freeze. If the audit reveals a problem extension, you want to know in September, not in the last week of October.

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 ended, Adobe moved 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 gets none of it. In fact the contrast has got starker: stores on 2.4.8 and 2.4.9 are 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 became more valuable at exactly the moment 2.4.6 stopped being supported.

You are past the deadline, so this is no longer a countdown. It is a plan to cut the exposure as short as you reasonably can, and to get it done before the peak trading freeze closes the window until January:

• 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.
• Before the freeze: plan and execute the production window, ideally a quiet trading period, with a tested rollback path. Most stores stop deploying at the end of October. Landing the upgrade before that is the difference between trading peak supported and trading it unpatched.

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, put monitoring on the file system so an injection is caught in hours rather than months, and book the upgrade for the first realistic slot after peak. An upgrade in January that you have actually scheduled beats one you keep intending to do.

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.