Reseller playbook · Beginner · 10 minutes
How to change your PHP version — Who Pays When a PHP Upgrade Breaks a Client's Site
The upgrade takes ten minutes; the argument about the broken plugin takes a fortnight if nobody agreed in advance who owns it.
Straight answer first
Set PHP version as a fleet policy with a stated supported floor, and settle in writing who pays for remediation before you upgrade anything — because the ten-minute change is easy and the plugin that stops working is a commercial conversation.
Version is chosen per site from the panel, so a stubborn client build can hold position while everything else moves forward. Treat that as a ramp with an end date, not a permanent parking space.
Written by the Hosting Seller staff · Checked 24 August 2026
Beginner
Skill assumed
5
Stages per wave
Free
Cover included
Tested
Tested on our own platform
Written for whoever administers a shelf of client sites rather than one. It assumes builds of varying age, at least one client who will not fund a fix, and no wish to spend a month on this.
The rollback is instant, which is what makes the technical risk low. The risk that is not low is contractual, so read the liability section before the steps.
Fleet policy beats per-account heroics
Decide the version you support, publish it to your clients as a policy with a date, and move everyone to it in waves. That single decision replaces dozens of individual judgement calls, and it gives you something to point at when a client asks why their site is being touched at all.
The alternative — upgrading each account when somebody happens to notice — leaves you with a fleet where no two sites are alike. That is not just untidy: it means every future problem starts with finding out what this particular account is actually running.
The liability conversation, held in advance
An unsupported PHP release stops receiving security fixes, which makes staying put a risk you are carrying on the client's behalf. Moving forward can break an abandoned plugin, which is a cost somebody has to bear. Both facts are true at once and neither is negotiable, so the only variable is who pays.
Put it in the care plan: the supported version, the notice period, and that remediation of third-party components is chargeable. Clients who have read that sentence before the upgrade react to a broken plugin as a scheduled task. Clients who read it afterwards react to it as your mistake.
The stubborn account, and the ramp off it
Because version is set per site, one legacy build can stay behind while the rest of the fleet advances. That is a useful safety valve and a terrible permanent arrangement, because the account left behind is the one running unpatched software on infrastructure you are responsible for.
So give the exception a deadline and a price. Either the client funds the work to bring the site forward, or the site moves off your care plan, or you accept the risk knowingly and in writing. Drifting is the only option that leaves you exposed without anyone having decided anything.
Rolling it out in waves
Start with your own sites, then the simplest client builds, then the ones with commerce or bespoke code. Ten accounts a week with a walk-through of the pages that matter is a rhythm you can maintain, and a wave that goes wrong teaches you something before it reaches the client who would mind most.
The platform makes the waves cheap. Version is per site from the panel, staging copies exist so a shop can be tested before it is switched, and daily backups run across every client account with restores you run yourself — so the worst case is minutes rather than a rebuild.
Why a fleet rollout is practical here
PHP versions are picked per site from the panel, so one client account can carry a legacy build and a current one side by side while you work through the list.
Staging copies and daily backups exist on every client account, which is what turns a version rollout from a gamble into a schedule.
- One supported version, published as policy
- Remediation chargeable, agreed in advance
- Exceptions given a deadline and a price
- Rolled out in waves, easiest first
Why Hosting Seller
On every plan, as standard
A policy, not a favour
Replaces dozens of individual judgement calls with one supported version and a stated date.
Liability settled first
Puts who-pays-for-the-broken-plugin into the care plan before anybody upgrades anything.
Exceptions with an end date
Lets a legacy build hold position, on a deadline and a price rather than indefinitely.
Waves you can sustain
Your sites first, then the simple ones, then commerce — a rhythm rather than a project.
Per-site control
Version is set per site from the panel, so one client's old application blocks nothing else.
Two-minute rollback
The same selector switches back instantly, and daily backups sit behind every client account.
First Steps
From choosing to live
- 1
Inventory what every client site is running
Read the version per domain across your accounts and write it down. Sites inherited from other providers are usually several releases behind, and you cannot plan waves against a fleet you have not counted.
- 2
Publish the supported version and the notice period
One version, one date, and a line saying that fixing third-party components is chargeable. This is the step that converts a future argument into a scheduled piece of work.
- 3
Test the risky builds on a staging copy
Commerce and bespoke code get a staging copy first; brochure sites can be switched and walked through. The tested-up-to notes on old plugins and themes tell you which is which before you start.
- 4
Switch in waves, then click through what matters
Ten accounts at a time, checking the pages that earn the client money. The change applies immediately, so anything unhappy declares itself within a minute or two rather than next week.
- 5
Roll back, fix the component, then go again
The selector reverses in seconds, which makes trying cheaper than worrying. The error names the piece that could not cope — update or replace it, bill it as agreed, and take the jump a second time.
In the Box
Packed with every plan
- PHP versions picked per site from the panel
- Staging copies so client changes are tested first
- Daily backups across every client account
- Restores you run yourself from the panel
- A cPanel of their own for every client, WHM for you
- SSH, Git and Composer on the plans built for developers
- LiteSpeed caching at the server, not bolted on by plugin
- NVMe SSD storage on every reseller tier
- Site migration done for you by our staff, at no charge
- Real people answer, for you and for them
Across the Counter
Things people ask us all the time
Can I move a client account to a newer PHP release without asking them?
Technically yes, and it is usually the right thing to do — but tell them first. A published supported version with a notice period turns the upgrade into maintenance they expected, which is a very different conversation from a site behaving oddly on a Tuesday.
A client's site broke after the upgrade — who pays for the fix?
Whoever your care plan says. The workable position is that the platform version is your responsibility and third-party plugins and themes are chargeable to remediate. Written down in advance it is a scheduled task; agreed afterwards it is a dispute.
Can two sites on one client account run different versions?
Yes — version is set per domain, so a legacy application can hold position while everything else on the account moves forward. Treat that as a ramp with a deadline rather than a permanent home for the stragglers.
How do I move a client up a plan as they grow?
In place. Plan changes are made from the client area with no migration and no downtime, and the range runs from shared accounts through VPS to whole dedicated servers, so growth is a line change on an account you already administer.
Read next
Drupal Hosting
Drupal hosting with Composer, Drush and the PHP version set per site.
PHP Hosting
Pick the PHP version site by site, on quick NVMe hardware.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Run a fleet you can keep current.
PHP per site, staging copies, daily backups per client account and restores you run yourself.
See PHP Hosting plans