[{"data":1,"prerenderedAt":236},["ShallowReactive",2],{"seo-verification":3,"blog-magento-2-4-6-end-of-support-upgrade-to-2-4-9-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-magento-2-4-6-end-of-support-upgrade-to-2-4-9-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":174,"ctaBody":175,"ctaButton":176,"ctaUrl":177,"relatedPosts":178},557,"magento-2-4-6-end-of-support-upgrade-to-2-4-9",{"fr":12,"en":10,"ar":13,"es":14},"magento-2-4-6-fin-de-support-mise-a-niveau-2-4-9","ماجنتو-2-4-6-نهاية-الدعم-الترقية-إلى-2-4-9","magento-2-4-6-fin-de-soporte-actualizar-a-2-4-9","Magento 2.4.6 out of support: upgrade to 2.4.9, short cutover","Standard support for Magento 2.4.6 has ended. Adobe's dates, the server stack 2.4.9 needs, and a Composer upgrade rehearsed in staging, with downtime cut to the switch.",9,0,false,"2026-11-01T00:00:00+00:00","2026-11-01T14:14:31+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmagento-2-4-6-fin-de-support-mise-a-niveau-2-4-9-poster.svg","Standard support for Magento 2.4.6 is over, and stores still running it no longer receive fixes under that scheme. For an agency, the risk is not the upgrade itself: it is launching it without having rehearsed it. This guide gives the dates read at the source, the server stack 2.4.9 requires and a Composer procedure you can replay in staging, with a rollback planned before the first order.",[35,39,49,52,74,77,80,120,123,126,157,161,164,171],{"type":36,"title":37,"body":38},"h2","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.\n\nAdobe 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.\n\nFor 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.",{"type":40,"title":41,"items":42},"ul","What being out of support means in practice",[43,44,45,46,47,48],"**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.",{"type":36,"title":50,"body":51},"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.\n\nMind 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.",{"type":53,"title":54,"headers":55,"rows":59},"comparison","Support dates read on the Adobe page (Adobe Commerce)",[56,57,58],"Version","End of standard support","End of extended support",[60,64,68,71],[61,62,63],"2.4.6","August 11, 2026","August 31, 2027",[65,66,67],"2.4.7","May 31, 2027","May 31, 2028",[69,67,70],"2.4.8","Not stated on the page",[72,73,70],"2.4.9","May 31, 2029",{"type":36,"title":75,"body":76},"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.\n\nThe 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.",{"type":36,"title":78,"body":79},"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.\n\nThe 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.",{"type":53,"title":81,"headers":82,"rows":85},"On-premises requirements read on the Adobe page",[83,84,72],"Component","2.4.6-p15",[86,90,94,98,102,106,110,113,116],[87,88,89],"PHP","8.2 or 8.1","8.5",[91,92,93],"Composer","2.2.26 and above","2.10",[95,96,97],"OpenSearch","2.19 or 3","3",[99,100,101],"MariaDB","10.11","12.3",[103,104,105],"MySQL","Not supported","8.4",[107,108,109],"Valkey","8.1","9.0",[111,112,112],"RabbitMQ","4.3",[114,115,115],"nginx","1.30",[117,118,119],"Varnish","8","9",{"type":121,"body":122},"p","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.",{"type":36,"title":124,"body":125},"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.\n\nOtherwise, 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.\n\nThat 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.",{"type":127,"title":128,"steps":129},"steps","Composer upgrade procedure, to rehearse in staging first",[130,133,136,139,142,145,148,151,154],{"title":131,"body":132},"Freeze the starting point","Take a server snapshot and a database export before any command. Record the exact version with `bin\u002Fmagento --version` and the package list with `composer show`.",{"title":134,"body":135},"Align the stack","On the target stack, install the versions from the table: PHP, Composer, OpenSearch, MariaDB. Check them with `php -v` and `composer --version` before going further.",{"title":137,"body":138},"Enable maintenance mode","Run `bin\u002Fmagento maintenance:enable`. In staging, this is a habit to rehearse so you can measure the real length of the downtime.",{"title":140,"body":141},"Stop cron and drain the queues","Remove cron with `bin\u002Fmagento cron:remove`, then drain the consumers with `bin\u002Fmagento cron:run --group=consumers`. Wait for processing to finish, which you follow with `ps aux | grep 'bin\u002Fmagento queue'`.",{"title":143,"body":144},"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.",{"title":146,"body":147},"Request the target version","Use `composer require-commerce`, not `composer require`: `composer require-commerce magento\u002Fproduct-community-edition \u003Ctarget version> --no-update`. For Adobe Commerce, the package is `magento\u002Fproduct-enterprise-edition`. This command assumes the `magento\u002Fcomposer-root-update-plugin` plugin is installed, as Adobe's prerequisites require.",{"title":149,"body":150},"Update the dependencies","Run `composer update` and 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.",{"title":152,"body":153},"Clean up, then migrate","Delete the contents of `var\u002Fcache\u002F`, `var\u002Fpage_cache\u002F` and `generated\u002Fcode\u002F`, then run `bin\u002Fmagento setup:upgrade`. Depending on your deployment mode, then replay `bin\u002Fmagento setup:di:compile` and `bin\u002Fmagento setup:static-content:deploy`; the Adobe page consulted does not detail these two commands, so follow your usual procedure.",{"title":155,"body":156},"Reopen and verify","Run `bin\u002Fmagento maintenance:disable`, reinstall cron with `bin\u002Fmagento cron:install` and restart Varnish if it is used. Then walk through the store: catalogue, search, cart, test payment, order e-mails.",{"type":158,"title":159,"body":160},"tip","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 \u003Ca href=\"\u002Fen\u002Fblog\u002Fvps-snapshot-vs-backup-what-differs-and-how-restore-works\">VPS snapshot vs backup\u003C\u002Fa>. Test the restore in staging before the upgrade date.\n\nA 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.",{"type":36,"title":162,"body":163},"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.",{"type":40,"title":165,"items":166},"Error messages and remedies",[167,168,169,170],"**`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. Run `composer why-not magento\u002Fproduct-community-edition \u003Ctarget version>` to see what blocks.","**Warning about conflicting root values** — with no option, Composer keeps your custom values and shows a warning. `--interactive-root-conflicts` lets you review them one by one; `--force-root-updates` overwrites 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 clear `var\u002Fcache\u002F`, `var\u002Fpage_cache\u002F` and `generated\u002Fcode\u002F` before reloading the store.","**Package `magento\u002Finventory-composer-installer` missing** — for an upgrade from 2.3 to 2.4.6-p13, Adobe asks you to run `composer require magento\u002Finventory-composer-installer` first, the package being missing from that version.",{"type":36,"title":172,"body":173},"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.\n\nThe fleet's other deadlines are in the \u003Ca href=\"\u002Fen\u002Fblog\u002Fend-of-life-calendar-2027-hosting-agencies\">2027 end-of-life calendar\u003C\u002Fa>, and the PHP-side checklist is in \u003Ca href=\"\u002Fen\u002Fblog\u002Fphp-82-end-of-life-planning-your-migration\">PHP 8.2 end of life: planning your migration\u003C\u002Fa>. Align the three on a single maintenance calendar.\n\nInventory 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.","Rehearse every upgrade before production","Staging and production on separate servers, snapshots before every upgrade, and your clients' domains, hosting and VPS centralised under your brand.","Discover the agency space","\u002Fsolutions\u002Fagences",[179,201,221],{"id":180,"slug":181,"slugs":182,"title":186,"excerpt":187,"readTime":188,"views":189,"isPinned":19,"publishedAt":190,"updatedAt":191,"category":192,"categories":198,"featuredImage":30,"bgImage":31,"posterImage":200,"relatedSolution":30},206,"php-82-end-of-life-planning-your-migration",{"fr":183,"en":181,"ar":184,"es":185},"php-82-fin-de-vie-checklist-migration","نهاية-دعم-php-82-دليل-الترحيل","php-82-fin-de-vida-planificar-la-migracion","PHP 8.2 end of life: your migration checklist","PHP 8.2 reaches EOL on December 31, 2026. Inventory your stack, compare PHP versions, and follow a step-by-step migration checklist to PHP 8.3 or 8.4.",11,7,"2026-08-01T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":193,"name":194,"slug":195,"color":196,"icon":197},4,"Development","developpement","bg-warning\u002F10 text-warning","dev",[199],{"id":193,"name":194,"slug":195,"color":196,"icon":197},"\u002Fblog\u002Fcovers\u002Fphp-82-fin-de-vie-checklist-migration-poster.svg",{"id":202,"slug":203,"slugs":204,"title":208,"excerpt":209,"readTime":210,"views":18,"isPinned":19,"publishedAt":211,"updatedAt":212,"category":213,"categories":218,"featuredImage":30,"bgImage":31,"posterImage":220,"relatedSolution":30},520,"end-of-life-calendar-2027-hosting-agencies",{"fr":205,"en":203,"ar":206,"es":207},"calendrier-fins-de-vie-hebergement-2027-agence","جدول-نهاية-الدعم-2027-استضافة-الوكالات","calendario-fin-de-vida-2027-hosting-agencias","2027 end-of-life calendar: PHP, PostgreSQL, Node.js, Ubuntu","Dated calendar from November 2026 to end of 2027: PostgreSQL 14, PHP 8.2, Node.js 22, Ubuntu 22.04. Sources, actions and a method to group work by client.",10,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":214,"name":215,"slug":216,"color":217,"icon":216},3,"Deployment","deploiement","bg-success\u002F10 text-success",[219],{"id":214,"name":215,"slug":216,"color":217,"icon":216},"\u002Fblog\u002Fcovers\u002Fcalendrier-fins-de-vie-hebergement-2027-agence-poster.svg",{"id":222,"slug":223,"slugs":224,"title":228,"excerpt":229,"readTime":17,"views":18,"isPinned":19,"publishedAt":230,"updatedAt":231,"category":232,"categories":233,"featuredImage":30,"bgImage":31,"posterImage":235,"relatedSolution":30},548,"vps-snapshot-vs-backup-what-differs-and-how-restore-works",{"fr":225,"en":223,"ar":226,"es":227},"snapshot-vs-sauvegarde-vps-difference-restauration","اللقطة-مقابل-النسخ-الاحتياطي-للـvps-الفرق-والاستعادة","snapshot-vs-copia-de-seguridad-de-vps-diferencias-y-restauracion","VPS snapshot vs backup: what differs and how restore works","VPS snapshot or backup: what each one protects, what it does not, how restoring works, and a decision rule for the VPS you run for your clients.","2026-10-31T00:00:00+00:00","2026-10-31T19:07:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[234],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsnapshot-vs-sauvegarde-vps-difference-restauration-poster.svg",1793542986660]