Extension audit before an upgrade: cutting Magento tech debt

Most Magento upgrades do not get stuck on Adobe’s core code. They get stuck on a payment module nobody has updated since 2022, a theme override of a core template, or three extensions that all rewrite the same class. Every third-party module you carry into an upgrade has to be checked, updated or patched.

An extension audit before the upgrade turns that unknown into a list with owners and decisions. This guide walks through the process we recommend: inventory, usage check, compatibility check, conflict check, then removal.

Why the 2.4.8 and 2.4.9 upgrades raise the stakes

Both recent releases changed parts of the platform that extensions depend on:

• 2.4.8 (April 2025) added PHP 8.4 compatibility, removed PHP 8.1, moved search to OpenSearch and is no longer compatible with Elasticsearch. It also replaced several Laminas dependencies.
• 2.4.9 (May 2026) adds PHP 8.5 support and drops PHP 8.2 and 8.3. Adobe’s release notes describe a native MVC implementation replacing Laminas MVC, the Symfony Cache component replacing Zend_Cache, and the WYSIWYG editor moving from TinyMCE to HugeRTE.

Any extension that calls those libraries directly, ships its own Elasticsearch adapter or customizes the editor needs attention. Support windows add pressure too: Adobe’s lifecycle policy lists the end of standard support for 2.4.6 as 11 August 2026 and for 2.4.7 as 31 May 2027.

Step 1: Build a complete module inventory

Start with what Magento sees as installed and enabled:

bin/magento module:status --enabled  > modules-enabled.txt
bin/magento module:status --disabled > modules-disabled.txt

Then list what Composer installed directly, with versions and descriptions:

composer show --direct
composer show --direct --format=json > composer-direct.json

Finally, find code that lives outside Composer:

ls app/code/*/

Put everything in one spreadsheet. Filter out Magento_* core modules and Adobe’s bundled packages, then add columns for vendor, installed version, latest version, source (Composer or app/code), business owner and a decision: keep, update, replace or remove.

Step 2: Find unused and abandoned extensions

Unused

Disabled modules are the easy wins. If something has been disabled for months and nobody misses it, plan to remove it. For enabled modules, look for evidence of real use:

• Is the feature visible on the storefront or in a daily admin workflow? Ask the people who run the store.
• Do its database tables contain recent rows?
• Does its cron job appear in cron_schedule and do any useful work?
• Is the feature switched off in configuration while the module stays enabled?

# Tables created by a vendor, with row counts
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name LIKE 'vendorprefix_%';

# Is the module's cron running?
SELECT job_code, status, MAX(executed_at)
FROM cron_schedule WHERE job_code LIKE 'vendorprefix_%'
GROUP BY job_code, status;

Abandoned or unmaintained

composer outdated --direct
composer audit

composer outdated shows which packages have newer versions and flags packages marked as abandoned. composer audit checks installed versions against known security advisories. For each extension, also check the vendor’s changelog and the date of the last release. A module without a release that supports your target PHP version is a candidate for replacement.

Step 3: Check compatibility with the target version

Composer constraints

Ask Composer what blocks the upgrade before you change anything:

composer why-not magento/product-community-edition 2.4.9
composer why-not php 8.4

Use magento/product-enterprise-edition for Adobe Commerce. The output lists every package whose constraints conflict with the target. That list is your upgrade backlog.

Upgrade Compatibility Tool (Adobe Commerce)

Adobe’s Upgrade Compatibility Tool (UCT) analyzes the modules and core code in an instance against a target version and reports critical issues, errors and warnings. Adobe’s documentation states it is available for Adobe Commerce instances only, and it is installed from repo.magento.com:

composer create-project magento/upgrade-compatibility-tool uct --repository https://repo.magento.com
chmod +x ./uct/bin/uct

# Check custom code against a target version
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9

# Only show new problems introduced by the upgrade
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9 \
  --ignore-current-version-compatibility-issues --min-issue-level=error

# Find modified core files
./uct/bin/uct core:code:changes /var/www/magento /path/to/vanilla

Before relying on the report, confirm that your UCT version supports the target release you are checking against.

PHP version checks (Open Source and Commerce)

On Magento Open Source, or in addition to UCT, run a static PHP compatibility scan with PHP_CodeSniffer and the PHPCompatibility standard over third-party code:

vendor/bin/phpcs -p --standard=PHPCompatibility \
  --runtime-set testVersion 8.4- app/code vendor/vendorname

Check that the PHPCompatibility version you install has sniffs for your target PHP version. Static scans miss runtime problems, so also run the store on the target PHP version in staging with deprecation logging on.

Common findings when moving to PHP 8.4 include implicitly nullable parameters such as function foo(Bar $bar = null), which PHP 8.4 deprecates in favor of ?Bar $bar = null. PHP 8.5 adds further deprecations, such as the non-canonical casts (integer) and (boolean) and using null as an array offset.

Step 4: Find plugin and preference conflicts

Preferences replace a core class completely, so only one module can win. Around plugins on hot paths can break each other and slow the store. List them:

# Preferences declared by third-party code
grep -rn "<preference" app/code vendor/*/*/etc --include=di.xml | grep -v "vendor/magento"

