Magento 2.4.8 Upgrade Checklist: Step by Step

Most Magento upgrades that go wrong do not fail because of Magento itself. They fail because the server stack was not ready, a third party extension was never checked, or the team found out on launch night that a custom checkout plugin depends on a method that changed. A 2.4.8 upgrade is a project with a few predictable phases, and treating it that way removes most of the risk.

This is the checklist I follow when moving a store from 2.4.4, 2.4.5, 2.4.6 or 2.4.7 to 2.4.8. It applies to Magento Open Source and Adobe Commerce. Where something only exists in Adobe Commerce, I say so.

1. Decide the exact target version

Do not upgrade to plain 2.4.8. Adobe ships security patch releases on top of each minor version, named 2.4.8-p1, 2.4.8-p2 and so on. Check the release notes and target the latest patch release available when you start the project, then plan to apply newer patch releases as they come out. If the project runs for several weeks, a new patch release may appear in the middle, so keep the version in one place in your notes and update it before go live.

Read the release notes for every minor version between your current one and 2.4.8, not only the 2.4.8 notes. If you are on 2.4.6, the changes from 2.4.7 matter as much as the ones from 2.4.8. A known example is the Content Security Policy change in 2.4.7, where checkout pages moved to restrict mode. Any inline script on checkout that is not whitelisted or loaded the right way will stop working.

2. Prepare the stack

2.4.8 targets PHP 8.3 and 8.4. Check the official system requirements page for the exact supported versions of each service, because Adobe updates it with patch releases. The services you need to compare against your current setup are:

• PHP version and extensions (bcmath, intl, soap, sodium, xsl, zip, gd, and the rest from the requirements page)
• MySQL or MariaDB version
• OpenSearch version. If you still run Elasticsearch, plan the move to OpenSearch before the upgrade, because current releases are tested against OpenSearch
• Redis or Valkey, RabbitMQ and Varnish versions
• Composer 2 version

Upgrade the services in your local environment first and keep the old Magento version running on them where possible. A Magento 2.4.7 store on PHP 8.3 is a valid combination, so you can split the PHP upgrade from the Magento upgrade and find problems one at a time. I wrote more about that part in the PHP 8 compatibility guide.

3. Inventory the code

Before touching Composer, list what will need attention:

bin/magento --version
bin/magento module:status --disabled
composer show --direct
ls app/code

Split the result in three groups:

• Composer extensions from vendors. For each one, find the version that declares support for 2.4.8 and the PHP version you are moving to. Some vendors publish this only in their changelog, so check there too.
• Custom code in app/code. This is yours to fix. Plugins and preferences on core classes are the highest risk, because a changed method signature breaks them at runtime or at compile time.
• Disabled or unused modules. This is a good moment to remove them instead of carrying them forward. See how to remove a module safely.

Adobe Commerce customers can run the Upgrade Compatibility Tool, which compares custom code against the target version and reports uses of removed or changed APIs. On Magento Open Source you get similar coverage, with more manual work, from running PHPStan and the Magento coding standard against app/code after the upgrade.

4. Run the Composer upgrade on a branch

Work on a dedicated branch with a fresh copy of the production database in your local environment. Put the site in maintenance mode locally, then update the root package. The require-commerce command comes from the composer root update plugin and also updates the root composer.json entries that the Magento metapackage expects.

composer require magento/composer-root-update-plugin "^2.0" --no-update
composer update magento/composer-root-update-plugin

composer require-commerce magento/product-community-edition 2.4.8-p3 --no-update
composer update

For Adobe Commerce, the package is magento/product-enterprise-edition. Replace the version string with the patch release you chose in step 1.

The first composer update rarely succeeds on a real store. The usual causes are extensions that pin an older framework version, a vendor package that requires a PHP version range that excludes 8.4, or an old patch in composer.json that no longer applies. Fix each conflict by upgrading the extension or removing it. Do not use --ignore-platform-reqs to force the install, it only moves the error to runtime.

If you apply patches with cweagans/composer-patches, many of them will fail after the upgrade because the fix is already in core. Remove the ones that are included in the new version and rebuild the rest. There is more on this in the Composer patches article.

5. Upgrade the database and compile

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento indexer:reindex
bin/magento cache:flush

setup:di:compile is the first real test of your code. It fails on missing classes, wrong constructor arguments and plugins on methods that no longer exist. Read every error, do not just delete the generated folder and retry.

Then run your own checks:

bin/magento setup:db:status
vendor/bin/phpstan analyse app/code
vendor/bin/phpcs --standard=Magento2 app/code

6. Test what makes money

A full regression test is ideal but rarely affordable. At minimum, test these flows with real data from the copied database:

1. Category page with layered navigation and sorting
2. Product page for each product type you sell (simple, configurable, bundle, grouped)
3. Add to cart, mini cart, cart page with coupon
4. Checkout as guest and as logged in customer, with every active payment and shipping method
5. Order email, invoice, shipment and credit memo in the admin
6. Integrations: ERP export, marketplace sync, feeds, any cron job that talks to an outside system
7. Admin login with two factor authentication, product save, configuration save

Watch var/log/exception.log and var/log/system.log while testing, and check the browser console on checkout for CSP violations and JavaScript errors. Deprecation notices from PHP 8.4 often show up in logs before anything visibly breaks.

Also check the cron and queue consumers. Run bin/magento cron:run a few times and look at the cron_schedule table for jobs in error state. If you use RabbitMQ, confirm the consumers start and process messages.

7. Plan the production release

The production upgrade runs setup:upgrade against the live database, so it needs maintenance mode. Plan the window:

• Take a full database backup and a copy of app/etc/env.php right before starting. See the backup and restore guide.
• Build the code (Composer install, compile, static content) before the window, in a separate release folder, so maintenance mode covers only the database upgrade and the switch.
• Upgrade PHP on the server first, ideally in a separate earlier release with the old Magento version, so a single window does not change everything at once.
• Time setup:upgrade on a copy of production. Large catalogs and big sales tables can make some schema changes slow.
• Write the rollback plan. If the database upgrade has run, rolling back means restoring the backup, so decide in advance how long you will try to fix forward before restoring.

8. After go live

For the first days, watch error logs, the cron schedule, queue consumers and order volume. Compare conversion rate and checkout errors with the week before. Flush and warm the full page cache so the first customers do not pay for cold pages. Then remove the old release folder and any temporary patches, and update your documentation with the new versions of PHP and services.

Finally, set a reminder to apply the next patch release. Upgrading from 2.4.8-p3 to a later 2.4.8-p release is a small change compared to this one, and keeping up with them is the cheapest way to avoid the next large upgrade turning into an emergency.

FAQ

How long does a Magento 2.4.8 upgrade take?

It depends mostly on the number of third party extensions and how much custom code touches core classes. A clean store with few extensions can be done in a few days. A store with dozens of extensions and heavy customization needs weeks, most of it testing.

Can I upgrade directly from 2.4.4 to 2.4.8?

Yes. Composer installs the target version directly and setup:upgrade runs all the schema and data changes in between. You still need to read the release notes for every version you skip.

Do I need to upgrade PHP at the same time?

2.4.8 needs PHP 8.3 or 8.4, so PHP must be upgraded at some point. Doing it first, on the old Magento version where supported, splits the risk into two smaller releases.

Is the Upgrade Compatibility Tool available for Magento Open Source?

It is offered to Adobe Commerce customers. On Open Source you can get similar information from setup:di:compile, PHPStan and the Magento coding standard.

I am available for freelance Magento and Adobe Commerce work, including version upgrades. If you need help with this, get in touch.