On 31st May 2027 Adobe’s standard support for Magento Open Source and Adobe Commerce 2.4.7 ends, so Open Source stores on 2.4.7 stop receiving security fixes while Adobe Commerce licence holders get one more year, and either way the upgrade to 2.4.8 or 2.4.9 needs planning now because PHP 8.2 runs out first, on 31st December 2026.
Rowan BurgessFounder, Refined Commerce Open Source ended 11th August 2026. Commerce extended to 31st August 2027, then security-only to 31st May 2028.
Standard support ends 31st May 2027. Adobe Commerce extended to 31st May 2028.
Released 8th April 2025. Supported to 31st May 2028.
Released 12th May 2026. Supported to 31st May 2029.
If your store runs Magento 2.4.7, you have a date: 31st May 2027. It is not a sales deadline invented by an agency; it is Adobe’s own lifecycle policy, and it is useful precisely because it is fixed. What follows is the policy in plain words, the PHP date that arrives first, what changes for Open Source and Adobe Commerce, and what we tell merchants who ask what to do about it.
On 31st May 2027 for standard support, which is all a Magento Open Source store receives. Adobe’s lifecycle policy gives each release line three years of standard support from general availability: quality fixes, security patches and, for Adobe Commerce, Adobe’s support. 2.4.7 became generally available on 9th April 2024 and its standard support ends on 31st May 2027. Adobe Commerce customers on 2.4.7 then get one year of extended support at no extra cost, to 31st May 2028. Adobe’s release policy states that extended support security patches are for Adobe Commerce customers only and are not available for the Magento Open Source code base.
| Release line | Released | Standard support ends | Adobe Commerce only | Cloud enforcement |
|---|---|---|---|---|
| 2.4.6 | 14th March 2023 | Ended 11th August 2026 | Extended to 31st August 2027; security-only to 31st May 2028 | 1st June 2028 |
| 2.4.7 | 9th April 2024 | 31st May 2027 | Extended to 31st May 2028 | 1st June 2028 |
| 2.4.8 | 8th April 2025 | 31st May 2028 | Not yet set | Not yet set |
| 2.4.9 | 12th May 2026 | 31st May 2029 | Not yet set | Not yet set |
Two things stand out. Each window is short: a store that moves to 2.4.8 now has until May 2028, and one that moves to 2.4.9 has until May 2029, so upgrading is a recurring job, not a one-off. And the extended columns apply to Adobe Commerce only; an Open Source store on 2.4.7 has the May 2027 date and nothing after it.
The store keeps trading; the fixes stop. On 1st June 2027 nothing visible changes on a self-hosted Open Source store. Orders arrive, the Admin opens. What changes is that when Adobe next fixes a vulnerability, the bulletin lists fixed versions for the supported lines and not for yours. Adobe now publishes those bulletins monthly, and each one describes what it fixed, so an unsupported store collects documented, unfixed flaws month by month. That is why the stores we find hijacked are overwhelmingly on old releases: not because old code is worse, but because its flaws are public and still open.
Only if it is on 2.4.7-p10 with every monthly isolated patch since July 2026 applied, plus September’s hotfix. Adobe released 2.4.7-p10 on 12th May 2026, the last -p release so far. From July Adobe switched to a monthly isolated patch for each line, built on the previous month’s and applied in order on top of the latest -p release; the bulletins name the result 2.4.7-2026-jul, -aug, -sep and -oct. The September hotfix for CVE-2026-75650, an exploited flaw rated 10.0, is not part of that chain and must be applied separately. A store on any earlier -p version has to reach p10 before it can take this year’s monthly fixes. How the chain works is explained in Magento security patches explained.
Because PHP 8.2 runs out on 31st December 2026, five months before 2.4.7 does. Adobe’s system requirements pair 2.4.7-p10 with PHP 8.3 or 8.2. According to php.net, PHP 8.2 receives security fixes until 31st December 2026 and PHP 8.3 until 31st December 2027. Adobe’s lifecycle policy says it does not fix PHP or other third-party dependencies and warns that running an end-of-life PHP puts PCI compliance at risk, leaving the assessment to the merchant and their assessor. So a 2.4.7 store on PHP 8.2 has a December deadline, not a May one, and should move to PHP 8.3 this winter whatever it decides about Magento.
They tend to stay for years, and many end up compromised. In February and March 2026 we looked for every Magento store on the .co.uk web and read what each one shows the world. Two figures answer the question. 916 UK stores were still running Magento 1, whose final security patches Adobe published in June 2020. And 722 UK Magento stores were already hijacked and serving spam pages to search engines, almost all on unsupported releases. Merchants on old releases did not decide to run an insecure store; they decided to deal with the upgrade later, and later did not arrive before the attacker did.
Upgrade in place, upgrade and move to Hyvä, or move to Shopify. We offer all three, so we have no reason to steer you towards one.
The smallest change: keep the frontend, extensions and integrations and move to a supported release on a supported PHP. 2.4.9 is supported a year longer than 2.4.8 and Adobe pairs it with PHP 8.5. The work is in testing every extension and integration against the new release on staging, with the shop trading throughout. Mage-OS, a community distribution currently based on 2.4.9, is a variant of this path for Open Source merchants who prefer community governance.
If the store still runs Magento’s Luma frontend, the upgrade is the natural moment to replace it. Hyvä keeps the Magento platform, catalogue, orders and integrations, and replaces the storefront with a much lighter one; doing both at once means one round of testing and one deployment. Hyvä’s documentation lists 2.4.7-p1 or higher among its supported versions.
Some merchants look at an upgrade every year or two and conclude Magento is more platform than they need. Shopify removes the support calendar because Shopify runs the platform. It is the biggest change of the three, with real trade-offs in URLs, product structure and checkout, and it suits some stores far better than others; we set out the trade in what a Magento to Shopify migration involves.
Close the patch gap this month, fix PHP before December, and finish the upgrade well before May.
Every date, version and bulletin number in this article was checked against the publisher’s own page on . Where a page changes after that date, the publisher’s page is the authority.
No. Nothing changes on the day for a self-hosted store. Orders keep coming in; what stops is Adobe’s fixes for Magento Open Source 2.4.7. Every vulnerability found afterwards stays open unless someone backports the fix. On Adobe Commerce on Cloud the position is different, with enforcement from 1st June 2028.
2.4.9 buys a year more: Adobe supports it to 31st May 2029 against 31st May 2028 for 2.4.8. Adobe’s system requirements pair 2.4.9 with PHP 8.5, which has security support until 31st December 2029. The deciding factor is usually extension readiness: every extension needs a version for the target release.
For a while. Backports are a reasonable bridge for a store already planning its upgrade, and we do them. As a permanent strategy they cost more each month, especially now that Adobe’s fixes arrive as a monthly chain of isolated patches, and they leave the store on an ageing PHP, which raises the PCI question regardless.
Not fully. Adobe’s monthly isolated patches since July 2026 apply only to the latest -p release for each line, which for 2.4.7 is 2.4.7-p10, released on 12th May 2026. A store on an earlier -p must reach p10 before it can take July, August, September and October’s patches, in that order.
Not past December. PHP 8.2 receives its last security fixes on 31st December 2026, according to php.net. 2.4.7 also runs on PHP 8.3, which is supported until 31st December 2027, so a 2.4.7 store still on PHP 8.2 should move to 8.3 this winter even if the Magento upgrade comes later.
Which Magento Open Source release lines still receive fixes, how that differs from Adobe Commerce, what happened to Magento 1 and what running an unsupported version risks.
What an Adobe security bulletin tells you, how -p releases, isolated patches and hotfixes fit together, what changed in July 2026 and how quickly to act on each priority.
The honest trade: what Shopify takes off your plate, what it asks you to give up, how products, customers, orders and URLs move, and where migrations go wrong.
Give us the address and we will read what the store already shows the world: release, support status, PHP, headers, hosting and any sign of a hijack. One page, by email, within two working days. Nothing is accessed or tested.
What we would do first. Apply the outstanding security fixes, then plan the upgrade to a supported release.
