On 31 December 2026, PHP 8.2 stops receiving security patches. That is the last day the version most of the WordPress world runs on is something you can defend to a client. Ninety-two days is enough time to move a 60-site portfolio if you start the audit this week, and not nearly enough if you start in December.

The numbers that make this a Q4 problem

The support calendar is public at php.net/supported-versions.php. As of today: 8.2 is security-only until 31 Dec 2026, 8.3 is security-only until 31 Dec 2027, 8.4 has active support until 31 Dec 2026 and security fixes until 31 Dec 2028, and 8.5 runs to the end of 2029. PHP 8.1 and everything older already receive nothing.

Now look at what WordPress sites actually run. WordPress.org publishes anonymised usage stats at api.wordpress.org/stats/php/1.0/ (checked 30 September 2026). Rounded: PHP 7.4 is 16.6% of sites, 8.0 is 4.0%, 8.1 is 11.1%, 8.2 is 24.5%, 8.3 is 25.8%, 8.4 is 8.8%, 8.5 is 3.3%, and the pre-7.4 tail adds about 4.3%.

Add up everything at 8.1 or below and you get roughly 37.5% of WordPress sites already running an unsupported PHP. Add 8.2 and it becomes about 62% that will be unsupported on 1 January 2027. If your portfolio looks like the average, six in ten of your client sites need a version change in the next three months. A care-plan portfolio is probably better than the average. It is probably not at zero.

Pick the target version first

Don't audit against "newer". Audit against one specific version, because the plugin checks below depend on it.

The WordPress core compatibility table (make.wordpress.org handbook) lists WordPress 6.9, 7.0 and 7.1 as compatible with PHP 8.2 through 8.5. The current release, 7.1.2, still only requires PHP 7.4, so core will not force anyone's hand. Your plugins will.

WooCommerce is the clearest example: WooCommerce 10.8 and later requires PHP 8.3 or greater and WordPress 6.9 or greater (WooCommerce server requirements, checked September 2026). A store stuck on 8.2 is also stuck on an old WooCommerce, and old WooCommerce is where the payment-related CVEs live.

My recommendation for a care-plan portfolio: standardise on PHP 8.3 for this quarter. It has 15 months of security support left, every mainstream plugin has had almost two years to catch up, and it clears the WooCommerce floor. Go to 8.4 only on sites where you have staging and a reason. 8.5 is for your own site, not a client's.

The audit, site by site

You need one row per site with six columns: current PHP, host, WordPress version, page builder, plugins with unknown 8.3 support, and a lane. If you keep sites in a management dashboard, most of these columns already exist; if you don't, a spreadsheet and an afternoon will do for 60 sites.

For each site, in order:

  1. Record the PHP version the site actually serves, not what the host's control panel says the default is. Site Health → Info → Server shows it. Hosts commonly set new sites to a current version and leave old ones where they were.
  2. Check WordPress core is on 7.x. Anything below 6.9 gets a core update before a PHP change, because you want one variable moving at a time, and because WooCommerce and an increasing number of plugins now require 6.9 anyway.
  3. List plugins whose readme "Requires PHP" is below 8.0 or missing. That header is the author telling you what they tested; an old or absent value is a flag, not a verdict. Check the plugin's changelog for any mention of PHP 8.x. A plugin with no update in 18 months and no PHP 8 mention goes on the suspect list.
  4. Check the theme the same way. Page builders are the usual offenders because they ship their own PHP that predates the site.
  5. Look at the last 30 days of the PHP error log for deprecation notices. Deprecated warnings on 8.2 are the things that become fatals on 8.3 or 8.4. If the site has no log access, that is itself a finding: put it in the notes and ask the host.
  6. Assign a lane: clean (mainstream plugins, all flags clear), questionable (one or more suspects, or custom code), or stuck (an abandoned plugin or theme that cannot run on 8.3).

That last step is deliberately the same three lanes from PHP upgrades across 60 sites without a weekend of rollbacks. This post is the audit; that one is the execution.

Tools that help, and what they miss

Plugin-based compatibility scanners, such as the PHP Compatibility Checker plugin, run static analysis on the code that is on the site. They are worth running because they are cheap. They miss three things: code paths the scanner can't reach (anything built dynamically), behaviour changes that produce wrong output rather than errors, and third-party APIs the plugin calls that may have moved on. Treat a clean scan as "no obvious blockers", not as "tested".

The only test that counts is the site running on the target version and the money page working. Staging is the honest way to get that. Where there is no staging, the batch-of-ten process with a restore point and a fast rollback from the post above is the fallback, not the plan.

The calendar

Ninety-two days, minus the fortnight around Christmas when clients don't want to hear from you, leaves about ten working weeks. A schedule that works for 60 sites:

  • Weeks 1–2 (October): audit all 60 sites, assign lanes, email the stuck-site clients.
  • Weeks 3–6 (October–November): clean lane in batches of ten, one batch every two or three days, roughly 35–40 sites.
  • Weeks 7–9 (November to early December): questionable lane, one site at a time, on staging, roughly 15–20 sites.
  • Week 10 (early December): stuck lane, about 5 sites: rebuild quotes accepted or written risk acceptance signed.

The stuck-lane email goes out in week two, not week nine, because a rebuild quote takes a client a month to approve and nobody approves anything between 15 December and 5 January. The wording is short: "Your site's theme cannot run on a PHP version that will still receive security fixes after December. The options are a rebuild, quoted separately, or keeping it on the old version with the risk documented and accepted in writing."

What to tell the other 55 clients

Nothing long. One line in the October report: "We're moving your site to PHP 8.3, a currently supported version, before the end of the year. We take a backup and a restore point before each change and check the key pages afterwards." Then, when it's done, a line in the activity log with the date and the version. The client who asks in March why their site behaved differently in November deserves an answer that isn't your memory.

If you run WPClientHub, the site health score counts the PHP version, so old-PHP sites sort to the top of the worst-first list, the activity log records the change, and safe updates take a restore point and a screenshot diff around any plugin or core update you make on the same visit. The PHP switch itself still happens at the host; the audit table is the part that gets faster.

Where this leaves you

Standardise on 8.3, audit all 60 sites in the first two weeks of October, and send the stuck-lane emails before anyone else starts talking about Christmas. The upgrade work is routine once the audit exists; the audit is what most agencies skip until the deadline makes it urgent. If you want the per-site PHP version, health flags and activity log in one table instead of a spreadsheet, WPClientHub is free for 3 sites, with paid plans from $19/month.

WPClientHub Team