Dead Weight in the Stack: Auditing CMS Extensions Before Upgrade Season

There is a particular kind of dread that arrives when you open the extensions list on a site that has been live for five years. It reads like a diary of small emergencies. Someone needed a cookie banner in a hurry. Someone else bolted on a redirect manager during a rebrand. A form add-on appeared because the marketing team had a deadline. Each was a two-minute install at the time. Now the upgrade is booked, and half of them have not been touched since 2021.

That is not a character flaw in your team. It is how content management systems age. The problem is that some of those extensions are now quietly holding up parts of the business, and nobody has checked whether they are still fit to do so. Before you plan the next upgrade cycle, it is worth doing the unglamorous work of finding out.

Start with a list you can actually defend

The first pass is mechanical: export every plugin, module, extension or add-on from the CMS admin, then reconcile it against what is actually enabled. Most platforms will give you a list with version numbers and last-updated dates. Treat that as a starting point, not the truth. I have seen extensions that were disabled in the admin but still had database tables humming away in the background, and others that were installed twice under slightly different names after a botched restore.

For each item, capture four things: who owns it, what it does in one sentence, which pages or templates depend on it, and whether it stores its own data. That last column matters more than people expect. A plugin that adds a button is easy to remove. A plugin that created five custom tables and a shortcode used on 200 pages is a different sort of tenant.

Read the vital signs, not the marketing page

Abandonment rarely announces itself. It looks like a project page that still says "compatible up to" a version you left behind two releases ago. It looks like a support forum where the last reply from the maintainer is a cheerful "will look into this" from eighteen months back. It looks like a changelog that only bumps the version number without touching the code.

Useful signals, roughly in order of how much they tell you:

• Release cadence. A plugin that has not shipped a release in two years is not automatically dead, but it is on watch. One that has never shipped a security release is a different conversation.
• Maintainer responsiveness. Check the support queue. If unanswered threads are piling up, assume yours will join them.
• Security history. Look the extension up in the relevant advisory feed — WPScan for WordPress, the Drupal security advisories, the Joomla vulnerability list, the Umbraco and Craft package pages. A clean history is not a guarantee, but a cluster of past CVEs with slow fixes tells you something about the maintainer's priorities.
• Declared compatibility. If the extension has not declared support for the CMS version you are moving to, you are not upgrading — you are gambling.
• Install base trend. A shrinking user base usually precedes a quiet retirement. It is not proof, but it is a smell.

For UK public sector teams, there is an extra lens. If an extension touches personal data, cookie consent, accessibility controls or payment flows, an unmaintained dependency is not just a technical risk. It is a conversation with your data protection officer and, potentially, your SIRO. Cyber Essentials and the NCSC's supply chain guidance both point the same way: you are responsible for what you ship, even when someone else wrote it.

The hidden dependencies are the ones that bite

Before you decide anything, map the blast radius. Search the codebase for the extension's name, shortcodes, template tags and database table prefixes. Check the content itself — not just the theme. A redirect plugin may look optional until you realise that 40 of your top landing pages depend on its rules. A forms add-on may be the only place a particular service's submissions are stored.

This is also the moment to check integrations. Payment gateways, CRM syncs, single sign-on and consent management platforms often sit behind an extension that nobody thinks of as strategic. If it fails during the upgrade, the failure will not look like a plugin problem. It will look like the website is broken.

A scoring sheet beats a heated argument

You do not need a 40-page risk model. A simple three-column score works: business criticality (low, medium, high), support health (active, watch, abandoned), and replacement effort (small, medium, large). Anything that lands in high criticality plus abandoned or watch goes straight onto the action list. Everything else gets a note and a review date.

The value of writing it down is that it turns a vague instinct — this feels risky — into a decision you can defend to a finance director or a head of digital. It also stops the audit from becoming a personal campaign against the one plugin you have always disliked.

Retire, replace or rebuild

Most extensions fall into one of three buckets.

Retire is the cheapest and most underused option. If the functionality is no longer needed, remove it properly: deactivate, check for orphaned tables, delete the data if it is safe to do so, and confirm nothing in the content breaks. Do not just leave it switched off for another three years.

Replace makes sense when the function is still needed but the current extension is unsupported. A like-for-like swap is fine if the new option is actively maintained and has a clear upgrade path. Be careful with "free" replacements that turn out to be a paid product with a thin free tier — budget for the licence and the migration time.

Rebuild is the last resort, and it should be reserved for extensions that do something genuinely specific to your organisation. A small custom module with tests and an owner is often safer than a sprawling third-party add-on, but only if you can maintain it. If you cannot, you have simply moved the abandonment problem in-house.

Time it before the upgrade, not during it

Aim to finish the audit eight to twelve weeks before the upgrade window. Freeze new extension installs while the audit is running, or you will be chasing a moving target. Test the decisions in a staging copy with realistic content, not a clean install. And write a short exit note for anything you remove — what it did, why it went, and what would need to happen to bring it back.

The point of all this

The goal is not a pristine stack with no extensions. It is a stack where every moving part has a reason to be there and someone who can explain it. That is a much easier position to defend when the next upgrade lands, and it makes the roadmap look less like a rescue mission and more like a plan.