PHP website maintenance: patch, upgrade or migrate?

A security update should lead to a verified fix and a clear owner for the next one. It can also expose a broader business problem: a website that is expensive to change, difficult to keep supported, or increasingly awkward for the people publishing on it.

Our recommendation is to commission the immediate remediation separately from the longer-term platform decision. Keep a PHP website when it meets your needs and can be maintained properly. Invest in an upgrade, a different support arrangement or a migration when the evidence supports that additional work.

The October 2026 PHP2Shell disclosure makes the distinction urgent. That news article contains the dated vulnerability details and fixed versions. This guide is about buying the engineering work that follows, whether your site uses WordPress, Drupal, another PHP CMS or a custom application.

Choose the work that matches the problem

What you have established	A sensible scope	What you should receive
The site is supported, meets business needs and can take the fix	A bounded patch and verification job	A record of the fix deployed to the running service, important journeys checked, and any unresolved exposure identified
The site is a good fit, but updates and improvements lack an owner	A takeover and ongoing maintenance agreement	An agreed starting condition, named responsibilities, update and escalation procedures, and a prioritised improvement backlog
The CMS or PHP version is unsupported, or dependencies block updates	A compatibility assessment and in-place upgrade	A dependency inventory, supported target, necessary code changes, deployment plan and acceptance tests
Keeping the platform would preserve costly publishing or integration constraints	A comparison of upgrade and migration	A requirements-based recommendation, costs for both routes, content and URL preservation, and a staged delivery plan

These scopes can run alongside one another. Maintenance keeps the current site supported during a planned migration. Suspected compromise adds a separate incident-response track; a rebuild proposal should never defer containment.

Make a patch job verifiable

Avoid buying a vague promise to “secure the website”. Agree which systems and advisory the work covers, who has authority to deploy, and how completion will be demonstrated.

Our proposed acceptance criteria for an application engineering engagement are:

• The target is explicit. Domains, environments, hosting accounts, runtime/package versions and application dependencies are recorded. Include old services that remain publicly reachable.
• The change reaches production. The delivery record identifies the fixed package or image and the serving instances. A successful build or an installed package on one machine is not sufficient evidence for a multi-instance service.
• Important journeys work. Choose tests around the business: an editor publishes a page, a customer submits an enquiry, a property reaches the search index, or an integration completes its expected transaction. Select the checks before work starts and record their results.
• Failure has an agreed response. State how to recover if the release breaks the service. A rollback that restores a known vulnerable runtime also restores exposure, so containment must be part of that decision.
• The handover names what remains. Separate patch completion, functional verification and compromise assessment. Record limitations rather than signing off the whole estate as secure.

The UK NCSC’s PHP guidance recommends identifying installations, updating them and considering whether earlier exposure could have enabled a backdoor. That last question needs security expertise and evidence beyond a passing website test. If compromise is suspected, coordinate changes with a qualified incident responder so that investigation evidence is preserved while exposure is contained.

Who owns each part?

Managed hosting can remove some operational work from your team. The contract still needs to say where that responsibility ends. The following is a proposed allocation to agree with the suppliers involved, rather than an assumption about what your current plan includes.

Owner	Responsibility to agree	Evidence to request
Hosting or platform provider	Runtime and operating-system fixes within its contracted scope; treatment of every serving instance	Applicable vendor advisory, deployed package/image identity, change time and confirmation of worker replacement where required
Website engineering partner	Application and extension compatibility; release coordination; publishing, form and integration checks	Code changes, release record, agreed test results and remaining exceptions
Qualified security responder	Investigation, containment advice and assessment of suspected compromise	Investigation scope, findings, limitations and recovery recommendations
Your business owner	Priority, service-impact decisions and acceptance of unresolved business risks	Named approver, accepted exceptions, owners and follow-up dates

One company may fill several roles, but those responsibilities should still be distinguishable. Your marketing or digital team does not need to become a development team to commission this work. It needs a named partner who can explain the state of the service and carry out the agreed engineering.

Download the blank remediation and handover checklist. It is an editable text file you can send to your host and agency. It contains no pass/fail certification and asks for evidence rather than passwords.

What ongoing PHP website support should include

A monthly allocation of developer hours can fund useful work. It does not, by itself, define who watches advisories, authorises a security release or responds outside normal working hours.

