PHP Upgrade Checklist and How to Test What Breaks

A PHP upgrade is a routine job on paper and a risky one in practice, because the language underneath a website changes while every plugin, theme and line of custom code stays the same. Good PHP upgrade testing for business websites is what stands between a quiet version change and a contact form that stops sending on a Monday morning. The checklist below covers the whole job from the business owner’s side, from the first audit to the weeks after the switch.

Most guidance on the subject is written for developers or for one hosting control panel. That leaves the people who own the website and carry the cost if it breaks without a clear picture of what needs checking and why. If you need a refresher on how version numbers and support periods work, PHP versions explained sets out the basics. Given how much of the internet runs on PHP, the same job comes round for almost every business website sooner or later.

Why a PHP Upgrade Needs a Plan

A PHP upgrade needs a plan because each new branch removes or changes features that older code may depend on. The official PHP supported versions page shows that each branch gets two years of active support and two further years of security fixes only, after which it reaches end of life. PHP 8.2 reaches that point on 31 December 2026, so websites still running it have a fixed deadline. PHP 8.3 follows a year later, as the guide to when PHP 8.3 reaches end of life explains.

Running past that date leaves known security holes unpatched, which is covered in detail in what happens if your website runs an end of life PHP version. The upgrade itself is the fix. Doing it in a planned order, with a way back, is what keeps the fix from becoming a new problem.

Audit What the Website Runs Today

The first step is a written record of everything that touches PHP on the website. WordPress shows the current PHP version and server details under Tools and then Site Health. The Site Health screen documentation explains where to find each item. That gives you a starting point, but the audit needs to go further than one screen. Our guide to what PHP is used for explains how much of a WordPress website depends on it.

• The current PHP version and the version you are moving to.
• Every active plugin, its version and the date it was last updated by its developer.
• The theme, any child theme and whether it was built bespoke or bought off the shelf.
• Custom code, such as functions added to the theme, small custom plugins and any scripts outside WordPress.
• Server extensions the website uses, such as image processing, mail handling or database drivers.
• Connections to other systems, such as payment gateways, CRMs, booking tools and stock feeds.

Plugins that have not been updated by their developer for a long time deserve a hard look. An abandoned plugin is the most common source of trouble after a version change. It may be better replaced before the upgrade than patched afterwards.

Scan the Code for Compatibility Problems

A compatibility scan reads the website’s code and flags anything that will not work on the target PHP version. The standard tool for this is PHPCompatibility for PHP_CodeSniffer, a set of rules that checks code against higher and lower PHP versions and reports each problem by file and line. A developer can run it across the theme, custom plugins and any bespoke code in one pass.

WordPress core is tested separately. The PHP compatibility and WordPress versions page in the core handbook lists which PHP branches each WordPress release supports. If the website runs an older WordPress release, updating WordPress itself may need to come first. Scanners read code without running it, so they miss problems that only appear when a page loads with real data, which is why the scan is a starting point and the staging test is the proof.

The scan results also help you judge the size of the job. A handful of warnings in one plugin is a small fix, whereas errors spread across a bespoke theme point to a longer piece of development work that needs budgeting and scheduling. If that work starts to look like a rebuild, the comparison of PHP, Python or Next.js for a business website is worth reading first.

What Typically Breaks Between PHP Versions

What breaks depends on which versions you are moving between. The PHP manual publishes a migration guide for each branch. The guides for PHP 8.0, PHP 8.2, PHP 8.3 and PHP 8.4 list every removal, deprecation and change in behaviour. The table picks out the changes most likely to affect a business website.

Deprecations rarely break anything on the day, because the feature still works and PHP logs a notice. Removals are different, since any code that calls a removed function stops at that point. A website jumping from PHP 7.4 to a PHP 8 branch meets every change in between at once, which is why older websites carry more risk than ones that move a branch at a time.

The migration guides are written for developers, so the useful question for a business owner is which of these changes touch code on your own website. The compatibility scan answers that for the code it can read. The staging test answers it for everything else.

Back Up and Build a Staging Copy First

