Magento 2.4.7: standard support ends on May 31, 2027

The date for Magento 2.4.7 is set: standard support ends on May 31, 2027, the end of the phase in which Adobe ships quality fixes and security patches for this release line (Lifecycle Policy). There is a free extension until May 31, 2028, but Adobe explicitly names only Adobe Commerce customers, the licensed edition. If you run Magento Open Source, you should therefore treat May 2027 as the date that counts. That is our conclusion from the wording and from how older release lines were handled, not a literal commitment, and we explain it below. This article puts the deadlines in context, shows how PHP and the database fall into the same period and helps you decide between an upgrade to 2.4.8 or 2.4.9 and a switch to Shopware. Our Magento agency is ready to carry out either path.

What Adobe has set for Magento 2.4.7

Adobe grants every version a standard support window of three years from the general availability date (Lifecycle Policy). Magento 2.4.7 was released on April 9, 2024, and standard support ends on May 31, 2027 (Lifecycle Policy). Within this window there are quality fixes, security patches and full support from Adobe (Lifecycle Policy). Security fixes arrive as cumulative patch releases with the suffix -p, and individual patch files and hotfixes are added for urgent cases.

Ten such patch releases have been published for 2.4.7 so far, from 2.4.7-p1 in June 2024 to 2.4.7-p10 on May 12, 2026 (Released Versions). The second-to-last release for 2.4.7 came on March 10, 2026 (Released Versions). Beyond the planned dates, Adobe may release further security patches, but explicitly does not commit to them (Patch Release Schedule).

Since 2.4.7, the standard windows all end on May 31, roughly three years after the release line came out (Lifecycle Policy). If you are on 2.4.7 today, only the months until the end of May 2027 remain before standard support ends. If you are on 2.4.6, that end is already behind you: standard support for 2.4.6 expired on August 11, 2026 (Released Versions).

Adobe offers one year of additional support at no additional cost for Adobe Commerce customers on versions 2.4.6 and 2.4.7.

Adobe, Adobe Commerce lifecycle policy

What the end means for Magento Open Source

The words Magento and Open Source do not appear on the lifecycle page. It refers to Adobe Commerce throughout, and the additional year explicitly applies to its customers (Lifecycle Policy). Adobe is clearer elsewhere: the notes on the security patches for 2.4.5 state that extended support security patches are available to Adobe Commerce customers only (Security Patch Notes 2.4.5). They are not available for the Magento Open Source code base (Security Patch Notes 2.4.5). For 2.4.6, whose extension began in August 2026, Adobe writes that these provisions are available to Adobe Commerce customers only (Security Patch Notes 2.4.6).

The public repository of Magento Open Source shows what this looks like in practice. There, the series of patch tags ends at 2.4.4-p13 for 2.4.4 and at 2.4.5-p14 for 2.4.5 (GitHub magento/magento2). 2.4.4-p13 was released on April 8, 2025, shortly before standard support for that line ended on April 12, 2025 (Released Versions). 2.4.5-p14 was released on August 12, 2025, the day standard support for 2.4.5 ended (Released Versions). For Adobe Commerce, both lines continued afterwards, up to 2.4.4-p18 and 2.4.5-p17 on May 12, 2026 (Released Versions).

For 2.4.6, no further patch release has appeared since standard support ended. The last one, 2.4.6-p15 from May 12, 2026 (Released Versions), is also available as a tag in the public repository (GitHub magento/magento2). Whether this line behaves like 2.4.4 and 2.4.5 will become clear with the next patch date.

PHP, database and search service: more deadlines

The end of Magento support is not the only deadline affecting a 2.4.7 store. Adobe explicitly does not provide security and quality fixes for dependencies such as PHP and MySQL, even if they reach end of life during the support period (Lifecycle Policy). 2.4.7-p10 is tested with PHP 8.2 and 8.3 (System Requirements). Security support for PHP 8.2 ends on December 31, 2026, for PHP 8.3 on December 31, 2027 (php.net). A store that still runs 2.4.7 on PHP 8.2 therefore loses PHP security fixes months before Magento standard support ends.

