Magento is not end of life. Specific Magento versions are, and the gap between those two statements is where store owners get caught. If your store runs on 2.4.4 or 2.4.5, Adobe has already stopped issuing fixes for it. If it runs on 2.4.6, the clock started on 11 August 2026.
The platform itself is in good health: Adobe shipped version 2.4.9 in May 2026 and has published its support dates out to 2029. The question that matters for your revenue is narrower and more personal. Which version is your store on, and is anyone still fixing it?
Adobe publishes a lifecycle table for every 2.4 release. Its page, last updated on 18 September 2026, gives these dates for Adobe Commerce:
Read that list as a shelf of dated stock. The two oldest lines are already expired, the middle one has just turned, and the newest three are comfortably in date. You can read the full table on Adobe's software lifecycle policy page.
Adobe's own wording is plain. Standard support "includes quality fixes, security patches, and full Adobe Commerce on-call support." Extended support covers "quality and security patches for the core application." Once a release leaves both, none of that is coming.
Notice what does not happen. Your store does not go dark on the expiry date. Orders keep flowing, pages keep loading, and usually nothing in the admin warns you. That is exactly why this goes unnoticed. The cost arrives later, as a security flaw found next spring that will never be fixed on your version.
We covered how that plays out in practice in our piece on the September 2026 Magento breaches. A store on a supported release can still be hit before a fix exists. A store on an unsupported one is hit and then never gets the fix at all.
Here is the part most owners miss. Adobe's lifecycle table covers Adobe Commerce. It does not list separate dates for Magento Open Source, and the agencies that track this schedule report that Open Source has no equivalent paid extension to fall back on.
Adobe's security bulletin for August 2026 shows the difference in practice. Published on 11 August, it lists Adobe Commerce releases all the way back to 2.4.4, while for Magento Open Source it stops at 2.4.6. Read the bulletin for yourself: an Open Source store on 2.4.5 was not in the list of releases that received that round of fixes.
So the same version number can mean two very different positions. If you are unsure which edition you run, our comparison of Open Source and Adobe Commerce explains what separates them, and the bill is only part of it.
An unsupported store is a risk you carry, not a bug your team can fix. Three things follow from it.
First, security. Every flaw disclosed after support ends stays open on your version. Attackers read the same bulletins you do.
Second, payments. Card-scheme and PCI expectations assume you run software that still receives security patches. If you take cards on an unsupported release, ask your payment provider or assessor how they view it before they ask you.
Third, everything else gets harder. Extensions and PHP versions move on, and a store several releases behind turns a routine upgrade into a project. The longer you wait, the bigger the jump, which is why ongoing Magento maintenance is cheaper than periodic rescue.
One more practical point. Version numbers in the admin often carry a patch suffix, such as a "-p" followed by a number. That suffix tells you how current you are within a release line, but it does not move you to a newer line. A store can be fully patched and still sit on a release whose support is over.
An upgrade is not a rebuild. It is the same store on a newer release, and for many stores it is the cheaper option by a wide margin compared with replatforming. What it takes is work on the parts around the core: your extensions, your custom code, the server environment and a full test of checkout and payments.
How long it takes depends almost entirely on how many extensions you run and how well they are maintained. A lean store can move in a matter of weeks. A store with years of accumulated modules can take considerably longer, and the unmaintained ones are what stretch the schedule.
Our position is simple. If you are on 2.4.5 or older, treat the upgrade as this quarter's work. If you are on 2.4.6, plan it for the next few months and do not let it drift towards the August 2027 end of extended support. If you are on 2.4.7 or newer, you have breathing room, and your priority is keeping up with patches. When we moved a retailer off end-of-life Magento 1, the lesson was the same one: the cost of waiting is paid in a bigger jump later.
What exact version is our store on? Is it Open Source or Adobe Commerce? Which extensions would block a move to the newest release? And who owns the decision and the budget?
The first question is the one we hear least often answered. On stores we inherit, reading the version off the admin panel is the first thing we do, and it is surprising how many teams cannot say.
If those answers are fuzzy, that is the kind of problem we handle at Encomage. Our engagements usually start with a plain audit of your version, your extensions and your upgrade path, before anyone debates what to fix first.
Let’s build something powerful together - with AI and strategy.
