Magento 2.4.x End-of-Life Calendar: Versions & Dates

The short answer first: Magento 2.4.5 has been out of support since August 12, 2025, Magento 2.4.6 loses support on August 11, 2026, 2.4.7 expires on April 9, 2027, and 2.4.8 (the current last LTS version, GA April 2025) is supported until April 11, 2028. So if you are running 2.4.5 or 2.4.6 today, you do not have much time left to make a decision.

This post is the calendar hub: every date in one place, plus the two things that usually get lost in the EOL conversation: the PHP-EOL risk (PCI) and the question of what a version's end actually means for your frontend. For the deep dive on 2.4.6 specifically, there is a dedicated post linked below.

What the Magento lifecycle policy actually says

Adobe gives every Magento 2.4.x minor version a fixed support window. Rule of thumb: roughly three years of support from General Availability (GA). Within that window you get security patches and quality fixes. Once the window closes, there are no more official security updates for that version. Adobe Commerce (the commercial variant) typically adds another year of extended support on top; Magento Open Source does not.

One thing to be precise about: we are consistently talking about support EOL here, meaning the point at which security patches stop. That is the business-relevant deadline, not some theoretical date when the code dies. After support EOL your version still runs technically, but you are running it without a safety net.

Since early 2026 Adobe has also moved to monthly patch cycles. Every patch needs testing and deploying, and that is exactly where the treadmill starts, which we will come back to.

The Magento 2.4.x End-of-Life calendar

• Version | GA | Support EOL | Status (as of June 2026)
• Magento 2.4.5 | August 2022 | August 12, 2025 | Already expired
• Magento 2.4.6 | March 2023 | August 11, 2026 | Expiring shortly
• Magento 2.4.7 | April 2024 | April 9, 2027 | In support
• Magento 2.4.8 (last LTS) | April 2025 | April 11, 2028 | Current, longest runway

How to read this in practice: if you are on 2.4.5, you are unprotected and should treat it as an acute case. If you are on 2.4.6, you have until August 2026, after which the same problem applies. 2.4.7 gives you some room until 2027, and 2.4.8 is the version with the longest horizon. For Adobe Commerce customers, each date shifts later thanks to the extra year of extended support, but the underlying pattern is identical.

PHP-EOL and the PCI risk that often gets forgotten

A Magento version never expires in isolation. It sits on a PHP version, and PHP has its own lifecycle.

PHP 8.1 fell out of support at the end of 2025. If your 2.4.6 store is still on PHP 8.1, you have a double problem: a soon-to-expire Magento version on an already-expired PHP version. PHP 8.2 reaches EOL at the end of 2026. So the windows close in a staggered way, not all at once.

Why this is business-critical: PCI DSS requires that you do not run unsupported software in the payment environment. An EOL PHP version or an EOL Magento version without security patches can jeopardize your PCI compliance, with direct consequences for your payment provider relationship. This is not an abstract compliance detail; it is a risk that surfaces in an audit and, in the worst case, touches your checkout.

What a version's end means for your frontend

Here is the point most EOL calendars leave out: in a classic Magento setup, your frontend is hard-married to the backend renderer. Luma theme, Hyvä, or PWA Studio render directly against the Magento version. That means every version jump forced by EOL is also a frontend project. You are not just upgrading the commerce engine; you are simultaneously testing and fixing your theme, your extensions, and your custom modules.

With monthly patch cycles this becomes a constant load: patch the backend, retest the frontend, deploy, repeat. That coupling is the expensive part of a Magento lifecycle, not the upgrade itself.

The alternative is to decouple the frontend from the backend renderer. With a Composable Headless Frontend, the frontend layer sits on top of the Magento GraphQL API instead of hanging off the theme renderer. That fundamentally changes the EOL math:

• The frontend depends on the API contract, not the theme engine. A backend patch stays isolated; the frontend does not need to be retested every time.
• Backend version upgrades become pure backend tasks, not a parallel frontend rewrite.
• If you ever want to replatform entirely, say to Adobe Commerce or Shopware, you swap the connector and keep the frontend.

That is exactly Laioutr's Frontend Management Platform (FMP): a Nuxt-based frontend layer that speaks to the Magento GraphQL API, with a Studio editor for marketing, accessibility-compliant components out of the box, and EU hosting. Magento stays your commerce engine; the frontend becomes interchangeable.

What you gain

• Dimension | Classic Magento setup | With a decoupled frontend (FMP)
• EOL upgrade effort | Test backend + frontend together | Backend task, frontend isolated
• Patch-cycle load | Every patch forces a frontend retest | Frontend on the API contract, patch stays isolated
• PCI / PHP-EOL pressure | Frontend trapped on the old platform | Frontend independent of the backend PHP stack
• Replatforming optionality | Rebuild frontend + backend at once | Swap the connector, keep the frontend
• Performance / Core Web Vitals | Tied to the theme engine | Core Web Vitals built into the layer

For more on the patch treadmill versus sustained performance, see our Performance and Core Web Vitals page.

FAQ

What does "Magento 2 end of life" actually mean? It means a given 2.4.x version stops receiving security patches from Adobe after its support EOL. The software keeps running, but without security updates, which creates compliance and security risk.

When is Magento 2.4.6 end of life? Support for Magento 2.4.6 ends on August 11, 2026.

When is Magento 2.4.7 end of life? Support for Magento 2.4.7 ends on April 9, 2027. 2.4.8 (GA April 2025) is the last LTS version and is supported until April 11, 2028.

Is the date different for Adobe Commerce versus Magento Open Source? Yes. Adobe Commerce typically adds one extra year of extended support beyond the regular window. The underlying pattern (roughly three years from GA) stays the same; the specific EOL date shifts later accordingly.

Do I have to replatform because of EOL? No. A version upgrade within Magento is possible. But if the recurring frontend effort on every upgrade is what weighs you down, decoupling the frontend is the more direct lever, and it keeps the replatforming option open for later.

Next step

If your frontend goes back under test with every Magento upgrade, that is the part you can decouple. We show how a [Composable Headless Frontend](https://www.laioutr.com/en/composable-headless-frontend) separates the version's end from the frontend on our [Headless Frontend for Magento 2](https://www.laioutr.com/en/headless-frontend-for-magento-2) page. For the deep dive on 2.4.6 and the patch treadmill specifically, read [Magento 2.4.6 EOL: patch treadmill and decoupling the frontend](https://www.laioutr.com/en/blog/magento-2-4-6-eol-patch-tretmuehle-frontend-entkoppeln).

Learn more about Laioutr at laioutr.com.

Related resources: Composable Headless Frontend and Headless Frontend for Magento 2.

Related reading: Shopify Scripts EOL June 30, Guide for Plus Brands and SAP Accelerator End of Life: Migrating to a Composable Frontend Without Replatforming the Backend.