The extension nobody remembers can hold up your Magento upgrade
Start with what the store still uses. Then identify the modules that can block checkout, pricing or the target Magento release.
Your upgrade estimate includes updating 24 extensions. Nobody has asked whether the store still uses all 24. One powers an abandoned promotion; another handles the payment method that accounts for much of your business.
They should not receive equal attention. A useful Magento extension audit connects installed code to current business processes, then identifies what must be upgraded, replaced, removed or investigated before the target release.
Inventory what is installed and what is actually used
Collect Composer packages, Magento module status, modules under app/code, custom patches and theme integrations. Group related modules into the product or workflow they support. A single purchased extension can install several Magento modules.
Ask the team what each feature does today. Record its owner and a representative customer or admin journey. “Installed” and “enabled” are not evidence that it still earns its place.
Do not disable unfamiliar modules to see what breaks. Dependencies, saved data and integrations need investigation first.
Put launch blockers at the top
| Module area | Why it deserves an early test |
|---|---|
| Payment and checkout | Failure can prevent purchases or create uncertain payment states |
| Pricing, tax and promotions | A subtle error can affect every order |
| Stock and fulfilment | Orders may be accepted but cannot be supplied correctly |
| Identity and trade access | Customers may be locked out or given unintended access |
| Catalogue and content | Discovery, product information and indexing can change |
For each, record your current version, supported target release, available update, entitlement and exact test. Ask vendors for evidence of the version combination, rather than treating a general “Magento 2” label as sufficient.
Diagnose dependency conflicts before the launch window
Composer can expose a package constraint that prevents the target dependency set from resolving. Use its command documentation for show, why and prohibits when investigating. Do this on the upgrade branch, not by experimenting with production's dependencies.
Static compatibility analysis is another source of evidence. Adobe's Upgrade Compatibility Tool overview explains its scope; check access and prerequisites for your environment. A successful scan or compile does not replace workflow tests.
Make a decision for every product
Keep and update a module that fits the requirement and has maintained support. Replace one whose gap is fundamental. Remove an unused module only after checking dependencies, data retention and uninstall behaviour. Investigate a module whose owner or purpose is unclear.
Compare alternatives against the actual workflow. A replacement approval module that cannot protect your required sign-in paths may reduce the licence cost while increasing risk. A feature already covered by your Magento edition may need no replacement at all.
Rehearse the complete combination
Update the selected packages on staging with representative data. Test the critical workflows and their intersections: a trade customer using a promotion, a payment followed by warehouse export, a configurable product returning to stock.
Record observed results, not just ticks. Assign each failure to a vendor or developer and set a resolution before the launch decision.
The Magento upgrade checklist covers the rest of the release. If the audit identifies a replacement opportunity, compare our extensions and send the failing package, target version, theme, checkout and acceptance test. That is a concrete starting point for a recommendation.
From our shop