WordPress 7.0: What to Do Before and After You Upgrade

What a major WordPress release actually changes for you

A major WordPress release changes the platform your plugins and theme are built on. Core itself is rarely the thing that breaks a site. What breaks is the code around it, a plugin that relied on a function that moved, a theme that assumed an older editor, or a customisation written years ago by someone who has since moved on.

That is why the useful question before any major upgrade is not "is the new version good", it is "is my particular combination of plugins and theme ready for it". Those are completely different questions and only the second one can take your site down.

Do not upgrade on day one

There is no prize for upgrading first. Plugin developers need time to test against a new major release and ship compatibility fixes, and the first couple of weeks after any major version is when incompatibilities surface publicly. Waiting a short while costs you nothing and lets other people find the sharp edges.

The exception is a security release. Those should be applied quickly, and they are usually minor point releases rather than major version jumps, so the risk profile is different.

The pre-upgrade checklist

Run through this before you touch the live site. Every item exists because skipping it has cost somebody a weekend.

1. Take a full backup, files and database, and store it off the server. Verify it downloaded properly rather than trusting that the job ran.
2. Write down your current versions: WordPress, PHP, every plugin, and your theme. This is your rollback target.
3. Check compatibility. For each plugin, look at its "tested up to" version and when it was last updated. A plugin that has not been updated in two years is a bigger risk than the upgrade itself.
4. Identify anything custom. Custom code in a child theme, a bespoke plugin, or snippets added through a code plugin are the least likely things to have been tested against a new release.
5. Check your PHP version against what the new release expects, since major WordPress releases often raise the minimum.

Test on staging, always

Clone the live site to staging and upgrade there first. This is the single step that separates a routine upgrade from an incident. Many hosts give you one-click staging, and if yours does not, that is worth more than most other hosting features.

On staging, upgrade core, then walk the site as a user would. Load the homepage, submit the contact form and confirm the email actually arrives, log in and out, run a search, and if you sell anything, put a product in the cart and go all the way to the payment step. Check on a phone as well as a desktop, because layout breakage often shows up at mobile widths first.

Watch the error log while you do it. A fatal error is obvious, but a plugin quietly throwing warnings is a signal that something it depends on has changed.

Abandoned plugins are the real risk

If a plugin has not been updated in a long time, a major core release is when it tends to finally fail. You have three options and only one of them is good: replace it with a maintained alternative, pay someone to maintain a fork of it, or accept that you are running unsupported code on a site that matters.

This is also a good moment to delete plugins you no longer use. Deactivated plugins still sit on disk, still contain whatever vulnerabilities they shipped with, and still need updating. If you are not using it, remove it.

If the upgrade breaks something

Work through this in order, from least destructive to most.

1. Note the exact error. Enable debug logging and read the message rather than guessing. The log usually names the file, and the file usually names the plugin.
2. Deactivate the suspect plugin. If you cannot reach the dashboard, rename its folder over SFTP, which force-deactivates it and gets you back in.
3. Switch temporarily to a default theme. If the problem disappears, it is your theme, not core.
4. Roll back the single plugin that caused it rather than rolling back everything.
5. If the site is down and revenue is affected, restore the backup first and investigate afterwards. Diagnosing on a live broken site is the expensive way to do it.

After the upgrade

Once you are on the new version, check the things that quietly break and that nobody notices for weeks: contact forms still delivering mail, scheduled posts still publishing, backups still running, caching still on, and Search Console not reporting new crawl errors. Re-run those checks a week later too, because some failures only appear on the next scheduled run.

Keep the pre-upgrade backup for a while. The bug you find in three weeks is easier to understand when you can compare against the version before.

The short version

Back up, check compatibility, test on staging, upgrade in order, verify the things that make you money, and keep a rollback path. That workflow is the same for every major WordPress release, which is the point. If you would rather not think about it, keeping sites patched and tested is exactly what a care plan is for.