Ask the proposed partner to put these items in writing:

• Starting condition and exclusions: supported versions, inherited defects, third-party dependencies and work that sits with the host or another supplier.
• Update ownership: who monitors relevant advisories, assesses applicability and schedules routine updates; who can escalate an urgent one.
• Release access and recovery: who controls the repository, deployment, backups and restore procedure, and what happens if the usual contact is unavailable.
• Response versus resolution: hours of coverage, acknowledgement targets and escalation paths. An acknowledgement deadline is not a promise that every issue will be fixed within that time.
• Continuous improvement: how speed, accessibility, publishing, integrations and enquiry journeys are prioritised, approved and reported alongside maintenance.
• A usable exit: your access to source code, deployment documentation and service accounts, plus a handover process if you change partners.

The working backlog should distinguish an urgent fix from an improvement proposal. That lets the business keep investing in the website without having routine maintenance consume every conversation.

When an in-place upgrade is the better investment

An upgrade is a strong candidate when the editorial setup and integrations work well, the dependencies have supported replacements, and the required compatibility changes are manageable. Keeping the platform can preserve valuable work while removing the obstacle to future updates.

Check the whole support chain. PHP, the CMS, extensions, the database and hosting components can have different end dates. At the time of writing, PHP 8.2’s upstream security support ends on 31 December 2026, according to the PHP support schedule. A security fix today does not extend that date. A vendor may provide its own backports; ask for the contractual scope and duration rather than inferring it from the upstream version string.

Drupal teams can use our upgrade-or-replatform guide for the CMS-specific decision. Scope the compatibility work before agreeing a deadline, including custom modules and integrations that a runtime-only quote might omit.

When migrating away from PHP deserves a business case

A different platform becomes worth evaluating when an upgrade would leave several expensive constraints in place. Examples to investigate include duplicated work across brands, content structures forced into unsuitable plugins, publishing approvals that need repeated customisation, or integrations that are difficult to test and maintain.

Write down the improvements the move must deliver. “Remove PHP” describes a technical change; it does not specify what an editor, customer or operations team gains. Useful requirements might be one controlled publishing process across languages, reusable content across channels, or a CRM integration with a visible retry and failure path.

Payload is our starting recommendation for large, complex content websites where tailored content models, permissions and integrations matter. We can build and maintain that platform for the publishing team. Our Payload development offering describes the work. A bespoke transactional system may need a different application architecture, or may be better retained and improved.

Changing language does not eliminate security maintenance. A replacement has its own runtime, dependencies, permissions, hosting and update obligations. A PHP exposure remains in scope for as long as an old admin panel, API or microsite is still running. Include decommissioning in the project, with explicit retention and rollback arrangements.

For evidence of planned platform delivery, Ingersoll Rand moved its China sites off Oracle Content Manager in five months, with WAYF on Payload. That is a CMS migration case study, not a PHP2Shell remediation claim or a promise of the same timeline. It illustrates the broader work involved in moving a functioning content platform.

Compare proposals on the same basis

Ask for separate estimates for immediate remediation, takeover or upgrade, ongoing support, and any migration. State the assumptions and unknowns for each. A low maintenance fee can exclude the next major upgrade; a rebuild quote can omit content work or the cost of keeping both systems running during transition.

Use the same planning period and requirements for both routes. Our CMS cost-of-ownership guide covers the comparison. For a migration, require a content inventory, URL and redirect plan, integration ownership, editor acceptance, cutover and recovery criteria. The pre-migration checklist covers those inputs before a build begins.

Start with the website you have

WAYF can assess the application work around a PHP update, coordinate deployment with the hosting owner, and scope an upgrade, ongoing engineering or a CMS migration. We agree access, responsibilities and availability before taking on delivery. Specialist incident response and forensics need their own qualified provider; this website is not an emergency-response channel.

For a first conversation, share the site URL, current CMS and PHP version if known, the hosting provider, any advisory or provider response, and what has become difficult to maintain or improve. Do not send passwords or production secrets in an enquiry. We can arrange appropriate access after agreeing the scope.

Discuss the website and the work you need. If your immediate exposure is unresolved, involve your current host or security provider now while the longer-term engineering work is assessed.