PHP upgrades are the maintenance task everyone agrees is necessary and quietly postpones. One site is easy. Sixty sites, each with a different theme, a different pile of plugins and a client who "doesn't want anything to change", is where agencies lose weekends. The fix is not braver upgrades, it is a process that makes each upgrade small, reversible and boring.
Why it piles up
Nobody schedules PHP upgrades because nothing breaks on the day you skip them. The site keeps working on the old version until a plugin drops support, the host retires it, or a security fix stops arriving. By then you are two versions behind on half your portfolio and the upgrade is no longer routine.
The version lifecycle is public. The official list of supported branches, with active support and security-only end dates, is at php.net/supported-versions.php. Put that page in your calendar quarterly. A version that has left security support is not a matter of taste, it is a liability you are carrying for the client without telling them.
Step one: inventory before anything
You cannot plan an upgrade for sites you have not counted. Build a simple table of every site, its current PHP version, its host, and its most fragile dependency:
| Site | PHP now | Host | Risk notes | |---|---|---|---| | Client A | 7.4 | Shared | Old page builder | | Client B | 8.1 | VPS | Custom plugin | | Client C | 8.3 | Managed | Clean |
You will find the interesting facts here. Perhaps eight sites share the same abandoned plugin, or the majority of your old-PHP sites live on a single cheap host. Clusters tell you where the pain is and let you fix one cause for many sites.
Step two: sort into three lanes
Not every site deserves the same treatment. A brochure site with a stock theme and mainstream plugins is a different job to a WooCommerce store with a decade of customisations.
- Lane 1, clean sites. Maintained theme, mainstream plugins, no custom code. Upgrade in batches.
- Lane 2, questionable sites. One or more plugins with unclear PHP support, or custom code. Test on staging first, one at a time.
- Lane 3, stuck sites. Abandoned plugins or a theme that cannot run on a current version. These need a project, quoted and scheduled, not a maintenance ticket.
Suppose the split across 60 sites is 36, 18 and 6. That is a made-up ratio, but it shows the shape: the majority is routine, a minority needs attention, and a handful needs a conversation with the client. The lanes stop the hard 10% from delaying the easy 60%.
Step three: batches, not a big bang
Upgrade Lane 1 in batches of about ten, spread over several days. With 36 clean sites that is four batches. The point is not speed, it is blast radius. If batch one shows a pattern, say a specific plugin throws warnings on the new version, you have found it on ten sites, not sixty, and you fix it once.
Within each batch, use the same routine every time:
- Take a backup and a restore point before touching anything.
- Switch the PHP version at the host, which is usually a setting, not a rebuild.
- Load the homepage, one interior page, and the money page such as checkout or the contact form.
- Check the error log for new warnings or fatals.
- Compare before and after screenshots if you can. A broken layout is faster to see than to describe.
- Only then mark the site done.
Notice that most of that is verification. Changing the version takes a minute, and proving the site still works is the work.
Roll back fast, or don't roll out
Every upgrade needs a rollback path that takes minutes. On most hosts, changing the version back is the same setting flipped the other way, and that is your first response to a failure. Restoring from backup is the second.
The mistake that causes weekend rollbacks is having no defined trigger. Decide up front: if the money page breaks or the error log shows a fatal, roll back immediately and log the site for Lane 2. Do not debug live on the client's production site at 6pm on a Friday. Reverting is a success, because it took a failure from customer-facing to a ticket.
The same principle applies to plugin and core updates. Restore points and visual comparison make a bad update a two-minute undo instead of an incident, which is the basis of how safe WordPress updates work.
Step four: tell the client, briefly
Most clients will not read a technical explanation, but silence is worse. A short note is enough: "We're moving your site to a newer, supported PHP version this week. We'll take a backup first and check the key pages afterwards. You shouldn't notice anything."
For Lane 3 sites, be direct about money. "Your theme can't run on a supported PHP version. Options are a rebuild, or we keep it on the old version with the risk documented and you accept that in writing." The written acceptance matters. It moves the decision, and the responsibility for it, to the person who owns the site.
Keep a record
Log which version each site is on and when it changed. It answers questions later: which sites were affected by a particular plugin issue, which ones you upgraded before a host deadline, why a site behaved differently in March. An activity log that records the change with a date is worth more than your memory.
Keep it from piling up again
An upgrade project that ends leaves you exactly where you started in two years. The habit that prevents that is small: a quarterly look at the supported-versions page, and one line in your onboarding checklist saying new sites go live on a currently supported version. Then the backlog never rebuilds, and "PHP upgrade day" becomes ordinary maintenance.
Where this leaves you
Inventory first, sort into three lanes, upgrade in batches of ten, verify before you call anything done, and define your rollback trigger before you begin. It is duller than a heroic weekend and it works far better. WPClientHub takes a restore point and screenshot comparison around updates and tracks each site's state in one place, and it is free for 3 sites if you want to try this on a real client site: register here.