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’s a real product solving a real problem, and if you run cPanel servers, you should understand exactly what it does, what it doesn’t, 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. And 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 and placed into one of four lanes.
Protect covers the sites that genuinely can’t migrate yet. PHP Bridge shields them at the application layer: security scanning, malware monitoring, and virtual patching. That matters for WordPress specifically, because the overwhelming majority of WordPress compromises enter through plugins and themes rather than the runtime.
Upgrade is the remediation itself: audit the site against the target PHP version, 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’s the work no patching product performs.
Freeze handles the sites that will never justify a migration. Managed Static converts them to fast static builds with no PHP executing at all; the attack surface is removed rather than defended, while WordPress quietly remains the CMS behind them.
Rebuild takes the sites worth more, onto a modern WordPress stack. WP Rebuilds solves this problem entirely.
The program’s success metric is the opposite of a patching subscription’s: the legacy share of the fleet shrinking, quarter over quarter, with the protection lane designed to empty itself.
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–8.1 | A four-lane lifecycle: protect, upgrade, freeze, rebuild |
| 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, frozen static, or rebuilt |
| Who pays | The host, per server, covering all sites on it | The customer, per site, visible on their bill |
| Billing over time | Renews as long as legacy sites exist | Protection charge ends at graduation; upgrades and rebuilds are 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 | Managed Static: no PHP, nothing left to patch |
| Fleet trajectory | Legacy share preserved, patched | Legacy share shrinks toward zero |
| Revenue model for the host | A per-server license the host pays; any retail packaging is left to the host to build | WP Care, retail add-ons, and project revenue on every lane |
| 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’s 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, freezing the ones that never will, and converting the whole exercise from a host-paid cost line into customer-funded lanes. 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 isn’t which product is better built. Both do what they claim. The question is which trajectory you’re 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 retail revenue to show for it.
That’s the trajectory the Legacy PHP Fleet Program sells.
