How do I find and remove abandoned extensions before an upgrade?

On Magento 2, an extension is abandoned when its vendor stops shipping releases for your target Magento or PHP version. To find them, list every third-party module and run a dry-run Composer update against the target version. To remove one, disable it on staging first, then delete its code and the database records it leaves behind. The vendor’s release history settles any borderline case.

How to find abandoned Magento extensions

1. Inventory every third-party module: Run bin/magento module:status. Anything outside the Magento_ namespace is third-party, apart from the few vendor modules bundled with core, such as PayPal_Braintree. Cross-check with composer show --direct, and also look in app/code, because modules installed there never appear in Composer output.
2. Check the abandoned flag: Run composer audit. Since Composer 2.7, the audit fails on abandoned packages by default. During composer install or update, the same flag shows up as “Package vendor/name is abandoned, you should avoid using it.” Composer names a replacement package when the maintainer has set one.
3. Know where the flag stops working:Packagist only sets the abandoned flag when a maintainer marks the package or archives its GitHub repo. Extensions installed from repo.magento.com or a vendor’s private repository sit outside Packagist, so they rarely carry this flag. A clean audit proves little on its own.
4. Test against the target version: Run composer require magento/product-community-edition=2.4.9 --no-update, then composer update --dry-run -W, using your real target version. Any conflict in the output names a package that blocks the upgrade. Modules in app/code have no Composer constraints, so test them on a staging copy running the target version. Adobe Commerce projects can also run the Upgrade Compatibility Tool, which scans module code for breaking changes. Adobe doesn’t offer it for Magento Open Source.
5. Confirm with the vendor: Read the vendor’s changelog and note when the last release shipped. If the vendor has shipped a compatible release, update to it instead of removing the module. A module with no compatible release and no reply from the vendor is abandoned for planning purposes.

Removing abandoned Magento extensions without breaking the store

1. Back up and move to staging: Take a full code and database backup. Never do this on production first.
2. Check what depends on it:module:disable refuses to run if other modules declare a dependency. module:uninstall only checks dependencies declared in composer.json, so a search is the only way to catch theme references. Search your theme and custom modules for the vendor namespace too, because layout XML and templates can reference its blocks.
3. Disable it: Run bin/magento module:disable Vendor_Module, then setup:upgrade. Test checkout, the admin product grid, and order views before you delete any code.
4. Remove the code: For Composer packages, run composer remove vendor/package. If the module ships an Uninstall class, bin/magento module:uninstall with --remove-data runs that cleanup and the composer remove together. For app/code modules, delete the directory manually.
5. Clean the leftovers: Delete the module’s row in setup_module and its paths in core_config_data. Drop its custom tables only after you export anything you still need. Finish with setup:upgrade, setup:di:compile, and a static content deploy.

When to replace, fork, or drop an old module

An unmaintained Magento extension leaves you with a short list of options.

Run the extension audit before you scope the Magento upgrade itself. Each abandoned Magento extension turns into replace-or-rewrite work, which belongs in the estimate from the start. Want a second pair of eyes on your module list? Our Magento development team can review it with you.