# Full DI picture for a class that several modules touch
bin/magento dev:di:info "Magento\Checkout\Model\ShippingInformationManagement"

dev:di:info shows the active preference, constructor arguments and every plugin on the class with its type (before, after, around). Flag any core class with preferences from more than one vendor, and any class with several around plugins. Those are the first places to test after the upgrade.

Also look for template and layout overrides of core files in your theme. A changed core template will not break the build, but it can silently drop new markup, CSP nonces or security fixes.

Step 5: Replace extensions with core features

Some extensions were bought to fill gaps that Magento has since closed. Typical examples worth checking:

Replacement is not automatic. Compare features, migrate data and retrain users, but each module you drop is one less dependency in every future upgrade.

Step 6: Remove extensions safely

1. Back up the database and code.
2. Disable first on staging and run a full regression: checkout, payments, admin order creation, imports and integrations.
3. Check for data you need to keep, such as custom attributes, order fields or customer data the module stored.
4. Remove the code. For Composer-installed modules:

bin/magento maintenance:enable
bin/magento module:disable Vendor_Module
composer remove vendor/module-package
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento maintenance:disable

Alternatively, bin/magento module:uninstall Vendor_Module --backup-db runs composer remove for you and, with --remove-data, runs the module’s own uninstall routine. It works only for modules installed through Composer. For modules in app/code, disable them, delete the directory, then run setup:upgrade.

5. Clean leftovers carefully: orphaned tables, core_config_data entries and EAV attributes. Only drop data after the business owner signs off.
6. Deploy to production as its own release, before the platform upgrade, so you can tell problems apart.

Frequently asked questions

Is the Upgrade Compatibility Tool available for Magento Open Source?

No. Adobe’s documentation says the Upgrade Compatibility Tool is available for Adobe Commerce instances only. Open Source projects can combine Composer’s why-not, PHPCompatibility scans and a test upgrade on staging.

Should I disable an unused extension or uninstall it?

Uninstall it. A disabled module still sits in your codebase, can still conflict with Composer constraints, and still needs updates when its dependencies change.

How long does an extension audit take?

It depends on how many third-party modules you run and how well they are documented. The inventory itself is quick with the commands above. The time goes into usage checks with the business and testing replacements.

Can we upgrade PHP and Magento at the same time?

Check the supported combinations for your path. 2.4.8 requires PHP 8.3 or 8.4 for production use, and 2.4.9 fully supports PHP 8.5, with PHP 8.4 allowed for upgrade purposes only. Many teams move to the target Magento version on a PHP version both releases support, then switch PHP in a separate step.

Sources

• Adobe Commerce 2.4.8 release notes
• Adobe Commerce 2.4.9 release notes
• Adobe Experience League: Released versions
• Adobe Experience League: Software lifecycle policy
• Adobe Experience League: Upgrade Compatibility Tool overview
• Adobe Experience League: Run the Upgrade Compatibility Tool
• Adobe Experience League: bin/magento CLI reference
• Adobe Experience League: Uninstall modules
• Adobe Developer: Dependency injection configuration
• PHP manual: Deprecated features in PHP 8.4
• PHP manual: Deprecated features in PHP 8.5