What "end of support" changes for a 2.4.6 store
According to the lifecycle table published by Adobe, standard support for 2.4.6 ended on August 11, 2026. Since then, a store that stays on 2.4.6 no longer receives quality or security fixes under standard support.
Adobe provides one year of extended support, until August 31, 2027. It carries no extra cost, but it is reserved for Adobe Commerce customers on versions 2.4.6 and 2.4.7.
For an agency, the question is therefore no longer "should we upgrade?" but "to which version, with which procedure, and on what date?". An online store carries a catalogue, payments and orders: you do not change its stack on a Friday evening directly in production.
What being out of support means in practice
- No more standard fixes — quality and security fixes for 2.4.6 are no longer released under standard support; only extended support, reserved for Adobe Commerce, extends the arrangement.
- PCI requirement — Adobe's upgrade overview states that merchants must be on the latest patch or security patch for PCI compliance. A frozen stack falls outside that frame.
- A stack that ages around Magento — Adobe notes that MySQL 8.0 reached end of support on April 30, 2026 and Elasticsearch 7.17 on January 15, 2026, and recommends migrating to MariaDB and OpenSearch.
- Extensions to requalify — every third-party extension must be checked against the target version before you set a date. A single blocking extension is enough to shift the whole schedule.
- A reprieve, not a target — extended support buys time, not a destination: 2.4.7 itself leaves standard support in May 2027.
- A fleet running at several speeds — if your clients have stores on 2.4.6, 2.4.7 and 2.4.8, you need a single tracking table, not one memory per client.
Reading Adobe's calendar without mistaking the scope
Adobe's lifecycle policy page defines standard support as a three-year period from general availability. It covers quality fixes, security fixes and support.
Mind the scope: this table is written for Adobe Commerce. It does not mention Magento Open Source. If your clients are on Open Source, do not adopt these dates as theirs. Check them with Adobe, and in the meantime plan for the unfavourable case, a version that no longer receives fixes. This article deliberately gives no end-of-support date for Open Source.
Support dates read on the Adobe page (Adobe Commerce)
Scroll the table
| Version | End of standard support | End of extended support |
|---|---|---|
| 2.4.6 | August 11, 2026 | August 31, 2027 |
| 2.4.7 | May 31, 2027 | May 31, 2028 |
| 2.4.8 | May 31, 2028 | Not stated on the page |
| 2.4.9 | May 31, 2029 | Not stated on the page |
Choosing the target: 2.4.7, 2.4.8 or 2.4.9
2.4.9 has been available since May 12, 2026 and its standard support runs until May 31, 2029: it is the target that gives the most runway. 2.4.7 leaves standard support in May 2027; stopping there means repeating the same operation before then. 2.4.8 offers an intermediate step until May 2028.
The calendar does not decide alone. Two criteria weigh more. The first is the client's extension list: an extension with no version compatible with 2.4.9 requires either a patch or a lower step. The second is the server stack gap, which grows with every version skipped and which you read in the next table.
The 2.4.9 server stack: what changes before Composer even runs
Adobe supports only the combinations listed on its system requirements page. The note on that page is explicit: 2.4.9 is tested with MariaDB 12.3, so the database is upgraded before Magento.
The table compares 2.4.6-p15 and 2.4.9 for an on-premises installation, as the Adobe page describes it for Adobe Commerce. For Open Source, confirm each row at the same source before ordering or reconfiguring a server.
On-premises requirements read on the Adobe page
Scroll the table
| Component | 2.4.6-p15 | 2.4.9 |
|---|---|---|
| PHP | 8.2 or 8.1 | 8.5 |
| Composer | 2.2.26 and above | 2.10 |
| OpenSearch | 2.19 or 3 | 3 |
| MariaDB | 10.11 | 12.3 |
| MySQL | Not supported | 8.4 |
| Valkey | 8.1 | 9.0 |
| RabbitMQ | 4.3 | 4.3 |
| nginx | 1.30 | 1.30 |
| Varnish | 8 | 9 |
One point stands out in this table: no PHP version is common to 2.4.6 and 2.4.9. PHP therefore changes at the same time as the code, and the database goes from MariaDB 10.11 to 12.3. This is not a patch upgrade, it is a stack migration. It is rehearsed on a separate machine, with the same versions as the target, before being played in production.
The short-cutover plan: a parallel stack, staging first
The safest approach is not to touch the production stack in place. Build a staging stack with the target versions from the table, restore a copy of the database and media into it, replay the upgrade end to end and time each step. If the rehearsal fits a window the merchant can accept, you replay it identically in production.
Otherwise, prepare a second production stack, resynchronise the database just before the switch and send traffic to it at the last moment. The interruption is limited to the switch, which you place in off-peak hours, and the original stack stays intact as a rollback.
That leaves the question every agency asks: who carries the client relationship and the risk? The merchant relationship and the procedure stay with you. On the infrastructure side, you get separate staging and production servers, root access to align PHP, the search engine and the database, and snapshots before every upgrade.
Composer upgrade procedure, to rehearse in staging first
Freeze the starting point
Take a server snapshot and a database export before any command. Record the exact version with
bin/magento --versionand the package list withcomposer show.Align the stack
On the target stack, install the versions from the table: PHP, Composer, OpenSearch, MariaDB. Check them with
php -vandcomposer --versionbefore going further.Enable maintenance mode
Run
bin/magento maintenance:enable. In staging, this is a habit to rehearse so you can measure the real length of the downtime.Stop cron and drain the queues
Remove cron with
bin/magento cron:remove, then drain the consumers withbin/magento cron:run --group=consumers. Wait for processing to finish, which you follow withps aux | grep 'bin/magento queue'.Back up the Composer file
Copy the file with
cp composer.json composer.json.bak. It is your safety net if dependency resolution goes the wrong way.Request the target version
Use
composer require-commerce, notcomposer require:composer require-commerce magento/product-community-edition <target version> --no-update. For Adobe Commerce, the package ismagento/product-enterprise-edition. This command assumes themagento/composer-root-update-pluginplugin is installed, as Adobe's prerequisites require.Update the dependencies
Run
composer updateand read the output to the end: an extension conflict announces itself there before any damage. An extension that caps the Magento version is fixed here, not in production.Clean up, then migrate
Delete the contents of
var/cache/,var/page_cache/andgenerated/code/, then runbin/magento setup:upgrade. Depending on your deployment mode, then replaybin/magento setup:di:compileandbin/magento setup:static-content:deploy; the Adobe page consulted does not detail these two commands, so follow your usual procedure.Reopen and verify
Run
bin/magento maintenance:disable, reinstall cron withbin/magento cron:installand restart Varnish if it is used. Then walk through the store: catalogue, search, cart, test payment, order e-mails.
Plan the rollback before starting the upgrade
A snapshot restores the state of the whole server, a database backup restores only the data: the difference is explained in VPS snapshot vs backup. Test the restore in staging before the upgrade date.
A rollback is only clean as long as no order has been placed on the new stack. Beyond that, those orders must be replayed by hand: decide in advance the moment after which there is no going back.
Troubleshooting: the errors that keep coming back during an upgrade
These messages come from Adobe's documentation and from Composer. Each has a remedy, and none should be fixed in production.
Error messages and remedies
Your requirements could not be resolved to an installable set of packages— Composer refuses the requested combination. Either the machine's PHP is outside the versions supported by the target, or a third-party extension caps Magento. Runcomposer why-not magento/product-community-edition <target version>to see what blocks.- Warning about conflicting root values — with no option, Composer keeps your custom values and shows a warning.
--interactive-root-conflictslets you review them one by one;--force-root-updatesoverwrites your values with Adobe's, to be reserved for projects with no customisation. We're sorry, an error has occurred while generating this email— Adobe says to reset file ownership and permissions as root, then clearvar/cache/,var/page_cache/andgenerated/code/before reloading the store.- Package
magento/inventory-composer-installermissing — for an upgrade from 2.3 to 2.4.6-p13, Adobe asks you to runcomposer require magento/inventory-composer-installerfirst, the package being missing from that version.
Industrialising the upgrade across the whole fleet
A successful upgrade on one store is worth little unless it becomes routine. Keep a table per client with the Magento version and patch, PHP, the database, the search engine, the extension list and the date of the last staging rehearsal. Adobe recommends upgrading every patch cycle: that rhythm is what keeps you from landing in the same emergency in two years.
The fleet's other deadlines are in the 2027 end-of-life calendar, and the PHP-side checklist is in PHP 8.2 end of life: planning your migration. Align the three on a single maintenance calendar.
Inventory the stores still on 2.4.6, with their edition (Adobe Commerce or Open Source) and their extensions. Choose the target, 2.4.9 in most cases. Build the staging stack with the versions from the table, rehearse the procedure and note the length of each step. Then give the merchant a switch date, a window and a point of no return. The rest is no longer improvisation, it is a planned operation.
