How agencies check PHP compatibility across many client sites

1. Make an inventory

Start with one row per site: the address, the host, the current PHP version, the host’s deadline if there is one, and the target version.

Read the PHP version the website actually runs: in the site’s WordPress admin under Tools → Site Health → Info → Server (wordpress.org), or in the hosting panel. Be careful with WP-CLI: it runs on the server’s command-line PHP, which can be a different version from the one serving the website. On our test site, the same WordPress installation gave two answers:

$ wp eval 'echo PHP_VERSION;'
8.2.29

WP-CLI is still handy for the rest of the inventory, for example the plugins with their versions:

$ wp plugin list --fields=name,status,version --format=csv
name,status,version
blogger-importer,inactive,0.9.3
compatnav-php-upgrade-checker,active,1.0.0
plugin-check,active,2.1.0
social-warfare,inactive,4.5.6

2. Prioritise

Sort by deadline first: a host’s date, or the end of security fixes for the version a site runs (PHP 8.2: 31 December 2026, php.net; more in PHP 8.2 reaches end of life). Then by risk: sites with code written for them, plugins that no longer get updates, and shops or forms, where a broken page costs the client money.

3. Check each site

Check the plugins and theme of every site for its target version, including inactive ones: a client may activate them later. The free CompatNav plugin does this on each site from Tools → CompatNav: it reads the code on the site’s own server, in small batches, and sends nothing anywhere. On our test site, 17 plugins and themes with 8,374 PHP files took about 70 seconds.

A code check can’t see problems that depend on the values a plugin works with while it runs, so the check after the switch (step 5) stays part of the plan.

4. Share the results with the client

Clients don’t need the technical details, but they need the decision: ready or not, what needs attention, who fixes it, and by when. Attach the full report for whoever wants more. The downloadable report from step 3 is a single HTML file that opens in any browser and can be emailed or printed to PDF; a CSV file of all findings is there for your own tracking.

Hello [name],

Your hosting company will move [site] to PHP [version] on [date]. We have checked all plugins and the theme for that version.

Result: [ready / not ready yet].
What needs attention: [plugin or theme, and what we will do: update, replace, or fix the custom code].
When: we plan the switch for [date and time], a few days before the host's date, with a backup and a way back.

The full report is attached. After the switch we will check the site and its error log for a week.

5. Schedule the upgrades

Give every site a date before its deadline, at a quiet time for that client. On the day: back up, switch in the hosting panel, click through the important pages, then watch the error log for a week. The step-by-step checklist works per site; for sites whose host has already set a date, start by asking the host five questions.

A tracking table

One row per site keeps the whole round in view (example rows):

For many sites at once: planned

Doing this site by site works today, with the free plugin on each site. For agencies, a Pro add-on is planned, not available, including all client sites in one view, scheduled scans with email alerts, and white-label client reports. Nothing is for sale; the Pro page lists what is planned.