You cannot remediate everything, so you rank it
A mature Magento store carries technical debt in dozens of modules. You will never get budget or a maintenance window to fix all of it at once, and trying to is how remediation stalls.
The move that works is ranking. Build an inventory, score each module by what it actually costs, and fix in order of risk.
This article covers how to inventory the modules, which dimensions predict real cost, and how to turn that into a remediation order instead of a pile of findings.
Start with a complete module inventory
You cannot rank what you have not listed. Begin with every module the store runs, both the custom code in app/code and the third-party packages under vendor/.
bin/magento module:status gives the enabled and disabled list, and composer show gives the installed packages and versions. Together they are the raw inventory.
The goal at this stage is completeness, not judgment. A module you leave off the list is a risk you have decided not to measure, usually without meaning to.
The dimensions that actually predict cost
Not every module carries the same risk, and the useful scoring dimensions are the ones that predict future pain. A few carry most of the signal:
- Upgrade risk: does it use preferences, core overrides, or deprecated APIs that break when the platform moves?
- Maintenance status: is the vendor still shipping updates, or is the module abandoned?
- Security exposure: does it carry a disclosed vulnerability with no patched release?
- Compatibility: does it block a needed PHP or Magento upgrade?
- Ownership clarity: does anyone on the team actually know what it does and why it is there?
Each of these is a separate article's worth of checks. In an inventory, you only need enough to score them relative to each other.
Scoring blast radius
The dimension teams most often miss is blast radius: how much breaks if this module fails. A module isolated to one admin report is a different risk than one wrapped around checkout.
Score each module by how deeply it hooks into critical paths. Anything touching checkout, order placement, payment, or core class behavior sits at the top, because its failures are customer-facing and revenue-affecting.
From scores to a remediation order
With the dimensions scored, the order writes itself. Rank modules by combined risk and blast radius, and the top of the list is where remediation starts.
The pattern that rises to the top is consistent: high blast radius plus high upgrade or security risk. A checkout extension from an abandoned vendor with a known vulnerability is the module you address first, regardless of what else is on the list.
Everything below that gets a clear, defensible position. When someone asks why a given module is not being fixed this quarter, the score answers for you.
Score it lightly, not perfectly
The scoring does not need to be precise to be useful. A simple low, medium, high on each dimension is enough to sort the list, and arguing over whether a module rates a six or a seven wastes the time the inventory was meant to save.
Put the modules in a spreadsheet, score each dimension, and sort. The ranking that falls out is directionally right, which is all a remediation order needs to be.
You can sharpen a score later, when a module reaches the top of the list and gets real attention. Precision at the bottom of the list is effort spent on work you will not do for months.
Keep the inventory alive
An inventory taken once and filed away decays immediately. Every deploy adds, updates, or removes modules, and last quarter's ranking stops matching the store.
The inventory is worth far more as a living document than a one-time report. Revisit it after major changes, and on a fixed cadence, so the ranking reflects the store you have now rather than the one you audited then.
That upkeep is small next to the value. A current, scored inventory means the next upgrade or incident starts with a plan instead of a scramble.
Why the inventory beats gut feel
Without an inventory, module priorities get set by whatever broke most recently. That is recency bias, not risk management, and it leaves the quiet high-risk modules untouched until they fail.
A scored inventory replaces that with evidence. Knowing which modules cost the most to carry, and in what order to address them, is the difference between reacting to outages and preventing them.
The ranked list is the deliverable. It is what turns a vague sense that the store is fragile into a schedule you can actually work through, and it is the core of what a forensic platform audit produces.