Work on a copy, update in dependency order rather than all at once, and set a point at which rebuilding is the cheaper answer.

Why the fear is rational

A site that has not been updated in three years is not one update behind, it is dozens, across the platform, the theme, and everything installed.

Applying those at once produces a site that breaks, with no way to tell which of forty changes caused it.

Some of the components may no longer be compatible with each other, or with a current version of the language the site runs on.

So the instinct that this will go wrong is correct, and the response of doing nothing makes each subsequent attempt harder.

Work on a copy

The step that removes the risk entirely and is skipped because it sounds like extra work.

Most hosts can create a staging copy in a few clicks, and where they cannot, a subdomain with a copy of the files and database does the same.

Everything that follows happens there, where breaking it costs nothing and can be undone by starting again.

The live site stays untouched until the whole sequence has been completed and checked on the copy.

Ask your host whether staging is included before assuming it is not, since many plans have it and few customers use it.

Without a copy, none of the rest of this is safe, and with one, almost all of it is.

The order matters

Working in that order means each step is small and the cause of any breakage is the thing you just changed, which is the entire benefit of not doing it all at once.

One at a time, checking each

Slower and considerably faster overall.

Update a single component, then load the site and check the pages that matter: the home page, a service page, the contact form, and anything with a booking or a basket.

Where something breaks, you know what caused it, and you can decide whether to find a fix, replace that component, or stop.

Note what you did and what happened, since the sequence is long enough to lose track of.

A site with thirty components takes an afternoon this way, which is less than a single day spent diagnosing a simultaneous update that failed.

Start with the components that are least likely to matter, so early failures are cheap.

A worked example

A site four years behind was updated on a staging copy over two afternoons.

Twenty-six of thirty-one components updated without incident.

Three broke visibly and were fixed by updating them in a different order, since one depended on another being current first.

Two could not be updated at all: one had been abandoned and was replaced, and one was a customisation from the original build that had to be rewritten.

The language version was raised last, which broke one remaining component and confirmed why it is done at the end.

The live site was updated in about an hour once the sequence was known, at a quiet time, with a backup taken immediately beforehand.

What to check after each stage

A short list, since checking everything after every step is impractical.

The home page and one service page load correctly on a phone.

The contact form submits and the message arrives.

Anything taking payment or bookings completes a full cycle.

The site is still reachable when signed out, which catches the case where something breaks only for visitors.

And nothing has appeared in the browser console, which frequently shows a problem before it becomes visible.

Set the point where you stop

Because updating is not always the right answer.

Where the site depends on components that are abandoned and have no replacement, or on customisations nobody can maintain, a rebuild may cost less than the sequence.

Decide that threshold before starting: something like two components that cannot be updated and have no alternative.

Reaching it is information rather than failure, and it is better to discover it on a staging copy after an afternoon than after a week.

A site that cannot be brought current is also a site that will keep being a security problem, which is the argument for rebuilding rather than living with it.

Get the content out either way, since that is the part worth keeping.

Then keep it current

Since this is a state to leave rather than a task to repeat.

The reason a site falls four years behind is that nobody owns the updating, not that anybody decided against it.

Name who does it and how often: monthly is right for most small sites, and the work is minutes when nothing has accumulated.

Enable automatic updates for security releases at minimum, which most platforms now offer separately from feature updates.

And keep the staging copy, since the next update is far easier when the mechanism already exists.

The counter-case

Sometimes doing nothing is defensible.

A site being replaced in two months does not need a careful update sequence, provided it is not currently compromised and is not taking payments.

Very simple sites with no interactive components carry considerably less risk from being behind, though they still carry some.

And where the site is business-critical and nobody in the business can do this, paying somebody is the correct answer rather than attempting it alone.

Take a backup, work on a copy, update in order, check as you go, and decide in advance when to stop.

The sequence

  1. Back up and store it off the server.
  2. Create a staging copy.
  3. Update one component at a time.
  4. Check the four things after each.
  5. Note what broke and what fixed it.
  6. Stop if you hit your threshold.
  7. Repeat on the live site, quickly, once known.

Step two is what converts this from a risk into an exercise, and it is available on most hosting plans to people who have never been told it is there.

The version where updating is genuinely impossible is covered in an old site you cannot update any more.

Frequently asked questions

Is the fear justified?

Yes. A site three years behind is dozens of updates behind across everything, and applying them at once produces breakage with no way to tell which change caused it.

What makes it safe?

Working on a staging copy, where breaking things costs nothing. Most hosts include staging and few customers use it, so ask before assuming you do not have it.

What order should I update in?

Platform to the last version of its current line, then plugins one at a time, then the theme, then the next major platform version, then the server language version.

Why one at a time?

Because the cause of any breakage is the thing you just changed. A site with thirty components takes an afternoon that way, against a day diagnosing a failed simultaneous update.

What should I check after each step?

Home and a service page on a phone, the contact form submitting and arriving, any payment or booking cycle completing, the site working signed out, and the browser console.

When should I stop and rebuild?

Decide the threshold first, such as two components that cannot be updated and have no replacement. Reaching it is information rather than failure.

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.

Site years behind and nobody dares touch it?

Ask your host whether staging is included. It usually is, and it turns the whole problem into an afternoon.

Start a Conversation