Replacing 47 plugins with 12: a consolidation playbook.

When a WordPress site is running 40+ plugins, the temptation is to rip half of them out at once. That breaks the site every time. The real playbook for plugin consolidation is methodical, takes weeks, and follows a specific order: audit, categorize, sequence, replace, verify. Here's the process I follow when a client engagement starts with “we have too many plugins.”

A common opening question on legacy WordPress engagements: “How many of these plugins do we actually need?” The site has 47 active. The honest answer is usually somewhere between 10 and 15. Getting from 47 to 12 isn’t a deletion exercise: it’s a refactor. The plugins that need to come out have to come out in the right order, with the right replacements in place, with verification at each step. The work takes weeks, not an afternoon.

Step 1: Audit before you touch anything.

The first deliverable isn’t a list of what to remove. It’s a list of what each plugin actually does. Most plugin lists, read cold, contain three categories that are easy to confuse:

• Plugins doing one thing each. A redirects manager, a Gravity Form HubSpot add-on, a CDN plugin. Easy to evaluate; either you need the thing or you don’t.
• Plugins doing five things each. Big page-builder plugins, comprehensive SEO plugins, suite-style tools. The question isn’t “do we need this plugin”; it’s “which of the five things does this plugin do are we using.”
• Plugins that exist because of a third plugin. Add-ons, extensions, integrations. Removing the parent removes them; trying to evaluate them independently confuses everyone.

Spend a day with the editor team and the site analytics. For each plugin, answer two questions: what does it do that the site needs, and what would break visibly if we turned it off today. The plugins that lose this exercise, and can’t answer either question, come out first.

Step 2: Group by replaceability.

The plugins that survive the first cut fall into four piles:

• Keep. Doing real work, doing it well, no consolidation candidate. ACF Pro, Gravity Forms, WooCommerce typically land here.
• Consolidate. Two or three plugins doing related work that one well-chosen plugin could handle. Three image-optimization plugins layered on top of each other; six different SEO assist plugins. These collapse to one.
• Replace with code. Plugins doing something simple that’s a 50-line PHP file. A custom “hide the admin bar on the front end for non-admins” plugin is a 5-line mu-plugin. A “redirect after login” plugin is one filter hook.
• Remove entirely. Plugins doing something the site doesn’t need. The contact form plugin from before Gravity Forms was installed. The analytics plugin from before GA4 launched. The slider plugin from a slider that’s no longer on the site.

Step 3: Sequence the work.

Don’t deactivate them in any order. There’s a right order:

1. Remove-entirely plugins first. They have the lowest risk and produce the biggest visible win — the plugin count drops, the editor feels progress.
2. Replace-with-code next. Write the replacement, deploy it, verify it works, then deactivate the plugin. This is the “belt-and-suspenders” window — both the plugin and the replacement are active for a release cycle before the plugin comes out.
3. Consolidate last. The riskiest moves because they involve multiple plugins changing behavior in concert. Pick the keeper, configure it to handle the work the others were doing, verify in staging, do the swap as one coordinated deploy.

Step 4: Test what you didn’t know to test.

Every plugin removal has a non-obvious failure mode. The form plugin that you replaced cleanly: turned out it also had a hook that fired on user registration. The image optimizer you consolidated: turned out it was rewriting img tags in post content, and the replacement doesn’t, so old posts now serve unoptimized images.

Things to specifically check after each removal:

• Front-end pages that use any feature touched by the removed plugin
• Admin screens that the editor uses (the plugin might have added columns or filters that are now gone)
• Email sending (some plugins hook into wp_mail in non-obvious ways)
• Background tasks (cron jobs the plugin scheduled, now orphaned)
• Data the plugin wrote to wp_postmeta or wp_options, either still needed or now garbage

Step 5: Document what’s left and why.

The final deliverable on a consolidation pass isn’t the shorter plugin list. It’s a one-page document that explains: for each remaining plugin, why it’s there, what would break if it came out, and what the replacement would look like if we ever needed to. This is the artifact that prevents the next consolidation cycle from being a from-scratch rediscovery.

A consolidation pass usually doesn’t get to the theoretical minimum. The realistic outcome on a 47-plugin site is somewhere between 12 and 18 plugins remaining — not because the rest were necessary, but because each individual removal carries some risk and you stop when the marginal cost exceeds the marginal benefit. The win isn’t the small number on the dashboard. It’s the absence of the cruft that was making everything else harder. See legacy modernization for what a full engagement looks like.

Plugin consolidation often goes hand-in-hand with broader rebuild work. A regional theater engagement illustrates the connection: the original site had accumulated years of plugin sprawl that left it stuck in a hack-and-recover cycle. The rebuild absorbed many of those plugin capabilities into custom code, dramatically reducing the future attack surface.