Back up, make a copy, and update in stages on the copy: WordPress first, then plugins one at a time, then the theme, then PHP. Replace anything abandoned, then keep the live site current monthly.

A site nobody has touched since 2013

The site went live in early 2013, worked well and was left alone. Three years later the dashboard is a wall of update notices.

WordPress itself is on version 3.5, ten major versions behind 4.5. The theme has never been updated, and of eleven plugins, several have updates, two have none and one has left the plugin directory.

The tempting move is to click update on everything. On a site this far behind, that is often how it breaks, and then nobody can tell which update did it.

There is a safer order, and it starts with a copy rather than the live site.

What changed while it sat

The second explains the gap. Since version 3.7, minor security releases install themselves on most sites; a site on 3.5 never had that, so it has missed every fix since it was built.

A backup you can restore

Before anything else, take a full backup: every file and the database, downloaded off the server and kept somewhere else.

A backup is only useful if it can be restored. Check that the database file is not empty and that the files include the uploads folder with the site's images.

Then list what is installed: the WordPress version, the theme, every plugin with its version, and the server's PHP version. That list becomes the plan.

Work on a copy

Make a copy of the site at a separate address that nobody else visits, with search engines kept out. Most good hosts can set one up, and so can your developer.

Everything that follows happens on the copy first. The live site keeps running, untouched, while the upgrade is worked out.

Test forms on the copy with your own address only, so customers do not receive test messages.

Check every plugin first

Look each plugin up in the WordPress plugin directory: is it still listed, when was it last updated, and has it been tested with a recent version?

A plugin last updated two or three years ago is a candidate for replacement rather than updating. So is one that has disappeared from the directory, since plugins are sometimes removed over security problems.

Premium plugins, bought separately or bundled with the theme, need a current licence or a fresh copy from the maker, and bundled sliders and page builders are the usual stumbling block.

Remove anything nobody uses. Every plugin left installed is one more thing to keep updated.

Update in stages

On the copy, deactivate the plugins and update WordPress itself. It usually copes with a long jump, because it upgrades its own database as part of the process.

Then reactivate and update the plugins individually, testing the site after every one: the home page, the busiest pages, the menu on a phone, and every form, with a test message sent and received.

The theme comes next. If someone edited its files years ago, updating will overwrite those changes, so compare first and move them into a child theme, a small companion that holds customisations separately.

Last, switch the copy to a current PHP version and test again. Some old plugins rely on functions PHP 7 no longer has.

A worked example

A barber school with two classrooms and a cutting floor, where the public get inexpensive cuts from supervised students, had a WordPress site built in early 2013 listing programs, intake dates and walk-in hours.

In April someone in the office saw the update notices and updated WordPress and every plugin in one go. The home page went blank.

The host restored the previous night's backup. The culprits were an events plugin untouched since 2013 and a theme slider whose scripts no longer worked with the newer jQuery, the script library WordPress includes.

The upgrade was redone in stages on a copy: a maintained events plugin replaced the old one, and a single photo of the cutting floor replaced the slider.

Two unused plugins went, the rest were updated one at a time, and the server moved from PHP 5.3 to 5.6. The finished copy replaced the live site on a quiet Sunday morning.

When to stop and rebuild

Sometimes the copy shows that upgrading is not worth it: the theme is abandoned, heavily edited and not built for phones, and every fix uncovers another.

A site built in 2013 may not be mobile-friendly at all, and Google's stronger mobile-friendly signal finished rolling out this month.

Then the upgrade becomes a rebuild on current WordPress with a maintained theme, keeping the content and page addresses, a decision best made after someone has looked at the copy.

Keeping it current afterwards

The point is never having to do this again: a little attention often, instead of a lot every few years.

Leave automatic minor updates switched on. They are how 4.5.2 reached most sites this month without anyone clicking anything.

Major versions, like 4.5 in April, still need someone to click update, after a test on the copy, within a few weeks.

Check plugins monthly and remove what is unused. And name who does it: a maintenance arrangement with your developer or a named person in the office, but someone.

The counter-case

A small brochure site with three plugins and a theme from the WordPress directory may update cleanly in one sitting, with a backup in hand.

A site due to be replaced in the next few months may only need its security sorted out now, with the full upgrade folded into the rebuild.

The copy costs time to set up and test, and for a simple site the stages can be shorter, but they should still happen in order.

For any site this far behind, though, the advice holds: back up, work on a copy, update in stages, and then keep it current.

Stage by stage

  1. Take a full backup and check it.
  2. List every plugin with its version.
  3. Make a copy on a private address.
  4. Replace abandoned plugins before updating.
  5. Update WordPress, then plugins one at a time.
  6. Move PHP forward once everything works.
  7. Name who keeps it current afterwards.

Step four decides how smoothly the rest goes. Most of the breakage in a long-delayed upgrade comes from plugins nobody maintains, and replacing them first removes the likeliest failures before they happen.

Testing a single major release before clicking update is covered in testing WordPress 4.5 before clicking update.

Frequently asked questions

Can I update everything at once?

On a site many versions behind, that often breaks it, and nobody can tell which update caused the problem. Update in stages on a copy instead.

Why has my site never updated itself?

Automatic minor updates began with version 3.7. A site built on an earlier version never received them, so it missed every security fix since.

What order should updates happen in?

Backup and copy first, then WordPress itself with plugins deactivated, then plugins one at a time, then the theme, then PHP, testing after each stage.

How do I know a plugin is abandoned?

Look it up in the plugin directory. A plugin missing from it, untouched for two or three years, or never tested with a recent WordPress is a warning.

What if the theme was edited directly?

Updating it will overwrite those edits. Compare the files first and move the changes into a child theme, which holds customisations separately.

When is rebuilding better than upgrading?

When the theme is abandoned, heavily edited or not built for phones, and every fix uncovers another. Decide after looking at the copy, not before.

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.

WordPress site untouched since it launched?

Ask us for a review. We will list what is installed, what is abandoned, and the safest order to bring it current.

Start a Conversation