Blog / hosting
How to deprecate a PHP version on shared hosting
Most hosting platforms stall on retiring old PHP branches. Here is the sequence I use: count real usage, close the taps, and expire every exception.
Every hosting platform I have worked on carried a PHP version it should have retired years earlier. Usually two.
The reason was never technical. Flipping a version on a cPanel server takes seconds. What stalls the work is that nobody wants to own the ticket queue that follows, so the old branch stays on the menu year after year, until somebody finally counts how many accounts still use it and finds the number is bigger than anyone guessed.
The clock is louder than usual right now. PHP 8.2 has security support until the end of December 2026, which means that in eleven weeks every branch below 8.3 is unsupported upstream. Out on the public web, roughly 27% of PHP sites still run a 7.x release and almost 8% are still on PHP 5. If you operate a shared platform, some of that long tail is living on your fleet.
Here is the order I work in.
Count what is running, not what is configured
Two numbers get collected and a third gets skipped.
The easy ones are how many accounts have the old version selected, and how many of those served a real request in the last thirty days. Access logs, not uptime checks. A surprising share of any old-version population is parked domains and abandoned accounts, and those can be flipped on a Tuesday night with no notice at all.
The number teams skip is how many of the live ones would actually break. A fatal error on a removed function is a broken site. A deprecation notice in the error log is a tidy-up item that can wait, and it is not a reason to hold a branch open for another year.
You can sort that cheaply. Replay each account's home page and two or three known URLs against a server running the target version, then compare status codes. It misses logged-in paths, cron jobs and payment callbacks, so it is not a certificate of health. It is good enough to split the list into "flip it tonight" and "needs a person to look".
In my experience the split is lopsided. Most accounts sitting on an old branch are there because of a default somebody set in 2019, not because of code that needs it.
Close the taps before you announce anything
Nothing is more demoralising than a month of upgrade work undone by provisioning. Before any customer communication goes out, make the current version the default in every path that can create or reset an account: new signups, plan changes, restores from backup, inbound migrations, and whatever package templates your panel uses.
A restore that quietly puts an account back on PHP 7.4 is a bug, and it will not be reported as one.
Publish a date and say what happens on it
An email that encourages customers to upgrade produces close to nothing. I have watched it happen on every platform I have been part of.
What moves people is a specific date, the version their account will be moved to, and one sentence on what to do if that move breaks something. Put the same notice inside the control panel, where someone signing in to fix their site will actually read it. Send it more than once and send the last one about 48 hours out.
Expect most of your response volume in the final week. That is not a failure of the notice period, it is how deadlines work. Staff for it.
Make exceptions expire
Somebody will have a genuine problem: an abandoned e-commerce platform, a custom application whose developer is gone, a client in the middle of a rebuild. Give them an extension. Record it against the account with an end date, sixty or ninety days out, and make the end date something your tooling can report on.
Permanent exceptions are how a platform ends up serving PHP 5.6 in 2026. Every one of them looked reasonable on the day it was granted.
Be straight about the security argument
The security framing is the one most hosts lead with, and it is the weakest part of the case. An unsupported interpreter is a real risk, but it is rarely how these sites get compromised. Almost everything I have helped clean up arrived through an abandoned plugin or a reused password, and the PHP version was a footnote. I went through that pattern in what hosting teams get wrong about hacked sites.
The honest argument is carrying cost. Every branch you keep is a build to maintain, a set of modules to compile, an OS image to keep alive, a row in the support training, and a question in every hiring interview. That is where the money quietly goes, and it is the number worth putting in front of whoever signs off on the work.
Put it on a schedule instead of a project plan
The platforms that handle this well do not run deprecation projects. They run a standing quarterly item: retire the oldest branch, add the newest, move the default up one notch, and keep the supported list short enough to fit on a page. Dull, and it means you never have the conversation about PHP 5 again. The same thinking applies to panel and OS updates, which I wrote about in running cPanel at scale.
My own hosting company, DrivenHost, keeps a deliberately short supported version list for exactly this reason.
If you are sitting on a long tail you cannot get rid of, or you need someone to build the measurement and the communication plan before you commit to a date, that is the kind of work I take on. Have a look at hosting and platform work or just get in touch. Engagements are quoted as a fixed fee, hourly or on retainer, depending on what the job needs.