Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
To upgrade Magento 2 safely, you prepare a matching staging environment, update Magento and your extensions with Composer, run the database upgrade, then test checkout, integrations and search before you deploy to production with a rollback plan ready. The commands take minutes. The preparation and testing around them decide whether the upgrade goes smoothly. The checklist below covers every task before, during and after an upgrade, with a suggested owner for each so nothing falls between teams.
It applies to Adobe Commerce and Magento Open Source 2.4.x on-premises. Adobe Commerce on Cloud uses the same logic, but deployment runs through Cloud tooling.
Who does what
The owners in the checklist are roles, not job titles. In a small team one person may hold several.
- Project lead: scope, dates, sign-off and communication.
- Developer: code, extensions, Composer and fixes.
- DevOps or host: servers, services, backups and deployment.
- QA: test plans and regression testing.
- Store team: merchandising, content, customer service and order checks.
- SEO or marketing: URLs, tracking and feeds.
Before the upgrade
| Task | Owner | Why it matters |
|---|---|---|
| Choose the target version and check its support end date | Project lead | Landing on a long-supported version avoids a repeat project next year. |
| Read the release notes for every version between yours and the target | Developer | Backward-incompatible changes add up across versions. |
| List every extension with version, vendor and target-version support | Developer | Extensions are the most common cause of delays. |
| Remove extensions you no longer use | Developer and store team | Fewer modules means less to update and test. |
| Scan custom code for compatibility issues | Developer | Finds PHP deprecations and removed APIs early. Adobe Commerce customers can use the Upgrade Compatibility Tool. |
| Compare your stack with Adobe's system requirements for the target | DevOps or host | PHP, database, OpenSearch, Valkey, RabbitMQ and Varnish versions must match. |
| Build staging with production-like data and the target stack | DevOps or host | Testing on a different stack hides real problems. |
| Write a test plan covering checkout, payments, tax, shipping, search, accounts and integrations | QA and store team | Agreed in advance, so sign-off is objective. |
| Record baseline metrics: page speed, conversion rate, error rates, indexed pages | SEO or marketing | You need a before picture to spot regressions after. |
| Agree a go-live window and code freeze outside peak trading | Project lead | Avoids launching during a sale or holiday rush. |
During the upgrade
| Task | Owner | Why it matters |
|---|---|---|
| Back up code, database and media, and test that the backup restores | DevOps or host | A backup you have never restored is not a rollback plan. |
| Upgrade services first (PHP, database, search, cache) on staging | DevOps or host | Separates infrastructure issues from code issues. |
| Update Magento and extensions with Composer in a branch | Developer | Keeps the change reviewable and reversible. |
| Run the database upgrade, compile and deploy static content | Developer | Applies schema and data changes and rebuilds generated code. |
| Fix errors, deprecations and theme issues | Developer | Check logs, not just the homepage. |
| Reindex and check search results and filters | Developer and store team | Search engine changes can alter relevance. |
| Run the full test plan and log every defect | QA | One list of issues, prioritized by business impact. |
| Load test key pages and checkout | DevOps and QA | Catches slow queries and cache problems before customers do. |
| Rehearse the production deployment and rollback | DevOps and developer | Gives you a real timing for the maintenance window. |
| Get written sign-off | Project lead and store team | Confirms the business accepts the release. |
The core commands
On a Composer-based on-premises install, the core of the upgrade follows Adobe's documented pattern. This example targets Magento Open Source 2.4.9. Adobe Commerce uses magento/product-enterprise-edition instead.
bin/magento maintenance:enable
bin/magento cron:remove
bin/magento cron:run --group=consumers
cp composer.json composer.json.bak
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 setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento maintenance:disable
bin/magento cron:installThe compile and static content steps apply in production mode. Your deployment tooling may wrap these steps differently, and extensions may need their own Composer constraints updated first. Always run them on staging before production.
After the upgrade
| Task | Owner | Why it matters |
|---|---|---|
| Place real test orders with each payment method, then refund them | Store team | Confirms the money path works end to end. |
| Check orders, stock and prices flow to and from ERP, PIM and marketplaces | Store team and developer | Integration failures are often silent for hours. |
| Confirm cron jobs and message queue consumers are running | DevOps or host | Emails, indexing and exports depend on them. |
| Monitor logs and error rates daily for two weeks | Developer and DevOps | Some bugs only appear with real traffic. |
| Compare speed and conversion with the baseline | SEO or marketing | Shows whether the upgrade helped or hurt. |
| Check analytics tags, product feeds and sitemaps | SEO or marketing | Tracking and feeds break quietly. |
| Check Search Console for crawl errors | SEO or marketing | URL changes can cause 404s. |
| Retire old environments and update documentation | DevOps and developer | Old servers are a security risk. |
| Set up a patching routine for the new line | Project lead and developer | Keeps you current until the next upgrade. |
Keeping current after the upgrade
Once you are on the new version, staying there is cheaper than catching up later. Adobe recommends upgrading every patch release cycle, and says merchants must be on the latest patch or security patch to remain PCI-compliant. In practice that means applying each new -p release for your line and any isolated security patches Adobe publishes in between. Our guide to Magento security patches explains the patch types and how to test them. If you would rather hand that routine to a team, Mistri's Magento support and maintenance covers ongoing patching and monitoring.
Version-specific notes
- Going to 2.4.9: PHP 8.5, Valkey 9, OpenSearch 3 and MySQL 8.4 or MariaDB 12.3 are required, and several libraries were replaced. See what's new in Magento 2.4.9.
- PHP jumps: moving up one or more PHP versions is often the largest source of code fixes. See moving Magento to PHP 8.5.
FAQ
Can I upgrade Magento 2 from the Admin panel?
No. Magento 2.4.x upgrades are done with Composer and the command line, then deployed through your normal release process.
How much downtime does an upgrade need?
The maintenance window covers the database upgrade, compile and deployment steps. Rehearsing on staging tells you the real duration for your store, and many teams use build-based or blue-green deployments to shorten it.
Should I upgrade PHP and Magento at the same time?
Do both on staging together, since the target Magento version needs the new PHP. In production they usually go live together, but test the services changes separately first so you can tell infrastructure faults from code faults.
Need a hand?
If you want an experienced team to run this checklist with you, from the extension audit to post-launch monitoring, see Mistri's Magento upgrade services.
Sources
Adobe Commerce upgrade guide overview (Adobe Experience League); Perform an upgrade (Adobe Experience League); System requirements (Adobe Experience League); Security patch release notes (Adobe Experience League).
