Every host with a WordPress fleet of any age has a long tail of sites running PHP versions that stopped receiving security fixes years ago, often with WordPress cores and plugins to match. Nobody chose this; it accumulates. A legacy PHP fleet program is the structured way to work that tail down without a wave of broken sites and angry tickets. Here is what one looks like.
Why the tail is a problem
Old PHP is a security liability, a performance drag, and increasingly an operational one. The practical consequences for a host:
- Security. Unsupported PHP versions receive no fixes. Combined with outdated WordPress cores and plugins, these sites are where fleet-wide malware incidents start, and cleanup costs land on your support team.
- Infrastructure drag. Keeping old PHP builds available means maintaining old server images, old library versions, and exceptions in your automation. Each exception is a place where an upgrade or a migration can fail.
- Performance and cost. Modern PHP is substantially faster per request. Sites on old versions consume more resources for the same traffic, which is margin you are giving away.
- Compliance and partners. Payment providers, security vendors, and enterprise customers increasingly ask what minimum versions you enforce.
- Customer experience. The site that breaks when a plugin update assumes a newer PHP version is your ticket, not the plugin author’s.
Program design
A fleet program has five phases. Run them in order; skipping inventory is how hosts turn a controlled migration into an incident.
1. Inventory
Build a per-site record: PHP version in use (not just available), WordPress core version, active theme and plugins with versions, last admin login, traffic tier, plan tier, and whether the site has a care plan. Fleet platforms such as WP Maintain collect this across thousands of sites; otherwise, script it from your panel’s API and WP-CLI.
2. Risk ranking
Score each site on exposure (how old the PHP and core are, known vulnerable plugins), value (traffic, plan, revenue), and fragility (abandoned plugins, custom code, page builders known to break on upgrade). The matrix that falls out:
| Low fragility | High fragility | |
|---|---|---|
| High exposure | Upgrade first, in bulk | Upgrade with testing and a human on standby |
| Low exposure | Upgrade in the next scheduled wave | Defer, but set a deadline and communicate it |
Abandoned sites (no login in a year, negligible traffic) get their own track: notify, wait, then suspend or archive rather than migrate.
3. Compatibility testing
For each wave, clone a representative sample to staging on the target PHP version and run the site: front end, admin, checkout or forms, and any cron jobs. Automate what you can (visual regression on key pages, PHP compatibility scans on themes and plugins) and have a person check the rest. Sites that fail go to a fix queue, which is where white-label fulfillment through Pro Services earns its keep: a defined “make this site compatible with the target PHP version” service with a fixed scope and turnaround.
4. Migration waves
Upgrade in waves sized to what your support team can absorb if a few percent break. Order the waves by the risk matrix: high exposure and low fragility first. For each wave:
- Notify affected customers with the date, what changes, and what to do if something looks wrong.
- Take a backup you have tested restoring.
- Switch the PHP version with a rollback path that works in minutes.
- Run automated checks immediately after; a human reviews the failures.
- Confirm with the customer, or at least tell them it is done.
5. Enforcement and prevention
Set a minimum supported PHP version, publish it, and schedule its increase annually. New sites default to current. Sites that fall behind trigger an automated notice and a care plan offer, because the cheapest fleet program is the one you never need to run again.
Customer communication
This is where programs fail. The usual mistake is a single technical email that reads like a threat. A better sequence:
- Announcement, 60 days out. Plain language: why it is happening (security, speed), when, and that most sites will not notice. Offer a free compatibility check.
- Reminder, 30 days out. Specific to the site: “Your site is on PHP X; we will move it to PHP Y on this date. Here is what we checked.” For fragile sites, offer the fix service or a care plan that includes the work.
- Day-of notice. Short. Done, or scheduled for tonight, and how to reach a person.
- Follow-up, one week later. Anything odd? Here is the rollback option and here is the support channel.
Three rules: never surprise a customer with a version change, always name the benefit before the obligation, and route every reply to a person who can act, not a queue.
Staffing and tooling
A fleet program is mostly coordination. You need an owner, a fleet platform that can inventory, patch, and report, a staging capability, and a fulfillment path for the sites that need code work. For most hosts that is a small internal team plus a partner. Seahawk has maintained thousands of WordPress sites and runs this kind of program for hosts through WP Maintain, with the fix and compatibility work handled white-label.
Measuring it
Track the share of the fleet on supported PHP versions monthly, the break rate per wave, ticket volume in the week after each wave, and the number of sites moved onto a care plan as a result. A good program finishes with a smaller tail, a lower break rate each wave, and a measurable lift in care plan attach, because the customers who went through it have just learned what unmanaged WordPress costs.
Next step
WP Maintain is the fleet platform Seahawk runs for web hosts: inventory, scheduled patching, monitoring, and reporting across every site, with a team for the ones that break. If you are planning a PHP program, start with a fleet inventory on a pilot slice; the data usually changes the plan.