WordPress PHP Upgrade Checklist: Compatibility and Rollback
Choose a supported PHP version that your application can run, then prove the important workflows. PHP is the server runtime used by WordPress. Changing it is a different operation from updating WordPress core or increasing the PHP memory limit.
This checklist helps a site owner coordinate the change with a host and maintainer. It does not recommend a universal version for every plugin combination. Use the memory limit versus server RAM guide if your problem is capacity, or the PHP workers guide for concurrent application work.
Check the current support window
Use PHP’s official supported-version table for lifecycle dates. As checked October 5, 2026, PHP 8.2 is in security-only support through December 31, 2026; PHP 8.3 through December 31, 2027. PHP 8.4 has active support through December 31, 2026 and security support through December 31, 2028. These dates establish upstream support, not compatibility of your installed plugins.
Ask the host which branches it offers for this product and whether its policy adds constraints or support beyond upstream dates. Save the answer with the review date. A short remaining window may justify planning the next upgrade now rather than discovering the deadline during an unrelated incident.
Inventory the application and runtime
Record the live PHP version, WordPress version, active theme, plugins, custom code and important integrations. Ask the maintainer to check vendor requirements and known compatibility issues for the intended target. Include scheduled jobs and command-line tasks where relevant; ask the host whether those tasks use the same runtime as web requests.
WordPress’s PHP-update guidance recommends backups, application updates and compatibility checks before changing the server-level version. Its older example version numbers are not a current lifecycle reference; use PHP’s official table for that decision.
| Question | Why it matters | Record |
|---|---|---|
| What changes with the version switch? | The environment may include extensions or configuration that need review. | Target version, required extensions and settings. |
| Does staging match the intended runtime? | A test on another runtime answers a different question. | Staging configuration and differences. |
| Who verifies custom code? | A host may support the runtime while excluding application repairs. | Named developer and vendor contacts. |
| Can the previous runtime be restored? | Availability and support policies can limit rollback. | Supported procedure and responsible person. |
| What else changes in this release? | Multiple simultaneous changes make failures harder to attribute. | Separate application and runtime change records. |
Test a representative staging copy
Use the staging guide to choose the environment and the isolation checklist before invoking external systems. Establish a working baseline, apply the target runtime using the host’s supported controls and repeat the same acceptance checks.
Include authorized editing, media operations, enquiries, account access and the business-specific transaction. For a store, use the WooCommerce test-order checklist. Review relevant logs with the maintainer rather than assuming that the absence of a visible error means every code path was tested.
Separate compatibility work from the live switch
If a component needs an update or replacement, test that application change as its own step. Use the WordPress update checklist to record versions and results. Review the relevant PHP migration guides with the developer when moving between runtime branches.
Record unresolved notices, failing workflows and the vendor’s response. A successful homepage test does not establish compatibility of a rarely used export or scheduled job. Make the release decision against the tasks the business actually depends on.
Plan rollback and verify production
Confirm a recent backup and the recovery owner before the live switch. Restoring files and a database does not itself select the server’s PHP version. Establish both procedures with the host, and consider current orders or registrations before authorizing a data restore.
Choose a release window with support available, change the intended runtime, repeat the agreed checks and monitor the relevant logs and jobs. Record the final version, result and remaining work. If a workflow fails, preserve the evidence and follow the approved recovery plan instead of repeatedly changing unrelated settings.
Match the runtime to the failing task
For a hypothetical upgrade, the web editor works on the target PHP version while a command-line import still runs under another branch. Record the runtime for each relevant execution path and ask the host how it is selected. Repeat the actual scheduled or command-line task under the intended environment. A passed homepage check does not establish compatibility for every task sharing the website’s files.
Sources and scope
Official PHP and WordPress documentation checked October 5, 2026. The coordination table is HRL’s editorial guidance. This page does not certify a site’s compatibility, promise a speed gain or report a PHP upgrade performed by HRL.