The Deadline Open Source Merchants Cannot Buy Their Way Out Of
Magento Open Source 2.4.6 reaches the end of its regular support on August 11, 2026. According to Adobe's own release documentation, that is the day the 2.4.6 line stops receiving patches. The date itself is not the interesting part, deadlines come and go. The interesting part is the phrase Open Source, because it decides whether you have an escape hatch, and for a large number of stores the answer is that you do not.
Adobe Commerce, the paid product, has a lifecycle policy that includes a one-year extended-support option for older releases. Adobe Commerce 2.4.4 and 2.4.5, for example, received that extension at no extra cost. Magento Open Source, the free code base that runs an enormous share of the world's mid-market stores, is explicitly not covered by that policy. There is no paid extension to buy and no year of grace to fall back on. On August 12, 2026, an Open Source 2.4.6 store is simply running unsupported software.
What End of Support Actually Means
It is worth being precise, because "end of support" sounds soft and it is not. After August 11, the 2.4.6 line stops receiving security patches, quality and bug fixes, and compatibility updates. The consequences stack up quickly.
The first is security. Adobe ships Magento security fixes on a schedule, in the bulletins the community tracks by their APSB numbers, and those fixes target the currently supported versions. The May 2026 security update, for instance, addressed more than a dozen vulnerabilities across the supported lines, some serious enough to lead to code execution or file writes on an affected store. Once 2.4.6 falls off that list, the next bug of that class ships with a fix for 2.4.8 and 2.4.9 and nothing for you. A commerce platform is one of the highest-value targets on the web, and running it unpatched is not a position you want to hold for long.
The second is compliance. If your store handles card data, PCI DSS expects you to run supported software and apply security patches. An unsupported, unpatched commerce platform is hard to square with that, and your payment provider or acquiring bank can take an interest. For many merchants it is the compliance conversation, not the abstract security risk, that actually forces the upgrade.
The third is the slow rot. Extensions and integrations gradually stop testing against an old core, the PHP and database versions move on underneath you, and every month you wait makes the eventual jump larger and riskier. The cheapest time to upgrade is always now, and it only gets more expensive from here.
Where You Should Actually Go
Not every supported version is a sensible destination, so it is worth being clear about the options.
2.4.7 is a trap. Its own regular support ends in April 2027, only months after 2.4.6, so upgrading from 2.4.6 to 2.4.7 buys you a short runway and then a second upgrade almost immediately. Skip it as a destination.
2.4.8 is the pragmatic target. Its support runs to April 11, 2028, which gives you close to two years before you have to think about this again, on a version the ecosystem has had time to stabilise around. For most stores moving off 2.4.6, this is the sweet spot between a meaningful support window and a codebase your extensions already work with.
2.4.9 is the newest line, released on May 12, 2026, with support out to May 2029. It gives you the longest runway and the latest features, at the cost of being the freshest release, where some third-party extensions and custom code may need more work to catch up. If you have the appetite and the testing budget, it is a fine choice, especially for a store that would rather modernise in one move than two.
For the mechanics of the move itself, the jump we most often make, from 2.4.7 to 2.4.8, is written up step by step in our guide to upgrading Magento 2 to 2.4.8, and the same shape applies coming from 2.4.6.
The PHP Jump Hiding Inside the Upgrade
Here is the part that catches teams off guard. Moving off 2.4.6 is rarely just a Magento upgrade, it is usually a PHP upgrade at the same time. Magento 2.4.6 runs on PHP 8.1 and 8.2, and both of those are at or near the end of their own support lives, with 8.1 already past it. The newer Magento lines require newer PHP: 2.4.8 wants PHP 8.3 or 8.4, and 2.4.9 moves to PHP 8.4 and adds support for 8.5, dropping the older versions along the way.
That matters because a PHP major-version jump is exactly where custom modules, older extensions, and crusty theme code tend to break. The Magento upgrade and the PHP upgrade have to be planned and tested together, on a staging environment, with every extension and custom integration exercised before anything touches production. Treating it as a one-line version bump is how a planned upgrade turns into an unplanned outage.
What to Do Before August
This is a deadline you can see coming, so the work is planning, not panic.
- Confirm exactly which version and PHP you are running today. A surprising number of stores are not sure, and the answer changes the plan.
- Choose a destination deliberately: 2.4.8 for the balance of stability and runway, or 2.4.9 if you want the newest and can absorb more testing. Do not land on 2.4.7.
- Rebuild the upgrade on staging first, with the matching PHP version, and test every extension, payment method, and custom integration before you schedule the production window.
- Budget for extension and theme compatibility work. The core upgrade is usually the easy part, the third-party code around it is where the time goes.
- If you genuinely cannot complete the upgrade before August 11, do not simply ignore it. Accept that you are running unpatched, tighten what you can with a web application firewall and virtual patching as a stopgap, and treat the upgrade as urgent rather than optional. A firewall in front of an unsupported platform buys time, it does not fix the problem.
The blunt version is this. For an Open Source 2.4.6 store, August 11 is not a suggestion, and there is no extension to buy. The stores that treat July and August as their upgrade window will move calmly. The ones that wait for the first post-deadline security bulletin to scare them will move in a hurry, which is the most expensive way to do it.
If you run Magento Open Source and want an honest assessment of which version to move to, what your extensions will need, and how to sequence the Magento and PHP upgrades without downtime, that is exactly what our Magento and migration work covers, from the staging rehearsal to the production cutover.
Sources
Talk to the engineer who will own your stack.
No account managers, no offshore handoff. Senior DevOps, direct. Tell us what you are dealing with and you get a straight answer.