Auditing a store’s module estate

Why that inventory almost never exists

Nobody keeps a list of a store’s modules, because each was added for a good reason at some point, and that reason is written down nowhere. Two years later nobody knows whether the promotional banner module is still used, or why there are three statistics modules.

That vagueness has a direct cost. It prevents deciding what to update, it makes every upgrade riskier than it should be, and it spreads the diagnosis of each failure across the whole estate rather than onto an identified suspect. The audit repairs nothing by itself: it makes the following decisions possible.

What I hand back at the end

A list, sorted by decision rather than alphabetically: what can be removed with no consequence, what must be updated promptly, what must be replaced because its publisher no longer follows, and what stays as is. For each module concerned I state what to check before touching it and what is likely to break.

I add two things that weren’t asked for but always come out of an audit: traces of already deleted modules still in the database, and modules installed twice under different names for the same function. Those two points explain a significant share of the slowness and conflicts found afterwards.

The audit is reading and measuring work, not intervention. I remove nothing during it: the store stays exactly as it was, and decisions are taken afterwards with the list in hand.