Take a full backup, copy the site to a staging environment, update the one plugin there, and check the pages it touches. If it breaks in staging, you have learned that safely rather than publicly.

The plugin everybody has one of

Every site that has been running a few years has one.

The booking tool, the form handler, the gallery, the thing that makes the menu work.

It sits there with an update notice on it, and the notice has been there for eleven months, because the last time somebody pressed that button the site did something alarming for twenty minutes.

So it stays as it is, and everyone quietly agrees not to mention it.

The fear is not irrational

This is worth saying plainly, because the usual advice treats reluctance as laziness.

It is not. Updates do break things. An add-on that has been customised, or that interacts with a theme in a way nobody documented, can genuinely stop working when its underlying code changes.

If your site is your phone line, a twenty-minute outage during business hours is a real cost, and being cautious about causing one is a reasonable instinct.

The problem is not the caution. The problem is that indefinite postponement is not actually the safe option, it just moves the risk somewhere you cannot see it.

What happens while you wait

Three things, all of them getting slowly worse.

The gap between your version and the current one widens, so the eventual update becomes larger and more likely to break something rather than less.

The rest of the site keeps moving, since the platform underneath and the other add-ons are updating, and at some point one of them stops being compatible with the old version you are holding.

And any security flaw found in that version stays open on your site specifically, which is the part that does not wait politely.

Security does not care that you are busy

Known flaws in popular add-ons become publicly documented, and automated tools scan for them at scale.

Nobody has to target your business. The scanning is indiscriminate and constant, and it finds sites by the version numbers they announce.

A compromised small business site typically does not get defaced dramatically. It gets used quietly to send mail or host pages that have nothing to do with you, which is discovered weeks later when your domain stops delivering email.

The way out is a copy

The entire problem is that you are being asked to test a change on the live site in front of customers.

You are not obliged to do that.

A staging copy is a duplicate of your site at a private address where you can break things freely. Many hosts provide one on request or as a button in the control panel, and where they do not, a subdomain and a copy of the files will do.

Once a copy exists, the update stops being a gamble and becomes a test.

One at a time, deliberately

The temptation, once you have a staging site, is to press update on everything at once and see what happens.

Do not, because if something breaks you will not know which change caused it, and you will end up undoing all of them.

Update one thing, look at the site, and note the result. Then the next.

It is slower and it is the difference between an afternoon of methodical work and a week of guessing.

What to check after each one

Five minutes each, and they catch nearly everything that matters.

A worked example

A clinic had a booking add-on two years out of date, left alone after an update once emptied the appointment calendar for an afternoon.

Their host provided staging, which nobody had ever used.

They copied the site, updated the booking tool alone, and it broke immediately: the calendar rendered but would not accept a submission.

That would have been an afternoon of lost bookings on the live site, and instead it was a discovery on a copy nobody could see.

Investigating on the copy showed the problem was a small customisation a previous developer had made directly to the add-on's own files, which the update overwrote.

The fix took an hour, was tested on the copy, and went live at seven in the evening with no interruption at all.

The two-year-old version had four documented security flaws, which was not why they finally did it, but was the more important reason.

When it is genuinely abandoned

Sometimes the reason there is no safe update is that there are no updates.

An add-on whose last release was three years ago is not stable, it is unmaintained, and it will eventually stop working when the platform beneath it moves.

That is a replacement decision rather than an update decision, and it is better made deliberately in January than urgently in the middle of a breakage.

Finding the replacement, moving the data, and retiring the old one is a project. It is a smaller project than doing the same thing in a panic.

The counter-case

There is one situation where leaving it is defensible.

If the add-on does something trivial, has no access to your data, and the site is otherwise fully current, the risk of that specific old version may be genuinely small.

But apply that reasoning honestly. It covers a decorative slider. It does not cover anything that handles forms, payments, logins, or customer information, which is where most of the plugins people are frightened of actually sit.

If you cannot say what the add-on has access to, assume the answer is everything.

The procedure

  1. Take a full backup you hold yourself.
  2. Make a staging copy of the site.
  3. Update one thing on the copy.
  4. Check the five items above.
  5. Repeat for the next one.
  6. Apply to the live site outside business hours.
  7. Check again on the live site afterwards.

Done once properly, the backlog clears, and after that it is a twenty-minute job each month rather than a thing you avoid for a year.

Add-ons carry a cost even when they work, covered in what a plugin costs you in load time.


Frequently asked questions

Is it safe to leave a plugin un-updated?

No, though the fear behind it is reasonable. The version gap widens, compatibility with everything else degrades, and any known security flaw in that version stays open on your site.

How do I update without risking the live site?

Use a staging copy. Duplicate the site to a private address, update there, and check it. If it breaks, it breaks where no customer can see it.

Should I update everything at once?

No. Update one thing, check the site, then move to the next. Batch updates mean you cannot tell which change caused a problem.

What should I check after an update?

The homepage, the page the add-on affects, the contact form sent as a real test, the site on a phone, and any booking or payment step end to end.

What if the plugin has not been updated by its developer in years?

That is a replacement decision rather than an update decision. Unmaintained is not stable; it will break when the platform underneath moves.

Why would anyone target my small business site?

Nobody targets it. Automated tools scan indiscriminately for known flaws by version number, and a compromised site is usually used quietly rather than defaced.

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.

One update you have been avoiding?

Copy the site, break it privately, fix it, then go live in the evening. The fear was reasonable; the postponement is not.

Start a Conversation