1. Build an inventory you can trust

Start with the deployed store, not an old purchasing spreadsheet. Ask your developer to record installed packages, Magento module names, versions, enabled status, vendors, and installation methods. One commercial extension can contain several modules, so package counts and module counts will not necessarily match.

Use bin/magento module:status to list enabled and disabled modules. Compare that result with composer show, your lockfile, and custom code under app/code. Composer lists packages; it does not provide a complete business inventory by itself. Record custom integrations and externally injected storefront scripts separately. [1][2]

For every extension, add its business purpose, responsible owner, renewal date, connected services, and affected customer journeys. Include the Magento edition, active storefront, and current platform version. These details prevent somebody from approving a removal without understanding where the feature is used.

Link each inventory entry to its configuration notes, support account, and deployment history. If the original developer has left, assign a current owner. A module without documentation creates an investigation task; it should not disappear from the review because nobody remembers buying it.

Separate third-party additions from platform modules. A name nobody recognizes is a reason to investigate, not evidence that the component is unnecessary.

2. Ask what business value remains

For each extension, ask a simple question: what useful outcome would disappear if this feature stopped working tomorrow? Good answers include collecting payments, applying negotiated customer prices, reducing repetitive work, or supplying a marketplace with accurate inventory.

Check those answers against evidence. Review feature usage, completed transactions, support tickets, staff workflows, and relevant analytics. Choose a representative period that includes seasonal activity; a holiday promotion module can look unused during a quiet month.

Look for overlapping capabilities. Two SEO extensions might both control metadata, while separate merchandising tools may manage the same product labels. Document which system should own each function before consolidating anything.

Some valuable extensions operate entirely behind the scenes. An export connector used weekly by finance may be more important than a prominent storefront widget. Speak with merchandising, operations, customer support, and finance before deciding that low visibility means low value.

For uncertain features, agree on a short measurement period with the business owner. Define the event you need to observe, such as completed exports or redeemed offers. Missing analytics should lead to better observation before it leads to a removal recommendation.

3. Review maintenance and security

Check the vendor’s release history, compatibility statements, support availability, and security notices. Record the installed version and any applicable fixes. A recently updated product is not automatically reliable, and an older release is not automatically abandoned; investigate the vendor’s actual support commitments.

Ask your developer to run composer audit and review its findings alongside vendor advisories. Composer checks package information against advisory sources, but a clean result does not establish that custom or private extension code is secure. Treat it as one input to the review. [2]

Give additional attention to extensions that handle checkout, customer information, file uploads, administrator access, or external API connections. Check whether integrations still need their existing permissions and credentials.

Where a serious issue affects a necessary feature, assign an owner and remediation deadline immediately. Business importance makes a reliable patch or replacement more urgent; it does not make the issue acceptable.

Document where each connected service sends information and who can access its dashboard. When staff or agencies change, review those accounts alongside the extension itself. Forgotten service access can remain active even after a storefront feature has been switched off.

4. Measure performance in real journeys

Extension count is a poor performance diagnosis. One inefficient customization can cause more trouble than several small modules. Investigate observable symptoms instead: slow product filtering, delayed cart updates, lengthy checkout requests, stuck queues, or imports that run beyond their expected window.

Capture a baseline on representative category pages, product pages, search results, cart, and checkout. Examine server response times, database queries, third-party requests, JavaScript work, and application traces. Include scheduled jobs and administration tasks where staff report delays.

Test suspected extensions individually in a representative staging environment. Keep hosting resources, catalog data, traffic assumptions, and cache conditions consistent. Repeat measurements so an unusually fast or slow request does not determine the outcome.

Distinguish correlation from cause. Disabling a recommendation widget may reduce browser work, but the same experiment might also change caching or remove an external request. Record what changed and whether the measured improvement matters to shoppers or staff.

Set acceptance criteria before testing. For a checkout extension, that might mean successful transactions across supported payment methods, no new errors, and response times within your agreed budget. This makes the eventual recommendation easier to defend than a vague impression that the store feels faster.

5. Check the next upgrade, too