Adobe links this to PCI compliance: for PHP 8.2, the Lifecycle Policy sees PCI compliance at risk from the end of 2026 and advises planning an upgrade or migration before then (Lifecycle Policy). The table there lists only 2.4.6 as the affected release line; in our assessment, the reason, a PHP version without security fixes, applies equally to a 2.4.7 store on PHP 8.2. Whether a store meets the requirements of the card payment standard is for the merchant to assess (Lifecycle Policy). If the store still runs on PHP 8.2, moving to PHP 8.3 is therefore the first step, regardless of how the big decision turns out. Our article on the end of support for PHP 8.2 describes a PHP switch with a staging test using WordPress as the example, and the approach carries over to Magento.

On the database side, one deadline has already passed. MySQL 8.0 reached its end of support on April 30, 2026 (System Requirements). 2.4.7 does not support MySQL versions released after MySQL 8.0 (System Requirements). Adobe therefore strongly recommends that operators of 2.4.7 on their own servers move to a compatible MariaDB version (System Requirements). What to check when changing the database version is covered in our article on the end of support for MySQL 8.0.

Server requirements of the three target releases

The table shows the tested versions for running on your own servers (System Requirements). Every upgrade therefore also moves the server environment. 2.4.9 is tested only with PHP 8.5 and OpenSearch 3, and Elasticsearch and Redis are no longer listed for this release line (System Requirements). Adobe supports only the combinations listed there (System Requirements). Store and server therefore belong in one plan. If your store runs on our hosting, we plan both together.

Path 1: upgrade to Magento 2.4.8

2.4.8 has been available since April 8, 2025 and receives standard support until May 31, 2028 (Lifecycle Policy). That is one year more than 2.4.7. It is the smallest step of the three paths: the line is tested with PHP 8.3 and 8.4, including the PHP version a 2.4.7 store should move to anyway (System Requirements). PHP 8.4 receives security fixes until December 31, 2028 and thus covers the entire standard window of 2.4.8 (php.net).

2.4.8 also solves the database question, since the line is tested with MySQL 8.4 as well as MariaDB 11.4 and 11.8 (System Requirements). The downside: if you choose 2.4.8, you will face the same decision as today in spring 2028. For stores whose extensions are not yet released for the newest line, 2.4.8 is still often the sensible intermediate step.

• Many third-party extensions: 2.4.8 has been on the market longer than 2.4.9, so vendors have had more time for compatible releases.
• Little time until May 2027: going from 2.4.7 to 2.4.8 is only one version step, so the staging trial and go-live can be completed faster.
• Platform switch planned anyway: if you want a different system in the medium term, 2.4.8 bridges the time until then without sitting on a release line without patches.

Path 2: jump to Magento 2.4.9

2.4.9 was released on May 12, 2026 and receives standard support until May 31, 2029, two years longer than 2.4.7 (Lifecycle Policy). The line is tested with PHP 8.5 (System Requirements), whose security support runs until December 31, 2029 (php.net). If you are setting up an upgrade project now anyway, 2.4.9 gives you the longest window.

The longer period comes at a price. Going from 2.4.7 to 2.4.9 takes two version steps, PHP moves from 8.3 via 8.4 to 8.5, and the server environment changes in several places at once (System Requirements). Every extension, every theme and every custom module has to run on the new PHP version. For stores with a few well-maintained extensions, this is quite manageable. For stores with many older modules, 2.4.9 quickly turns into a project that comes close to a platform switch in scope.

• List of all extensions with version, vendor and release status for the target version
• Custom modules and theme: changes to core classes, plugins and preferences in the dependency injection system
• Integrations with ERP, payment providers and shipping, see our integrations
• Server environment: PHP, database, OpenSearch, cache and message queue against the system requirements
• Staging environment with current data, but without real payments and without emails to customers
• Way back: a tested backup of code and database before go-live

If an ERP system is connected, check the integration with every version jump. Our article JTL-Wawi 2.x: check the shop integration before the version jump shows what that looks like in practice, and the checks carry over to other systems.

Path 3: switch to Shopware

An upgrade keeps the existing store, a switch replaces it. It pays off above all when an upgrade to 2.4.9 would require many modules to be rebuilt anyway, when the team finds running Magento demanding or when the next fundamental decision should not wait until 2029. Shopware 6.7 is released under the MIT license (GitHub shopware/shopware) and allows PHP 8.2 to 8.5 (GitHub shopware/shopware). The next major version, 6.8, is planned for 2027 (Shopware announcement). A switch that goes live in 2027 should take this date into account from the start.

