WordPress PHP upgrade QA checklist for maintenance teams

A PHP version change can alter type handling, deprecated functions, error reporting, extensions, memory behavior, and the way WordPress plugins communicate with external systems. The admin dashboard may load while checkout, forms, search, image processing, scheduled publishing, or a webhook silently fails.

Open a release ticket before touching production. Record the current and target PHP versions, hosting environment, business-critical journeys, expected maintenance window, technical owner, QA owner, rollback decision maker, and the evidence required for approval.

• Confirm the target PHP version is supported by the host, current WordPress core, and every critical plugin vendor.
• List web, worker, cron, CLI, and staging runtimes; they may not share the same PHP setting.
• Define the user journeys and SEO templates that must pass before release.
• Freeze unrelated theme, plugin, content-model, DNS, and caching changes during the upgrade window.

Start with evidence from the live stack, not assumptions from a plugin list. Export active and must-use plugins, theme and child-theme versions, PHP extensions, WordPress constants, object cache, CDN rules, scheduled events, payment methods, form destinations, search integrations, and deployment hooks.

Run automated compatibility tools as a discovery aid, then inspect custom code manually. Static scanners can miss reflection, dynamic hooks, serialized data, vendor libraries, and code that only executes for a specific role, locale, payment method, or scheduled task.

• Search custom themes, plugins, and snippets for deprecated PHP APIs, dynamic properties, loose comparisons, and changed argument behavior.
• Verify required extensions such as mbstring, intl, curl, imagick, zip, and database drivers on the target runtime.
• Classify each dependency as compatible, update required, replace, custom patch, or retire.
• Create a risk register for abandoned plugins and code without an accountable maintainer.

A stale staging site gives false confidence. Refresh it close to the test window, redact sensitive data, preserve representative orders and content shapes, and match production PHP extensions, database version, caching layers, filesystem permissions, and environment variables.

Take a coordinated database and filesystem backup before the rehearsal and again before production. A backup is not a rollback plan until someone restores it, verifies URLs and media, clears caches, and measures the recovery time.

• Block staging from indexing and prevent it from sending real email, payment, CRM, analytics, or webhook traffic.
• Confirm the backup contains uploads, custom code, configuration, database tables, redirects, and deployment metadata.
• Restore the backup to an isolated location and test login, media, permalinks, and one critical transaction.
• Record backup timestamps, storage location, encryption, retention, restore owner, and estimated recovery time.

Update WordPress core, themes, and plugins on staging using a documented sequence. Change one compatibility layer at a time when the stack is high risk, so logs and regression results can identify the change that introduced a failure.

Switch staging to the target PHP version only after prerequisites are ready. Clear opcode, page, object, CDN, and browser caches, restart relevant workers, and verify the web request, cron runner, and command line all report the intended runtime.

• Capture version numbers and checksums before and after every dependency update.
• Do not overwrite custom plugin or parent-theme edits without comparing them against source control.
• Run database migrations once, inspect their output, and confirm repeated deployments will not rerun destructive work.
• Keep debugging output out of rendered pages while sending warnings and fatal errors to a protected log destination.

Test as anonymous visitors, customers or members, editors, administrators, and integration users. Cover the homepage, key landing pages, search, forms, authentication, ecommerce or lead-generation paths, and any template driven by custom fields or custom post types.

Then test the work that happens away from page views: media upload and resizing, scheduled publishing, imports and exports, backups, queue workers, WP-Cron, real server cron, REST endpoints, webhooks, sitemap generation, and command-line maintenance tasks.

• Submit every critical form and verify delivery, CRM creation, autoresponse rules, spam controls, and consent fields.
• Create, edit, preview, schedule, publish, update, and unpublish representative content as an editor.
• Test payment, tax, shipping, coupons, refunds, account email, and stock updates when ecommerce is present.
• Compare PHP and application logs before and after each test for warnings, deprecations, timeouts, and fatal errors.

A runtime upgrade can change rendered HTML through plugin failures, shortcode errors, missing extensions, cache fragmentation, or different image processing. Crawl staging and compare status codes, titles, headings, canonicals, robots directives, hreflang, structured data, internal links, redirects, pagination, and XML sitemaps with the approved baseline.

Measure performance with warm and cold caches. Compare server response time, cache hit rate, slow database queries, memory use, error rate, LCP, CLS, and INP on representative templates. A faster PHP benchmark is not useful if production caching or critical rendering regresses.

• Diff server-rendered HTML for the homepage, service pages, blog posts, archives, product pages, and localized templates.
• Confirm 404, redirect, canonical, noindex, sitemap, and robots.txt behavior survives cache clearing and deployment.
• Validate schema markup and ensure PHP warnings never leak into HTML, JSON-LD, feeds, or API responses.
• Save crawl and performance evidence with the exact staging build and PHP version tested.

Write objective go or no-go gates before the production window. Examples include zero fatal errors, all critical journeys passing, no unexpected crawl differences, acceptable response-time variance, successful cron execution, and a restore test within the agreed recovery target.

Rollback may mean switching the runtime version back, reverting dependency updates, restoring database and files, or all three. Rehearse the steps in staging, time them, and identify changes that are not backward compatible. A database migration can make a simple PHP toggle insufficient.

• Name the person authorized to stop the release and the thresholds that trigger rollback.
• Save exact hosting-panel, CLI, deployment, cache-purge, restore, and health-check steps in the runbook.
• Confirm the previous PHP runtime remains available for the rollback period.
• Prepare customer-support and stakeholder messages for maintenance, degraded service, rollback, and resolution.