You can shrink the extension footprint without losing features
A store carrying hundreds of extensions is carrying real overhead, but the fear of removing anything keeps the footprint growing. Teams assume every extension is load-bearing, so nothing ever comes out.
Most stores can reduce their extension count meaningfully without losing a single feature customers use. The waste is in duplication, abandonment, and features nobody actually needs anymore.
This article covers how to find the removable extensions, how to consolidate overlapping ones, and how to do it safely so no working feature goes with them.
Start with the inventory
Reduction begins with knowing what you have. List every enabled module with bin/magento module:status and every installed package with composer show.
The goal is a complete picture of the footprint, separated into custom code and third-party extensions. You cannot reduce what you have not listed, and the list itself often surprises teams with how much is installed.
This is the same inventory that a technical-debt review builds, used here for the specific question of what can safely come out.
Find the genuinely unused
The easiest wins are extensions for features nobody uses. Over years, stores accumulate extensions for campaigns that ended, integrations that were dropped, and experiments that never went anywhere.
These provide features the business has moved past, so removing them costs nothing. Identifying them means asking, for each extension, whether the feature it provides is still used, which is a business question as much as a technical one.
An extension whose feature no one can point to a use for is a strong removal candidate. It is pure overhead with no offsetting benefit.
Find the duplicates
Stores often carry several extensions that do the same job. Two SEO extensions, two page builders, or three ways to manage promotions accumulate as teams try different vendors over the years.
Consolidating onto the best of the overlapping options keeps the feature while removing the redundancy. This is reduction without loss, because the capability stays and only the duplication goes.
Find the abandoned
Abandoned extensions are removal candidates even when their feature is used, because they are liabilities. An extension from a vendor that no longer ships updates is a security and upgrade risk carried for a feature that could be provided more safely.
Where the feature is needed, an abandoned extension becomes a replacement rather than a straight removal. Where the feature is not needed, it is simply removed, and either way the abandoned code comes out.
This connects footprint reduction to extension health. The abandoned extensions on the removal list are the same ones flagged as risks in a health review.
Test before removing
Removal has to be safe, which means testing before deleting. Disable the candidate in staging with bin/magento module:disable, then run a full regression to confirm nothing customer-facing breaks.
If disabling it changes nothing that matters, the extension was dead weight and can be removed for real. If something breaks, you have learned the extension is load-bearing, and it stays or gets replaced rather than removed.
This test is what turns fear into evidence. Instead of assuming every extension is essential, you confirm which ones actually are.
Remove it properly
Disabling is not removing. A disabled extension still sits in the codebase and the Composer requirements, still adding to compilation and upgrade considerations.
Proper removal takes the module out of app/code or out of the Composer requirements entirely, so its weight is genuinely gone. Until then, the footprint has not actually shrunk, only quieted.
Check for data the extension owns before deleting, such as custom tables or configuration, so removal is clean. A properly removed extension leaves nothing behind to puzzle over later.
Reduction is a recurring habit
A one-time reduction shrinks the footprint, and without a habit it grows back. Extensions get added for new needs, experiments, and campaigns, and the count creeps up again over the following years.
The durable fix is to make reduction part of ongoing maintenance. Reviewing the footprint periodically, and removing what has fallen out of use, keeps the store from re-accumulating the bloat you just cleared.
This also means being deliberate about additions. An extension added with a clear purpose, and reviewed when that purpose ends, never becomes the orphaned weight that reduction has to remove later.
The payoff of a smaller footprint
Each extension removed is compilation time saved, a shorter plugin chain, less code on every request, and one fewer pair that can conflict under load. The gains compound as the footprint shrinks.
A leaner store is faster, more stable, and cheaper to upgrade, because there is simply less code to run, reason about, and carry forward. None of that costs a feature customers use.
Knowing which extensions are unused, duplicated, or abandoned, and removing them safely, turns a bloated store into a lean one without loss. That reduction is a practical outcome of a module-risk and performance review.