Shopware's migration path covers most of the data move: categories, customers with addresses, orders, products with variants, properties, images, reviews and stock can be transferred (Shopware docs on Magento migration). Order status, payment methods and tax rates are assigned manually through a pre-mapping step (Shopware docs on Magento migration). Pages and blocks from the Magento CMS are missing from this list, and in the section on media the documentation states that CMS data cannot be migrated (Shopware docs on Magento migration). Content pages, landing pages and blocks are therefore rebuilt in Shopware.

The bigger effort rarely lies in the data but in functionality: whatever runs in Magento through extensions or custom modules is mapped in Shopware through existing features, extensions or custom development. We develop B2B features such as customer accounts with approvals or customer-specific prices to fit the actual need. Redirects for all previous URLs belong in every switch so that search engines and visitors find the new pages. Our guide to migrating from Magento to Shopware 6 describes the general process, and you will find the matching services under Shopware migration.

Day-to-day work in the back end also changes with the system, and the team needs training for it. How phone and email orders are entered in the Shopware admin, for example, belongs in the planning of a switch, not in the week after go-live.

Upgrade or switch: making the decision

Which path fits depends less on the calendar than on the state of the store. The comparison sums up how the three paths differ.

As a rule of thumb: if the store can be raised to 2.4.8 in a staging environment with reasonable effort, that is the shorter path to May 2027. If the inventory already shows that several central modules would have to be redeveloped, the switch deserves serious consideration.

Schedule until the end of May 2027

There is less time until the end of May 2027 than it seems, because the holiday season, the turn of the year and stocktaking fall right in the middle. A realistic sequence for an upgrade looks like this:

1. November 2026: inventory of extensions, custom code, integrations and server environment; move from PHP 8.2 to 8.3 if not done yet.
2. December 2026: decision between 2.4.8, 2.4.9 and a switch, based on a first upgrade trial in the staging environment. PHP 8.2 should be replaced by December 31, 2026 (php.net).
3. January to March 2027: update or replace extensions, adapt custom modules, switch database and search service.
4. April 2027: acceptance in the staging environment with test orders across all payment and shipping methods and a load test.
5. May 2027: go-live with a buffer before May 31, then monitoring of error logs and orders.

Until the change: securing the 2.4.7 store

CVE-2025-54236 shows how serious gaps in Magento can become. The vulnerability could be exploited without authentication, received a CVSS base score of 9.1 and allowed attackers to take over sessions (NVD). In October 2025, the US cybersecurity agency CISA added it for Adobe Commerce and Magento to its catalog of known exploited vulnerabilities (NVD). For 2.4.7, it is fixed in patch release 2.4.7-p8, and Adobe had already published a hotfix in September 2025 (Security Patch Notes 2.4.7). For CVE-2024-34102, Adobe had already reported known attacks on merchants, albeit very limited ones (Security Patch Notes 2.4.7).

• Install the latest patch release: for 2.4.7, that is currently 2.4.7-p10 (Released Versions). Isolated security patches can only be applied to the latest -p release of a line (Patch Release Schedule).
• Do not treat hotfixes as a substitute: a hotfix like the one from September 2025 closes a single vulnerability. It does not resolve all issues that an upgrade to the latest release fixes, however (Lifecycle Policy).
• PHP 8.3 instead of 8.2: this removes the end of 2026 as a PHP deadline (php.net).
• Database on MariaDB: MySQL 8.0 is past its end of support, and for 2.4.7 Adobe recommends a compatible MariaDB version (System Requirements).
• Restrict access: make the admin area reachable only from fixed addresses or with an additional sign-in factor, and remove unused integrations and access keys.
• Set up monitoring: watch error logs, file changes and unusual orders so that an attack is noticed early.

For merchants in the EU, this also has a legal side. Under Art. 32 GDPR, controllers implement appropriate technical and organizational measures, taking into account the state of the art, to ensure a level of security appropriate to the risk (GDPR). Whether a store meets this has to be assessed case by case. Software for which the vendor no longer publishes security fixes certainly does not make that case easier.

How we support an upgrade or a switch

We look after Magento stores and build stores with Shopware. That is why we assess both paths side by side without anticipating the result. It starts with an inventory and an upgrade trial, after which you decide on the basis of an effort estimate for each path.

If you are not sure which path fits your store, we can clarify it in an initial consultation.