Every module you carry is code you have to update, security advisories you have to read, and one more thing that can break on upgrade day. Most sites that have been around a few years are hauling modules nobody remembers installing. This audit lightens the pack. You’ll need drush, a site managed with Composer, and ideally a local or staging copy to practice on first.

List what’s installed and who depends on what

Start with the inventory:

drush pm:list --type=module --status=enabled --no-core

That’s your working list. For anything you’re unsure about, ask Composer why it’s there — some modules exist only because another one needs them:

composer why drupal/MODULE_NAME

If the answer is another module you’re keeping, cross it off. It’s along for the ride whether you like it or not.

Identify the candidates

Walk the list looking for the usual freeloaders: modules whose feature got retired (“we haven’t had a photo contest since 2022”), two modules doing the same job, development tools that snuck onto production, and modules installed for an experiment that ended. When you’re honestly unsure, ask the site’s editors — thirty seconds of “do you still use this?” beats an hour of code archaeology. Uncertain ones stay, for now. This is pruning, not clear-cutting.

Check what each one holds before it goes

Uninstalling a module deletes its data — that’s the point, and the danger. For each candidate, visit Extend → Uninstall and read what Drupal says it will remove; a module that owns a field will warn you the field’s contents go with it. If anything listed sounds like content someone might want back, stop and take a backup that actually restores before proceeding:

drush sql:dump --gzip --result-file=../backups/pre-module-audit-$(date +%Y-%m-%d).sql

Uninstall first, then remove the code

The order matters. Uninstalling runs the module’s cleanup — dropping its tables, deleting its config — and that cleanup needs the code present to run. Remove the code first and you’ve orphaned data Drupal can no longer clean up. So, one module at a time:

drush pm:uninstall MODULE_NAME -y
composer remove drupal/MODULE_NAME

If drush refuses because something depends on the module, believe it — either that dependent is also on your list, or your candidate stays.

Export the config change

Uninstalling changed your site’s configuration, and that change needs to travel with your code so staging and production agree:

drush config:export -y
git add config composer.json composer.lock
git commit -m "Module audit: remove MODULE_NAME (unused since 2022)"

If config export is new to you, export Drupal configuration to git covers the setup. Say why in the commit message — future-you will want the reason more than the fact.

Verify the site and the shorter update list

Click through the pages that matter: front page, a content edit, search, checkout if you sell things. Check Reports → Status report for new complaints. Then enjoy the payoff:

drush pm:security
composer outdated "drupal/*"

That list is now shorter, and it stays shorter every update from here on. That’s the whole prize: not the disk space, but every future Wednesday advisory that no longer applies to you.