Fleet Handbook
Hosting with multiple PHP versions — An inherited fleet is a PHP audit you have not done yet
Written for whoever inherited twenty sites of assorted vintage and now has to decide, per client, who pays for modernity.
Straight answer first
Run every site on cPanel hosting with a per-site PHP selector, so the current release is the default for new builds and the awkward legacy site gets a clearly dated sunset lane rather than a permanent home — a Pro plan carries the multi-site room to do that.
The reason this matters commercially rather than technically is that PHP end-of-life is a cost with a date attached, and somebody has to be told about it in advance. If that conversation happens after the version stops receiving security patches, the cost has already transferred to you.
Written by the Hosting Seller staff · Checked 24 August 2026
Free
Migration into the account
24/7
Cover at any hour
Daily
Backups across every account
$0
To open a new account
Nobody chooses a mixed-version fleet. It accumulates: a site built in 2018 by somebody else, a plugin the client will not replace, a bespoke integration whose author is unreachable. The account ends up carrying several eras at once, and one global setting cannot serve them.
The technical answer is straightforward — choose the version per site. The operational answer is harder, because it involves telling a client that something they consider finished has an expiry date on it.
Auditing what you have actually taken on
Start with a list: every site, its current PHP version, and whether anybody knows what breaks above it. That third column is usually empty, and filling it is the whole job.
Filling it does not require guesswork. Clone the site to staging, raise the version on the copy, and walk the pages that matter — checkout, forms, admin. An afternoon spent on a fleet of twenty converts a vague anxiety into a short list of genuine blockers.
Record the finding per client rather than per site, because the conversation that follows is with a person and a budget, not with a hostname.
Where the setting lives, and who can reach it
On cPanel the PHP version is chosen per site rather than once for the account, with extension toggles and per-site settings in the same screen. On a reseller arrangement you set that from the account you administer, and you decide whether the client can see it at all.
Leaving the selector visible to a competent client is fine. Leaving it visible to a client who reads a forum post about performance is how a site gets moved to a version its plugins have never seen, on a Sunday, without a backup. Judge that per account.
New releases arriving promptly matters here as much as old ones remaining available. A supplier who ships 8.x years late holds your whole fleet back; one who removes old versions on their own timetable transfers an emergency to you at a moment of their choosing.
The client who will not fund the upgrade
This is the real subject of the page. A client with a working site does not experience an end-of-life notice as urgent, because nothing visible is wrong. Your job is to make the risk legible without sounding like an upsell.
What works is a date and a consequence, in writing: this version stops receiving security patches on a stated date, after which the site continues to run and stops being defensible. Offer the sunset lane as a deliberate, time-boxed decision rather than as neglect, and put the end of the lane in the care plan.
Where they still decline, isolate. A legacy site on its own account with its own quota and its own credentials limits what a later compromise reaches, which is the mitigation available when the upgrade is not.
Writing end-of-life into the care plan
Add a clause naming who is responsible for keeping the application compatible with a supported runtime, and what happens when it is not. Two sentences prevent the argument where a client believes a maintenance retainer covered a rebuild.
Schedule the sweep rather than reacting to it. Once a quarter, list versions across the fleet, raise anything with no blocker, and re-open the conversation on anything with one. Staging makes each of those a rehearsal rather than a gamble, and daily backups underneath make the rehearsal cheap.
The performance argument is worth using, because it is real and it is a benefit rather than a warning: the same application generally runs measurably quicker on a current release than an old one, which turns the selector into a free improvement you can point at rather than a chore you are imposing.
Why we say what we sell
The recommendation here is a plan on our own shelf and we would rather write that at the top than bury it. What is left is the reasoning and the specifics, both of which survive being checked against another supplier.
Per-site PHP selection, staging and daily backups are inside the plan price rather than sold back per site, which is what makes a quarterly fleet sweep affordable to actually perform.
- PHP chosen per site rather than per account
- Extension toggles in the same screen as the version
- Staging available to rehearse a version bump
- Daily backups underneath every change
Why Hosting Seller
On every plan, as standard
Per-site, not per-account
The version is chosen site by site, so a 2018 build and a current one can share an account without either dictating to the other.
Extensions in the same screen
Per-version extension toggles cover the one legacy requirement that always turns up somewhere in an inherited fleet.
New releases without a wait
Current versions arriving promptly is what stops a supplier's timetable becoming your fleet's ceiling.
A rehearsal before every bump
Staging copies let a version change be tested on a copy, which is what makes a quarterly sweep a routine job rather than a gamble.
Isolation for the site that cannot move
A legacy site on its own account with its own quota limits what a later compromise can reach when the upgrade is refused.
A visible improvement to point at
The same application generally runs quicker on a current release, which gives the conversation a benefit rather than only a warning.
Price Tags Compared
How we compare with the household names
Typical sign-up and renewal prices across the market, set next to ours — the second number most comparison charts leave off.
| Line item | Hosting SellerBest seller | Typical big-brand host | Typical budget host | Typical loss-leader |
|---|---|---|---|---|
| Entry price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Price at renewal / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Renewal price on the entry plan is unchanged | ||||
| SSL on every plan | ||||
| Site migration included | ||||
| The entry plan uses NVMe storage | ||||
| Entry plan gets a backup daily | ||||
| Live human support, 24/7 |
*The number in our column is the cheapest plan on our shelf, priced on an annual term and pulled live from the very catalogue that feeds the pricing page, so it cannot drift out of date. Other columns show the ranges shared hosting tends to advertise inside each bracket: introductory rates that normally ask for a one-to-four-year commitment, then climb once that term expires. Naming individual competitors and printing their prices is something we have stopped doing. A figure we cannot re-check on the day you read it has no business sitting in front of you. So compare us with whoever you are genuinely weighing up, and read the renewal line first. That line tells you more than the headline ever will.
First Steps
From choosing to live
- 1
Build the version list before anything else
Every site, its current version, and what is known to break above it. The third column is the work, and it is the column that turns anxiety into a short list of real blockers.
- 2
Rehearse each bump on a copy
Clone, raise the version, walk checkout and forms. An afternoon across a fleet of twenty is cheaper than one emergency rollback, and it produces evidence you can show a client.
- 3
Put a date in the care plan
Name the end-of-life date and the consequence in writing, and offer the sunset lane as a time-boxed decision. Silence here transfers the cost of the eventual emergency to you.
In the Box
Packed with every plan
- PHP version selected per site from the control panel
- Extension toggles available per version
- Current releases available without waiting on a supplier
- Older versions still reachable, clearly marked as temporary
- Staging copies for rehearsing a version bump
- Daily backups with restores you run yourself
- Per-account isolation for a legacy site that cannot move
- Panel access you can grant or withhold per client
- cPanel, so the setting is where every tutorial says it is
- Migration into the account handled by our staff at no charge
Across the Counter
Things people ask us all the time
How do I audit PHP versions across a fleet I inherited?
List every site, its current version, and what is known to break above it. Then fill the third column by cloning to staging, raising the version on the copy and walking checkout, forms and admin. An afternoon across twenty sites turns a vague worry into a short list of genuine blockers you can quote against.
Should clients be able to change their own PHP version?
Judge it per account. A competent developer client should have it; a client who has just read a post about performance should not, because the failure mode is a Sunday version change with no backup and no rehearsal. It is a per-account decision, which is exactly why per-account control is worth having.
What do I tell a client who refuses to fund an upgrade?
Give them a date and a consequence in writing: the version stops receiving security patches on a stated date, after which the site keeps running and stops being defensible. Offer a time-boxed sunset lane rather than silence. If they still decline, isolate the site on its own account so a later compromise is contained.
Is there an argument for upgrading beyond security?
Yes, and it is the one clients respond to. The same application generally runs measurably quicker on a current release than on an old one, so the selector doubles as a free performance improvement. Leading with that is more persuasive than leading with the patch schedule, and it happens to be true.
Read next
Hosting for Nonprofit Projects
Carrying community projects alongside paying work, and what that arrangement actually costs.
CMS Hosting for Content Teams
Choosing a platform and a host together when several people publish to the same site.
PHP Hosting
Choose the PHP version site by site, on quick NVMe hardware.
WordPress Hosting
WordPress looked after for you — caching, staging copies and daily backups included.
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.
Get the whole fleet on versions you can defend.
PHP per site, staging to rehearse the bump, daily backups underneath, and a renewal figure that matches the joining figure.
See PHP Hosting plans