Remove one thing at a time, on a copy first, with a note of how to put it back. The obstacle is fear of breaking something rather than disagreement.

Why agreed removals do not happen

Deciding something should go is easy and doing it is not.

Whoever would remove it usually did not install it, does not know what it touches, and will be the person blamed if something stops working.

So the safe action is to leave it, and leaving it is what happens.

Which makes this a problem about confidence rather than about agreement, and the answer is a method that makes removal reversible.

Find out what it actually does first

The last is the one that catches people. A form plugin holds every submission, and a booking tool holds every booking, so removing it can delete records rather than merely a feature. Export before touching anything that stores.

Remove on a copy first

The step that makes the rest safe.

Most hosts provide a staging copy, and removing something there costs nothing and reveals what breaks immediately.

Work through the pages that might be affected, on a phone as well, and check the forms still submit.

Where nothing breaks, the removal on the live site is now a known quantity rather than a gamble.

Where something does break, you have learned it without an outage and can decide whether to fix or keep.

That is twenty minutes and it converts the whole exercise from risky to routine.

One at a time, with a gap

Since removing six things at once means not knowing which caused a problem.

Remove one, wait a few days, and watch for anything unusual: enquiries stopping, a page erroring, a report going empty.

Some breakage is not immediate, particularly anything that only runs on a form submission or a monthly report.

A week between removals is enough for most small sites and it makes each one attributable.

That turns a frightening afternoon into a slow, boring process, which is the correct shape for this.

A worked example

A business had eleven plugins, of which four were agreed to be unnecessary, and none had been removed in two years.

The developer would not remove them because he had not installed them and did not know what used them.

They set up a staging copy, removed all four there, and found that one was providing the styling for a contact form nobody had connected it to.

Three were removed from the live site over three weeks, one a week, with a note of the version and settings in case of a need to restore.

The fourth was replaced with a small piece of styling and then removed.

Nothing broke, and the process took less total attention than the two years of discussing it had.

Write down how to put it back

The note that removes the remaining fear.

Before removing, record the exact name and version, the settings it was using, and where the account is if it is a third-party service.

Take a screenshot of the settings screen, which is faster than transcribing it.

With that, restoring is ten minutes rather than a reconstruction, and knowing that makes the decision to remove much easier.

Keep those notes together, since a business doing this properly accumulates a useful record of what it once ran and why.

Do not rely on the backup alone, since restoring a whole site to recover one plugin is disproportionate.

The political half

Which is frequently the real obstacle rather than the technical one.

Somebody asked for that tool, and removing it can read as a judgement on them.

Ask rather than announce: this has not been used in eighteen months, is it still needed.

Most people say no, because they had forgotten it existed, and the ones who say yes give you a reason you did not have.

Where the person has left, that is the easiest case and the one where removal should simply happen.

Doing this at a fixed time each year also removes the personal element, since it is a process rather than a decision about somebody's tool.

Cancel the account as well

Since removing the code and keeping the subscription is the common half-measure.

A tool removed from the site frequently continues billing, sometimes for years, because the two actions are done by different people.

Check the card statement for anything you no longer recognise while you are doing this.

Export any data first, since cancelling frequently deletes it after a short grace period.

And note the cancellation date, since some services bill annually and cancelling a month after renewal wastes eleven months.

Deactivating is not removing

A distinction worth making, since the halfway step is the one people take.

A deactivated plugin usually stops running and stays on the server, which means it is still there to be exploited if a weakness is published for it.

It also stays in the update list, so it either gets updated forever for no benefit or stops being updated and becomes a risk.

Deactivating is the right first move for a week, as a test that nothing breaks, and it is not the end state.

Go back and delete it properly once the week has passed, which is the step that never gets diarised and therefore never happens.

The counter-case

Removal is not free either.

Every removal carries some risk, and a tool doing nothing visible is doing no harm on a site that is otherwise fine.

Time spent removing a plugin that costs a tenth of a second could go into something with a larger return.

And a tool nobody uses today may be the one somebody needs next month, particularly seasonal ones.

Do it once a year, on a copy first, one at a time, with a note of how to restore.

The method

  1. Ask what it was for and who asked.
  2. Check whether it stores data.
  3. Export anything it holds.
  4. Remove it on a copy and test.
  5. Record how to restore it.
  6. Remove one a week on the live site.
  7. Cancel the subscription too.

Step four is what breaks the deadlock, since the reason agreed removals never happen is that nobody wants to find out what depends on something while customers are watching.

Deciding what should go is covered in analytics, chat and three pixels.


Frequently asked questions

Why do agreed removals not happen?

Because whoever would do it did not install it, does not know what it touches, and will be blamed if something breaks. Leaving it is the safe action.

What should I check first?

What it was installed for, whether anything visible uses it, whether anybody reads its output, whether another tool depends on it, and whether it holds data.

What is the data risk?

A form plugin holds every submission and a booking tool holds every booking, so removing it can delete records rather than a feature. Export before touching anything that stores.

How do I remove safely?

On a staging copy first. Removing there costs nothing and reveals what breaks immediately, which converts the live removal from a gamble into a known quantity.

Why one at a time?

Because removing six at once means not knowing which caused a problem, and some breakage only appears on a form submission or a monthly report.

What about the person who asked for it?

Ask rather than announce: this has not been used in eighteen months, is it still needed. Most say no because they had forgotten it existed.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Tool everybody agrees should go?

Remove it on a staging copy first. The obstacle is not disagreement, it is nobody wanting to find out what depends on it live.

Start a Conversation