Skip to main content

How to Upgrade Magento 2 from 2.4.7 to 2.4.8

5 min read
Upgrade my store to 2.4.8

We check the requirements, run the Composer upgrade on a branch and validate everything after.

Keeping Magento current is critical for security, performance, and compatibility. This step-by-step guide walks developers through upgrading from Magento 2.4.7 to 2.4.8, covering system requirements, pre-upgrade checks, Git workflow, Composer commands, and post-upgrade validation.

Updated September 28, 2026. The requirements now follow Adobe's current table, and the commands follow Adobe's documented upgrade procedure.

Magento 2.4.8 was released on April 8, 2025, and Adobe supports it until May 31, 2028. Staying on 2.4.7 gets harder to defend every month. Its standard support ends on May 31, 2027, and Adobe no longer supports it with any MySQL version newer than 8.0, which itself reached end of support on April 30, 2026. Here's how we typically handle the move.

Quick Navigation

1. System Requirements

Adobe's system requirements page lists these versions for on-premises installations of 2.4.8 as released, and for 2.4.8-p5, the latest 2.4.8 security release at the time of writing:

Dependency2.4.82.4.8-p5
PHP8.4, 8.38.4, 8.3
Composer2.9.3+2.10
MySQL8.48.4
MariaDB11.411.4, 11.8
OpenSearch2.193
Elasticsearch8.178
RabbitMQ4.14.3
Valkey88.1
Varnish7.68
nginx1.261.30

Three rows decide how the upgrade goes.

  • The database. Adobe supports 2.4.7 with no MySQL version newer than 8.0, and 2.4.8 requires MySQL 8.4. On MySQL there is no version both releases share, so the database upgrade and the code upgrade have to happen in the same maintenance window. MariaDB is easier, because the latest security releases of both lines, 2.4.7-p10 and 2.4.8-p5, list MariaDB 11.8. If your MySQL runs on Amazon RDS, the blue/green guide covers the database half.
  • PHP. 2.4.7 runs on PHP 8.3 and 8.2, and 2.4.8 on 8.4 and 8.3. Switch to 8.3 while still on 2.4.7, upgrade, and move to 8.4 once your extensions support it.
  • Search. Both lines support OpenSearch 2.19. If you still run Elasticsearch 7, move to OpenSearch first and reindex before touching the code.

2. Pre-Upgrade Checks

Don't skip this part.

  • Back up everything: database, files, media and configuration. Magento's built-in backup commands are deprecated, so use a database dump or a binary tool such as Percona XtraBackup.
  • Check that every custom and third-party module supports 2.4.8.
  • Grep your code for deprecated functions and core overrides.
  • Run the whole upgrade on a staging copy first.
  • Install Adobe's Composer root update plugin once, if it is not there yet:
composer require magento/composer-root-update-plugin ~2.0 --no-update
composer update

3. Git Workflow

Always use a dedicated branch. If something breaks, you can roll back cleanly:

git checkout -b upgrade-to-2.4.8
git tag before-2.4.8-upgrade

Commit composer.json, composer.lock, and all theme and module files before moving forward.

4. Upgrade Commands

4.1 Stop Cron and Drain the Queues

bin/magento maintenance:enable
bin/magento cron:remove
bin/magento cron:run --group=consumers
# repeat until no 'bin/magento queue' process is left
ps aux | grep 'bin/magento queue'

Adobe warns that starting the upgrade while message queue consumers are running may corrupt data, which is why cron comes out first.

4.2 Update Magento via Composer

cp composer.json composer.json.bak
# target the latest 2.4.8 security release; Adobe Commerce uses magento/product-enterprise-edition
composer require-commerce magento/product-community-edition 2.4.8-p5 --no-update
composer update

4.3 Run the Magento Upgrade

