Magento 2.4.x upgrade checklist: before, during and after

A safe Magento 2.4.x upgrade has three phases. Before: check which release line is still supported, confirm the PHP, OpenSearch and database versions the target release needs, and map every extension and custom module against it. During: upgrade on a staging copy with production data, then run regression tests on checkout and every integration. After: release in a planned window with a tested rollback, then watch errors, orders and performance for the first days. Below is the checklist we work through on every upgrade, written for store owners and for agencies that hand upgrades to us.

Versions and dates below were checked against Adobe’s official documentation in November 2026. Adobe updates these pages regularly, so re-check them when you plan.

Before the upgrade

1. Know where your version stands

Adobe gives each 2.4.x release line three years of standard support from its release date, with quality fixes and security patches. Some older lines get extra time. Magento Open Source releases follow the same 2.4.x release lines and patch schedule as Adobe Commerce; the lifecycle dates are published by Adobe for Adobe Commerce.

What this means in practice:

• On 2.4.4 or 2.4.5: you only get isolated security fixes, no quality fixes, and that period will not be extended. Plan a minor upgrade now.
• On 2.4.6: standard support has ended. You have time, but not much.
• On 2.4.7 or 2.4.8: apply every security patch (the -pN releases) and plan the next minor upgrade calmly.
• On Adobe Commerce Cloud: from June 1, 2027 Adobe stops maintaining Cloud environments that run unsupported versions.

Also check that you are on the latest patch of your line. Adobe’s isolated security patch files can only be applied on top of it, so a store several patches behind cannot take an emergency fix quickly.

The 2.4.10 line is in alpha at the time of writing. Do not plan a production upgrade on an alpha or beta release.

2. Check the platform requirements

Much of the upgrade risk sits outside Magento itself: PHP, the search engine, the database and the cache. Adobe’s system requirements for the latest patch of each line (self-hosted):

Points that catch teams out:

• PHP jumps. Going from 2.4.6 to 2.4.9 means moving from PHP 8.1/8.2 to 8.5. Every custom module and extension has to run on the new PHP version, not just Magento core. PHP 8.2 itself gets security fixes only until December 31, 2026.
• Search engine. Elasticsearch 7.17 reached end of support on January 15, 2026, and 2.4.9 lists only OpenSearch 3. If you still run Elasticsearch, the search migration is part of the project. Budget for reindexing and for checking any search extension against OpenSearch.
• Database. MySQL 8.0 reached end of support on April 30, 2026. Check which MySQL or MariaDB versions your target release supports before you touch the code.
• Cache. Recent patches list Valkey instead of Redis. Your hosting or Cloud setup has to offer the version the target release expects.
• Commerce Cloud has its own requirements table that differs from the self-hosted one. Use the Cloud values if you are on Cloud.

3. Build an extension compatibility matrix

List every third-party module in composer.json and app/code, then fill in one row per extension:

• installed version and vendor;
• the version that supports your target Magento release and PHP version (from the vendor’s changelog, not the marketplace badge alone);
• licence or support status, since some upgrades need a paid renewal;
• whether the module is still used at all.

Mark each row as update, replace, patch ourselves or remove. Abandoned modules are a frequent reason upgrade estimates grow. Removing modules nobody uses is often the cheapest fix.

4. Review custom code and deprecated APIs

• Core modifications. Look for edits in vendor/, overridden core classes and composer patches. Each one has to be re-checked against the new release.
• Plugins and preferences on core classes break when method signatures change.
• Backward-incompatible changes. Adobe publishes a list per release. For example, 2.4.9 moves to Symfony 7.4 LTS, so custom classes that extend Symfony core classes need updated type declarations and method signatures. It also rejects orders created through the API without a billing address, which matters if an ERP or marketplace connector creates orders.
• On Adobe Commerce, run Adobe’s Upgrade Compatibility Tool against the target version. It reports critical issues, errors and warnings in your modules and core code. It is not available for Magento Open Source. There, the same review is done by hand and with static analysis.

5. Prepare staging and backups

