How to upgrade PHP on client WordPress sites without breaking them

The PHP security release of October 2026 was a useful reminder: some fixes don’t come from a WordPress update. When the flaw is in PHP itself, the fix is a newer PHP version on the server, and sites on a branch that no longer gets security fixes get no fix at all. This guide is a routine you can run on every client site to move it to a supported PHP version without surprises.

Why the PHP version matters more than it looks

Every PHP branch gets security fixes for a limited time. Once a branch stops getting them, any new flaw in it stays open, no matter how carefully you update WordPress, plugins and themes. PHP 8.1 and older no longer get official security fixes. Check php.net/supported-versions for the current dates of each branch.

There is a second reason. Plugin and theme authors drop support for old PHP versions over time. A site that stays on an old branch slowly loses access to plugin updates, and with them to security fixes in the plugins themselves.

Step 1: list the PHP version of every site

In WordPress you find it under Tools → Site Health → Info → Server. Your hosting panel shows it too. For each site, note the PHP version, the WordPress version, the theme, the page builder, whether it runs WooCommerce, and whether there is custom code in a child theme or a must-use plugin.

Then sort the list. Start with the oldest PHP versions, and within those with the sites that earn money or collect leads: shops, booking sites and sites with important forms.

Step 2: find what will block the move

Most PHP upgrades fail on one old plugin, an abandoned theme or a piece of custom code. Look for these before you switch:

• Plugins and themes that have not been updated in two years or more. Check the “Requires PHP” and “Tested up to” lines on their plugin page.
• Old versions of page builders and premium plugins whose licence has expired, so the site never received the versions that support newer PHP.
• Custom code in functions.php or must-use plugins. Functions such as each() and create_function() were removed in PHP 8.0, and PHP 8.2 warns about dynamic properties.
• Compatibility scanners can help, but they report false positives. Treat their output as a starting list, not a verdict.

Update WordPress, plugins and themes first, while the site still runs the current PHP version. Newer plugin versions usually support newer PHP. Do the updates and the PHP switch on different days, so you know which change caused a problem.

Step 3: test on a copy first

Make a staging copy of the site and set it to the target PHP version. Most hosts let you choose the PHP version per site. Turn on WP_DEBUG_LOG on the copy so errors go to a log file instead of the screen.

Then click through what matters for this client:

• The homepage and the two or three most visited pages, on desktop and mobile.
• Every important form: submit it and check the email arrives.
• On a shop: add to cart, checkout with a test order, the account page.
• In the admin: the editor and the page builder open, media upload works, settings pages load.

Afterwards, read wp-content/debug.log. Fatal errors must be fixed before you go live. Deprecation notices are warnings about the next upgrade; write them down, they can wait. Comparing screenshots of the key pages before and after catches the problems that don’t throw an error, such as a slider or menu that no longer renders.

Step 4: switch the live site at a quiet moment

Pick a moment with little traffic. Make a fresh backup of files and database right before the switch, and write down the current PHP version. Switch PHP in the hosting panel, clear the page cache and any object cache, and run the same checks as on the copy. Keep error logging to a file on for a day or two, so you catch the page nobody visited during your check.

Tell the client in one or two sentences what you did and why. A PHP upgrade is invisible when it goes well, and it is good maintenance work they should know about.

Step 5: know your way back

The rollback for a PHP upgrade is usually simple: switch the version back in the hosting panel. That is why you wrote down the old version. If one plugin turns out to be the problem, you have three options: update it, replace it, or stay on the previous supported branch for a short time while you sort it out. Never stay on an unsupported branch longer than needed.

When it is urgent: a security release for PHP itself

When a flaw is published in PHP, a WordPress update won’t fix it. Ask your host whether the patch release for your branch has been applied. A patch within the same branch, for example from one 8.3 release to the next, rarely breaks anything. The risky move is jumping to a new branch, and that is exactly the work this guide prepares you for. Sites on a branch without security fixes are the ones to plan first.

How Verploy handles PHP upgrades

On sites with an old PHP version, Verploy’s PHP upgrade check shows what is blocking the move and in which order to fix it. Every update is checked, and the risky ones are tested on a copy first. See how it fits a full maintenance routine on WordPress maintenance for agencies.