No PHP version should change on a live website until there is a full backup and a staging copy running the target version. The backup needs both the files and the database, stored away from the server. Someone also needs to have checked that it restores. The WordPress guide to updating PHP makes the same point and adds that reverting also needs the host to switch the PHP version back.

The staging copy should match live as closely as possible, with the same plugins, theme, content and server setup. Only the PHP version should change. That way any difference in behaviour comes from the upgrade and nothing else. The same discipline applies to plugin and core updates. The guide to common WordPress update problems covers the faults that show up most often.

Staging copies of shops and membership websites need care with live data. Payment gateways should run in test mode and outgoing emails should be held or redirected, so that testing does not charge real cards or send messages to real customers.

Test the Parts of the Website That Earn Money

A good test plan starts with the features the business depends on, not the home page. Pages that load correctly can still hide a form that fails to send or a checkout that stops at the payment step, so each test should complete a real task from start to finish on the staging copy.

• Every contact, quote and enquiry form, checking that submissions arrive and land in the CRM if one is connected.
• The full checkout on a WooCommerce shop, including coupons, shipping rules, payment and the order confirmation.
• Logins for customers, members and staff, plus password resets.
• Integrations with payment providers, CRMs, stock systems and any other software that exchanges data with the website.
• Scheduled tasks such as backups, feed imports, subscription renewals and scheduled posts.
• Transactional emails, including order confirmations, account emails and form notifications.

WordPress runs its timed jobs through its own scheduling system, described in the WordPress cron documentation. These jobs only run when triggered, so they are easy to miss in a quick click through. For shops, what to do when a WooCommerce update breaks your store lists the checkout faults worth testing for.

While testing, turn on error logging so that problems hidden from the screen are still recorded. The debugging in WordPress documentation explains how WP_DEBUG and WP_DEBUG_LOG write errors and notices to a log file without showing them to visitors.

Switch Over and Keep a Way Back

The switch on live should follow the same order every time, so nothing is skipped under pressure. Once staging has passed the full test plan, the change on live is a short, controlled job.

Agree the rollback trigger before you start. If a feature the business depends on fails and cannot be fixed within the window, switch the PHP version back and restore from the fresh backup if any data has changed, then return to staging to find the cause.

Monitor Error Logs After the Upgrade

Monitoring after the switch catches the problems that testing missed, because real visitors use a website in more ways than any test plan covers. Check the PHP error log and the WordPress debug log daily for the first week, then weekly for the following month.

Look for fatal errors first, since each one is a page or feature that stopped working for someone. Warnings should be fixed next. Deprecation notices go on a list for the next upgrade. The guide to what is changing in PHP 8.6 lists the deprecations coming in the next release. Uptime monitoring and a check on form submissions and orders against the weeks before the upgrade will show whether anything has dropped without an error being logged.

Leave error logging on for this period but keep errors hidden from visitors. Showing PHP errors on screen exposes file paths and server details that attackers can use, so the log file is the right place for them.

How Long a PHP Upgrade Takes and What Effort to Expect

The time a PHP upgrade takes depends far more on the website than on PHP itself. A current WordPress website with well maintained plugins and a clean theme may need little more than a scan, a staging test and a planned switch. A website that has skipped several versions or carries bespoke code written years ago can need real development work before it is ready. That work should be scoped once the scan results are in. It is also the point where some owners ask whether PHP is still relevant for business websites or whether a rebuild makes more sense.

The effort splits into four parts. There is the audit and scan, the fixes the scan points to, the staging test and the live switch with monitoring afterwards. Of those, the fixes are the only part that varies widely, so the scan is the point to set a realistic plan and to decide whether any plugin should be replaced rather than repaired. With PHP 8.2 support ending on 31 December 2026, starting that work now leaves room to fix problems without a deadline forcing the switch. A separate post on PHP 8.2 end of life sets out what that date means.

For websites on a support plan, the upgrade should not be a separate project at all. Priority Pixels includes PHP version upgrades in its WordPress support retainer, alongside backups stored off the server and uptime monitoring, with core, plugin and theme updates tested against a staging copy before they touch the live website. Treated as regular maintenance, each PHP upgrade becomes a smaller step and the website never falls far behind.