How do I plan a Magento 2 upgrade when I have many third-party extensions?

In a Magento 2 upgrade with third-party extensions, treat the extension list as the real upgrade plan. First, audit every module and sort it by upgrade risk against your target version. Then prove the plan on a staging site loaded with a recent production database before go-live. Core Magento updates through one Composer package, so most of the work sits in the modules on top.

How to plan a Magento 2 upgrade with third-party extensions

1. Build a complete extension inventory.
2. Remove what you no longer need.
3. Check Magento extension compatibility against your target version.
4. Classify each Magento 2 extension by upgrade risk.
5. Review custom code and patches.
6. Run the upgrade on staging with real data.
7. Test checkout and integrations, then plan go-live.

1. Build a complete extension inventory

List every installed module, from every source. composer show covers Composer packages, and bin/magento module:status lists enabled and disabled modules. Code dropped into app/code never appears in Composer, so check that folder separately.

For each module, record:

• The vendor and the installed version.
• What it does for the business, in one line.
• Where it came from: Composer, app/code, or a manual zip install.
• The date of the vendor’s most recent release.

2. Remove what you no longer need

Each extension you keep adds update and test work to the Magento 2 upgrade. Start with disabled modules. After that, look for extensions whose vendor has stopped shipping updates.

Also check for features Magento now ships in core. Page Builder has come bundled with Magento Open Source since 2.4.3, so a third-party page builder may no longer earn its place.

Uninstall cleanly through Composer and remove leftover database tables and config. A disabled module still sits in composer.json, and its version constraints can still block the upgrade.

3. Check Magento extension compatibility against your target version

Fix the exact upgrade target first: the Magento 2 version you’re moving to and the PHP version it requires. Framework changes inside Magento matter just as much as PHP. Adobe Commerce 2.4.9 shipped in May 2026. Its release notes confirm that 2.4.9 replaces the legacy Laminas MVC with a native MVC implementation. Any module built on Laminas MVC classes needs a vendor update before it runs on 2.4.9.

Then read each module’s changelog and check its composer.json constraints on magento/framework and php. To see what blocks the upgrade, use Composer’s why-not command: composer why-not magento/product-community-edition <target-version> (or magento/product-enterprise-edition on Adobe Commerce). It lists every installed package whose constraints conflict with the target.

4. Classify each Magento 2 extension by upgrade risk

Every row below Compatible is your actual project scope. It also shows where the cost sits before anyone writes code.

5. Review custom code and patches

Custom modules, plugins and preferences on core classes, theme template overrides, and Composer patches all need a pass. Check each patch against the target version’s release notes. A patch for a bug Adobe has since fixed can fail to apply or conflict with the new code.

Adobe Commerce stores have one extra check: Adobe’s Upgrade Compatibility Tool. It scans installed Magento extensions for compatibility with a target version. Adobe offers it for Adobe Commerce only. Open Source stores can use PHPStan and the Magento coding standard for PHP_CodeSniffer to catch deprecated and removed API usage.

6. Run the upgrade on staging with real data

Clone production into staging before the Magento 2 upgrade, with a recent database copy and every extension installed. Match production’s PHP, database, search engine, and cache versions. Run the Composer update, then bin/magento setup:upgrade, setup:di:compile, and setup:static-content:deploy.

When setup:di:compile fails, the stack trace names the class, and the class path names the vendor. Fix errors one at a time. Log each fix, since you’ll repeat the same steps on production.

7. Test checkout and integrations, then plan go-live

Test checkout end to end with every payment and shipping method you offer. Then cover integrations: ERP or inventory sync, product feeds, cron jobs, indexers, and transactional emails. Daily admin workflows belong on the list too.

Rehearse the full deployment on staging once more and time each step. That tells you how long a maintenance window to book. Freeze code and content changes, and take a full database and file backup before you start.

Where to focus your upgrade planning

On a Magento 2 upgrade, put the early effort into the extension audit, not the upgrade command. A complete inventory with a status for every module turns an unpredictable upgrade into a scoped list of tasks. If your list is long or full of abandoned modules, our Magento development team can audit it and plan the upgrade with you.