An extension that works today may become the reason your next platform upgrade stalls. Compare vendor support against your intended Magento or Adobe Commerce release, PHP version, storefront implementation, and relevant search or payment integrations.

Ask specific questions. Does the extension support your customized checkout? Are its features exposed through the APIs your storefront uses? Will existing product attributes, order records, or customer settings survive the proposed upgrade?

For Adobe Commerce projects, Adobe’s Upgrade Compatibility Tool can identify certain code compatibility issues against a target release. Adobe states that this tool is available for Adobe Commerce instances only. Its findings supplement functional testing; they do not prove that a complete customer journey works. [3]

Have developers review declared dependencies and custom code references as well. Magento prevents some changes when declared dependencies conflict, but project-specific integrations still need investigation. Do not bypass dependency checks simply to complete an audit faster. [1]

6. Calculate the full ownership cost

The purchase price is only part of an extension’s cost. Add recurring licenses, connected service subscriptions, update work, regression testing, incident investigation, and time spent maintaining custom compatibility fixes.

For example, imagine a module with a modest annual renewal that requires repeated developer intervention after releases. Compare that total with a supported alternative, including migration, training, and ongoing testing. This is a budgeting exercise, not a claim that paid extensions are inherently expensive.

Also count the work an extension saves. A reliable integration may eliminate hours of manual reconciliation every week. Removing its subscription while recreating that workload can increase total operating cost.

Use documented estimates and state any uncertainty. A useful comparison shows expected annual cost, one-time transition cost, and the operational benefit your team expects to retain.

Separate confirmed savings from hoped-for benefits. If a subscription is already paid for the year, removal may reduce future spending without producing an immediate refund. Likewise, performance improvements should be demonstrated before they appear in a financial forecast. This distinction keeps the audit credible when management compares proposals and approves the next implementation budget.

7. Decide what to keep, replace, or remove

Bring the findings together in one decision register. Record the recommendation, supporting evidence, responsible owner, and next review date. The examples below illustrate the reasoning; your store’s dependencies and workflows determine the final decision.

Allow a temporary “investigate” status when evidence is incomplete. Set a deadline and name the person who will resolve it. That keeps uncertainty visible without turning a guess into a production change.

Evaluate replacements against the actual workflow

Suppose an abandoned returns extension supports a process your service team still needs. A replacement must handle the required order history, return reasons, notifications, and staff permissions. Demonstrate those steps with representative records before purchasing. Compare export formats and migration options early, because inaccessible historical data can change the economics of switching.

Prefer a small proof of concept over a feature checklist alone. Ask the people who use the process to confirm that the alternative completes their daily tasks.

8. Retire extensions through a controlled release

Start in staging with a documented recovery plan and verified backups of the relevant code, configuration, database, and media. Identify the records you must preserve and test how the store behaves when the extension is disabled before planning permanent removal.

Disabling and uninstalling are different operations. Adobe documents that uninstalling can remove package code, and its optional --remove-data flag invokes a module’s uninstall logic to remove the schema and data it defines. Review the vendor’s instructions and your extension’s implementation before choosing an uninstall procedure. [4]

Use the deployment workflow appropriate to your hosting. Adobe Commerce cloud projects require module configuration changes to follow the project’s deployment process. Avoid treating a live server as a place for ad hoc package removal. [1]

Test checkout, payments, shipping, tax, promotions, refunds, customer accounts, and affected integrations. Check queues, cron jobs, APIs, and administrative screens. If the extension controlled URLs, metadata, or structured data, inspect those outputs too.

Deploy a small, reviewable change set and monitor errors and business events afterward. Only retire external subscriptions, webhooks, or credentials once the replacement or removal is confirmed. Keep the decision record so the next team understands what changed.

Define recovery triggers before release, such as payment failures or missing order exports. Also decide how new transactions will be reconciled if restoration becomes necessary. Restoring an older database without considering orders placed afterward can create a second operational problem.

9. Use this audit completion checklist

Before closing the review, confirm that the evidence and delivery plan are complete.

Schedule the next review before a major upgrade or renewal cycle, and revisit critical findings sooner.

Frequently asked questions