• A staging environment that matches production: same PHP, search engine, database and cache versions as the target, not as today.
• A recent copy of production data, anonymised if the staging environment is less protected than production.
• Backups you have restored at least once: database dump, media/, app/etc/env.php and the deployed code (or the release artefact). A backup you have never restored is a hope, not a backup.
• A code freeze or at least a clear branch strategy, so features developed during the upgrade do not collide with it.

During the upgrade

6. Upgrade in small, reviewable steps

1. Update the infrastructure on staging first: PHP, search engine, database and cache.
2. Update Magento and the extensions through Composer, one group at a time, and commit after each step.
3. Run setup:upgrade, compile DI and deploy static content, and fix every error and deprecation warning. Do not silence them.
4. Re-apply or remove composer patches; some composer patches become unnecessary after an upgrade.
5. Rebuild frontend assets and check the theme, especially if it overrides core templates.

7. Regression-test what earns money

Automated tests help, but a written test plan covering real business flows is the minimum:

• Checkout: guest and logged-in, every payment method (including 3-D Secure and wallets), every shipping method, coupons, gift cards, tax and currency per store view.
• Customer account: registration, login, password reset, order history, reorder.
• Catalogue and search: category pages, layered navigation, search results and autocomplete after reindexing, configurable and bundle products, prices per customer group.
• Integrations: ERP and inventory sync, order export, payment and shipping webhooks, marketplace feeds, email and marketing tools, analytics and tag manager events. Test both directions, with real (sandbox) credentials.
• Admin and operations: order creation and invoicing, credit memos, imports, cron jobs, queue consumers and transactional emails.
• B2B features on Adobe Commerce: company accounts, shared catalogues, quotes, requisition lists.

Run a quick performance check too: full-page cache hit rate, server response time on key pages and Core Web Vitals on templates you changed.

8. Plan the release window and rollback

• Pick a low-traffic window away from campaigns, sales and other seasonal peaks.
• Write the release runbook: steps, who does what, expected duration and the decision point for rollback.
• Define rollback criteria before the release (for example: checkout broken, payment failures, integration errors you cannot fix in the window).
• Keep the previous release and a fresh database backup ready, and know how long a restore takes. Once new orders arrive after the database upgrade, rolling back the database means losing them, so the rollback window is short.
• Put the store in maintenance mode only for the steps that need it, and tell support and marketing the timeline in advance.

After the upgrade

9. Monitor the first days closely

• Errors: PHP and exception logs, failed cron jobs, stuck queue consumers.
• Orders: compare order volume and payment failure rates with a normal week. A silent drop is often the first sign of a payment or checkout problem.
• Integrations: confirm that orders reach the ERP, stock levels come back and webhooks succeed.
• Search and indexing: indexers valid, search results sensible, no growing reindex backlog.
• Performance: response times, cache hit rate and Core Web Vitals compared with before the upgrade.

10. Close the loop

• Remove the modules and patches you replaced, and clean up old deployment artefacts.
• Update the documentation: versions, the extension matrix, the runbook.
• Put the next security patch in the calendar. Staying on the latest patch of your line keeps the next minor upgrade small.

Patch, minor or older upgrade: what to expect

• Patch upgrade (for example 2.4.8-p4 to 2.4.8-p5): small scope, mostly testing. It should be routine.
• Minor upgrade (for example 2.4.7 to 2.4.8 or 2.4.9): new PHP and service versions, extension updates and custom code fixes. This is a project, not a task.
• Upgrade from 2.3 or older: expect a larger effort, since several PHP versions and many deprecated components lie in between.

If you are also thinking about replacing Luma, read When is Hyvä worth it? first. A Hyvä migration can be combined with a minor upgrade; on an unsupported version, the upgrade comes first.

Get help with your upgrade

If you want a second pair of eyes before you start, we offer a free express audit: versions, patch level, performance and basic security, with a short report and a 20-minute call. For the upgrade itself, our fixed-price upgrade packages start at €300 for a patch upgrade and €1,000 for a minor 2.4.x upgrade with the PHP update. The final price is set after the audit. To keep the store patched afterwards, see Magento support retainers.

Sources: Adobe Experience League: Lifecycle policy, System requirements, Released versions, Release schedule, Magento Open Source 2.4.9 release notes, Upgrade Compatibility Tool; Adobe Developer: Backward-incompatible changes; PHP supported versions.