Legacy PHP has become impossible for hosts to ignore. Internet-wide research now puts more than 70% of visible WordPress sites on outdated PHP, and the industry has started shipping products in response. One of the most visible is Extended PHP Support on cPanel and WHM, a per-server add-on that delivers security-patched builds of end-of-life PHP versions 5.6 through 8.1, powered by a third-party patch provider.
It is a real product solving a real problem, and if you run cPanel servers you should understand exactly what it does, what it does not, and how it compares to running a full legacy lifecycle program. The two approaches sound similar. They are structurally different, and the differences decide what your fleet looks like in three years.
What Extended PHP Support on cPanel Does
The design goal is continuity. Eligible cPanel servers can purchase the add-on per server, install security-patched builds of EOL PHP versions, and switch sites onto them in WHM. The site’s PHP version does not change: a site on PHP 7.3 stays on PHP 7.3, with the underlying build patched against known runtime vulnerabilities.
That solves a genuine dilemma. Forcing version upgrades breaks sites and floods support queues; leaving dead runtimes unpatched is exposure. Patched builds are a legitimate middle state, and cPanel’s own guidance is candid that the product should be treated as a bridge while modernization is planned.
The honest question for a host is what the product provides toward that modernization. The answer is: that part is left to you.
What a Legacy PHP Fleet Program Does
WP Maintain starts from the same 70% and builds in the opposite direction: toward the exit. Every legacy site in the fleet is identified by the PHP Version Monitor, audited against the target PHP version, and sorted into a lane before anyone touches production. The host sees the whole fleet by lane, with projected hours, before a single upgrade is scheduled.
Upgrade is the remediation itself: audit the site, fix the incompatible plugin and theme code, prove the result on staging, migrate with rollback standing by. PHP Upgrades is the work that actually ends a site’s legacy status, and it is the work no patching product performs. For hosting partners under a volume agreement, the upgrade is included with WP Care and WP Care+ on every enrolled legacy site: minor fixes on WP Care, code patches on WP Care+.
Rebuild takes the sites worth more than a patch onto a modern WordPress stack through WP Rebuilds. Sites that never change can be converted to Managed Static instead, where WordPress stays the CMS and no PHP runs on the public site. We recommend that case by case from the audit rather than as a lane a host has to choose.
While a site waits its turn, it is not unprotected. It sits on the WP Care plan the rest of the fleet is on, with malware scanning, safe updates, backups and monitoring; WP Care+ offers virtual patching and malware removal at the application layer, which is where the overwhelming majority of WordPress compromises enter. Protection is part of the plan, not a product bought to stay old, and nothing changes on the bill the day the site graduates.
Convert is what makes the economics work for a host that already sells extended PHP. The fleet is enrolled, the sites that can move are upgraded, and the billing SKU changes from extended PHP to WP Care at the same price. The customer gets a current, maintained, monitored site. The host keeps the revenue. Whatever the host pays a vendor to patch old PHP is pennies per site and never ends; the line that matters is the $5 to $25 a month it bills for it, and this is what turns that line into something the customer can see. There is no new billing motion, no product launch, and no customer to convince.
The program’s success metric is the opposite of a patching subscription’s. Legacy PHP Sites, Upgraded, Rebuild Candidates, Remaining Opportunity: one funnel per PHP version, reviewed every quarter, shrinking until a version can be retired outright and the cost of supporting it reaches zero.
The Comparison, Side by Side
| Extended PHP Support on cPanel | WP Maintain Legacy PHP Fleet Program | |
|---|---|---|
| What it is | Security-patched builds of EOL PHP 5.6 to 8.1 | A lifecycle program: audit, protect while waiting, upgrade or rebuild, convert the billing |
| Layer covered | PHP runtime | Application layer (plugins, themes, site code) plus the migration itself |
| What changes for the site | Nothing; same version, patched build | The site exits legacy: upgraded in place or rebuilt |
| Who pays | The host, per server, covering all sites on it | The customer’s existing subscription, renamed from extended PHP to WP Care at the same price |
| Billing over time | Renews as long as legacy sites exist | The same recurring line continues as WP Care after the upgrade; upgrades included for enrolled fleets, rebuilds one-time |
| Migration work included | No; planning and execution are the host’s responsibility | Yes; audit, code fixes, staging, migration, rollback |
| Path for never-upgrade sites | Indefinite patched legacy | Rebuild, or Managed Static where nothing needs to run on PHP |
| Fleet trajectory | Legacy share preserved, patched | Legacy share shrinks toward zero, version by version |
| Revenue model for the host | A per-server license the host pays; retail packaging left to the host to build | Existing extended PHP revenue kept as WP Care, plus rebuild and Pro tier revenue |
| Measurement | Servers licensed | Sites remaining on each legacy version, reviewed quarterly |
| Scope | cPanel and WHM servers | Any WordPress hosting environment |
Where Extended PHP Support on cPanel Makes Sense
Fairness matters here. If you run cPanel servers with runtime-level exposure you cannot tolerate for even a transition period, patched builds are a rational immediate control, and the per-server pricing is simple to reason about. It is also the only one of the two that changes the PHP binaries themselves; WP Maintain deliberately does not manufacture runtime patches, and says so plainly.
The two can even stack. A cPanel host can run patched builds at the runtime layer while WP Maintain runs the program above it: identifying the fleet, shielding the application layer where WordPress attacks actually land, migrating the sites that can move, rebuilding the ones that cannot, and converting the extended PHP line the host already bills into WP Care. In that combination, the patched builds become what cPanel’s own guidance says they should be: a bridge someone is actually walking across.
The Question That Separates Them
Strip everything else away and one structural difference remains. A patching subscription is priced and renewed on the existence of legacy; its natural end state is a fleet that stays old, safely. A lifecycle program is priced on movement; its natural end state is a fleet with nothing left to enroll.
So the question for any host evaluating the two is not which product is better built. Both do what they claim. The question is which trajectory you are buying: a legacy estate that is preserved, or one that is retired. Three years from now, one fleet is patched and unchanged. The other is smaller, faster and supported, with the savings and the same recurring revenue to show for it.
That is the trajectory the Legacy PHP Fleet Program sells. Send us your legacy PHP list and we will audit a sample free, and tell you what share of it converts.
