Magento 2.4.7 to 2.4.9 Upgrade: The Order to Do It In

The order comes straight from Adobe's on-premises system requirements. Anything that both the latest 2.4.7 patch and 2.4.9 support can change first, while your store is still on 2.4.7. Anything with no overlap has to change during the upgrade itself. This guide covers the order; for what is new in the release, see our Magento 2.4.9 release guide, for the full list of versions our Magento 2.4.9 system requirements, and for support dates our Magento end of life page.

Start from the latest 2.4.7 patch rather than whatever 2.4.7 release you happen to be on. The overlaps in the table above are Adobe's figures for that latest patch, and it also brings the security fixes you should be running anyway while the bigger upgrade is planned. If you are several patches behind, check Adobe's system requirements for your exact patch before changing anything, and see our explainer on Magento security patch releases for how patch versions work.

Each of these can happen on 2.4.7 as a small, separate change, tested and live before you touch the Magento version. Doing them one at a time means that if something misbehaves, you know which change caused it.

• Composer. Both releases list Composer 2.10. Adobe's upgrade prerequisites also ask for the magento/composer-root-update-plugin to be installed before you upgrade.
• Search. 2.4.9 supports only OpenSearch 3, while the latest 2.4.7 patch supports OpenSearch 2.19 and 3. Move to OpenSearch 3 now, reindex, and check your catalogue search on the storefront. If you still run Elasticsearch, this is where it goes. Our OpenSearch for Magento page explains what the search engine does.
• Cache and sessions. Adobe lists Valkey 8.1 and not Redis for the latest 2.4.7 patch, and Valkey 9 for 2.4.9. If you are still on Redis, move to Valkey 8.1 on 2.4.7, then to Valkey 9 as part of the 2.4.9 stack. Our Valkey for Magento explainer covers what changes.

Start this in parallel with step 2, because it usually decides the timeline. List every installed extension and check the vendor's compatibility statement for 2.4.9 specifically, and for PHP 8.5. If a vendor's statement is unclear, ask them before you plan around it.

Adobe Commerce customers can also run Adobe's Upgrade Compatibility Tool, which checks custom modules and core code against a target version. Adobe says it is available for Adobe Commerce instances only, so Magento Open Source stores rely on vendor statements and on testing the store on a staging copy. Custom modules and your theme need the same check from whoever built them.

This is where PHP and the database change, because they cannot change earlier. Build the staging environment on the target stack from the start: MySQL 8.4 or MariaDB 12.3, PHP 8.5, OpenSearch 3 and Valkey 9. Copy the store's files and database across, then run the upgrade on that copy. Adobe's 2.4.9 release notes allow PHP 8.4 for upgrade purposes only, not for production, so the store should go live on PHP 8.5.

For a Composer-based Magento Open Source store, Adobe's upgrade steps run in this order: maintenance mode on, a backup of composer.json, cron removed and queue consumers run, the new version required, dependencies updated, the cache and generated code cleared, the database upgraded, then maintenance mode off.

bin/magento maintenance:enable
cp composer.json composer.json.bak
bin/magento cron:remove
bin/magento cron:run --group=consumers
composer require-commerce magento/product-community-edition 2.4.9 --no-update
composer update
rm -rf var/cache/* var/page_cache/* generated/code/*
bin/magento setup:upgrade
bin/magento maintenance:disable

Adobe warns that the upgrade cannot be easily reversed, which is one more reason to run it on a copy first. Our guide to Magento 2 maintenance mode covers keeping your own access while the store is closed.

Walk the store as a shopper and as your team would: search, category and product pages, basket, checkout with every payment method, shipping rules, customer accounts and the emails they trigger. Then check the back end: admin workflows, cron, message queues and every integration that sends or receives data, such as ERP, stock or feeds. Anything broken is a blocker for the cutover, not something to fix afterwards.

Run a performance check on the upgraded copy too. A new PHP version, a new database version and a new search engine all change how the store behaves under load.

The safest rollback plan is not needing to undo anything. Upgrade onto a separate environment built on the new stack, and leave the old 2.4.7 environment untouched until the new one is signed off. Going back then means pointing traffic at the old environment rather than reversing an upgrade.

• Take full backups of the database, the files and composer.json before the production upgrade, as Adobe advises.
• Lower your DNS TTL in advance if the cutover moves the store to a new server, so the switch takes effect quickly.
• Schedule the cutover for your quietest trading period and keep the maintenance window short. Expect minimum downtime, not zero.
• Decide beforehand how you would handle orders placed on the new environment if you did roll back, because those orders will not exist in the old one.

A Magento upgrade is application work as well as hosting work. On the hosting side, we prepare the 2.4.9 stack and a staging copy of your store on it, and we match the Redis or Valkey version to your Magento version. On the application side, we work alongside your developer or agency on the extensions, custom code and theme. We host Magento on Managed VPS, dedicated servers and High Availability clusters in a UK data centre, and our free migration, with minimum downtime, makes the upgrade-onto-a-new-server pattern above practical.

If you are weighing up a move as well as an upgrade, our managed Magento VPS hosting is built to your Magento version from the start.