rm -rf var/cache/* var/page_cache/* generated/code/*
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush
bin/magento maintenance:disable
bin/magento cron:install

The last command puts cron back. Adobe's upgrade page ends before it, and a store without cron quietly stops indexing, sending mail and running its queues.

5. Post-Upgrade Tasks

Check the indexers with bin/magento indexer:status. setup:upgrade marks indexers whose configuration changed as invalid, and cron rebuilds them. On a large catalog, let cron do that rather than running a full indexer:reindex during business hours. If an indexer stays at Processing or Reindex required, our indexer guide walks through the causes.

Check file ownership rather than resetting permissions wholesale. A blanket chmod 644 across vendor also strips the execute bit from the scripts that vendor/bin points to.

Then check var/log/exception.log and var/log/system.log. If there are errors, you want to catch them now, not after you've disabled maintenance mode on production. Walk through the storefront, test checkout, and log into the admin to make sure nothing's broken.

Finally, apply the security fixes released since your 2.4.8 version. Adobe now ships monthly isolated patch files without Composer packages, applied in release order on top of the latest -p release, and the 2.4.9 guide explains how they work.

6. Common Issues

  • PHP errors. Usually the PHP version or a required extension is missing. Check with php -m.
  • Database logins failing after the move to MySQL 8.4. On a self-hosted MySQL 8.4 the old mysql_native_password plugin is disabled by default, so a Magento database user created on 8.0 cannot log in until it is moved to caching_sha2_password or the plugin is enabled again.
  • Broken themes. Theme compatibility is the most common headache. Look for deprecated layout handles.
  • Module errors. Third-party modules are the wild card. Disable them one at a time to isolate the problem.
  • Deployment failures. Make sure composer.lock is committed and caches are cleared before deploying.

7. Final Checklist

  • Staging upgrade completed and tested
  • Production backups verified and restorable
  • Git repo clean, no uncommitted changes
  • Database and PHP on versions 2.4.8 supports
  • Cron reinstalled with bin/magento cron:install
  • Isolated security patches applied
  • Third-party integrations tested (SMTP, payment gateways, CDN)
  • Team notified about the maintenance window

Note: If you need help with staging, backups, or a fully managed upgrade, our team at Private DevOps is ready to assist.

Wrap Up

The 2.4.8 upgrade is straightforward if you've done your homework. Good backups, a clean Git workflow, and testing on staging first will save you from most surprises. The database is the part that needs planning this time, since MySQL users move from 8.0 to 8.4 in the same window as the code. Once the store runs on 2.4.8, the 2.4.9 guide covers the next step.

Frequently asked questions

When does Magento 2.4.7 support end?

Standard support for Magento 2.4.7 ends on May 31, 2027. Magento 2.4.8 was released on April 8, 2025, and Adobe supports it until May 31, 2028. Adobe also no longer supports 2.4.7 with any MySQL version newer than 8.0, and MySQL 8.0 itself reached end of support on April 30, 2026, which makes staying on 2.4.7 harder to defend every month.

Do I need to upgrade MySQL when moving Magento from 2.4.7 to 2.4.8?

Yes, and on MySQL the database upgrade and the code upgrade have to happen in the same maintenance window. Adobe supports 2.4.7 with no MySQL version newer than 8.0, and 2.4.8 requires MySQL 8.4, so the two releases share no MySQL version. MariaDB is easier, because the latest security releases of both lines, 2.4.7-p10 and 2.4.8-p5, list MariaDB 11.8.

Which PHP version does Magento 2.4.8 support?

Magento 2.4.8 supports PHP 8.4 and 8.3, while 2.4.7 runs on PHP 8.3 and 8.2. The recommended order is to switch to PHP 8.3 while still on 2.4.7, run the Magento upgrade, then move to 8.4 once the store's extensions support it. PHP errors during the upgrade usually mean the wrong PHP version or a missing extension, which php -m shows.

What Composer commands upgrade Magento 2.4.7 to 2.4.8?

Install Adobe's Composer root update plugin first if it is missing, with composer require magento/composer-root-update-plugin ~2.0 --no-update and composer update. Then back up composer.json and run composer require-commerce magento/product-community-edition 2.4.8-p5 --no-update followed by composer update. Adobe Commerce uses magento/product-enterprise-edition in place of the community package. As of September 28, 2026, 2.4.8-p5 was the latest 2.4.8 security release.

Why stop cron and queue consumers before a Magento 2.4.8 upgrade?

Adobe warns that starting the upgrade while message queue consumers are running may corrupt data. Enable maintenance mode, run bin/magento cron:remove and then bin/magento cron:run --group=consumers, repeating until ps aux | grep 'bin/magento queue' shows no queue process left. When the upgrade is finished, put cron back with bin/magento cron:install, since a store without cron quietly stops indexing, sending mail and running its queues.

Why can't Magento log in to MySQL 8.4 after the 2.4.8 upgrade?

On a self-hosted MySQL 8.4, the old mysql_native_password plugin is disabled by default. A Magento database user created on MySQL 8.0 cannot log in until the user is moved to caching_sha2_password or the plugin is enabled again. Failed database logins right after the move from 8.0 to 8.4 are the typical sign.

Should I run a full reindex after upgrading Magento to 2.4.8?

On a large catalog, let cron rebuild the indexes and avoid a full bin/magento indexer:reindex during business hours. Running bin/magento setup:upgrade marks indexers whose configuration changed as invalid, and cron rebuilds them. Check progress with bin/magento indexer:status, and look into any indexer that stays at Processing or Reindex required.

How do I apply security patches after upgrading Magento to 2.4.8?

Apply the security fixes released since the installed 2.4.8 version as the last step of the upgrade. Adobe now ships monthly isolated patch files without Composer packages. They go on in release order, on top of the latest -p release such as 2.4.8-p5.

Read how we handle it in DevOps for e-commerce.