If your site earns leads, supports sales, or underpins client delivery, a CMS upgrade is no longer just a CMS task. As of May 24, 2026, the real constraint for many WordPress and Drupal sites is PHP version support, plus everything attached to it: plugins or modules, Composer dependencies, cron jobs, PHP-FPM, server config, and caching at the edge.
That is why seemingly simple upgrades keep turning into delayed release windows. The homepage may look fine, but the risk is usually hiding in scheduled imports, form handlers, WP-CLI or Drush tasks, image processing, or a hosting environment that has quietly fallen behind.
What changed in 2026
Two deadlines matter immediately. PHP 8.1 stopped receiving security support on December 31, 2025. PHP 8.2 remains in security support only until December 31, 2026. If you are still running 8.1, you are already outside the safe window. If you are on 8.2, you are inside a planning window, not a comfort zone.
WordPress has moved upward as well. WordPress currently recommends PHP 8.3 or greater for production hosting, and the current WordPress compatibility guidance now documents WordPress 6.9 and 7.0 as fully supporting PHP 8.5, with WordPress 6.8 and later fully supporting PHP 8.4. Drupal is pushing the same direction from the other side: current Drupal requirements show Drupal 11.3 supports PHP 8.5, and Drupal 12 requires PHP 8.5.
Why this is a stack project, not a version bump
Business owners do not buy PHP upgrades because they care about runtimes. They buy fewer surprises. For operations leads and agency teams, the real cost is not the version switch itself. It is the last-minute discovery that one revenue-critical plugin, one Composer constraint, or one background job is tied to an older environment.
That is why upgrade debt becomes visible in business terms. Forms stop submitting. XML sitemaps fail quietly. Scheduled publishing or imports stall. Admin screens work in staging but timeout in production. A CDN or Cloudflare layer keeps serving a cached error long enough for users and crawlers to notice. The symptom looks like SEO, performance, or conversion trouble, but the root cause sits lower in the stack.
In other words, the risky part is rarely changing php itself. It is everything that assumed the old runtime would stay there forever.
What to target in mid-2026
My practical recommendation here is an inference from the current vendor documentation, not a one-size-fits-all rule.
- WordPress: treat PHP 8.4 as the default planning target for many production sites in mid-2026. It is modern enough to buy time, while staying within the versions WordPress now documents as fully supported for 6.8 and later. Move to PHP 8.5 if the site is already on WordPress 6.9 or 7.0 and your active plugin stack has been tested properly.
- Drupal: if Drupal 12 is anywhere on your roadmap, plan for PHP 8.5 now. Drupal 11.3 already supports it, which makes 2026 the right time to clean up custom code, contributed module compatibility, and server extensions before the major-version jump is urgent.
For both platforms, do not choose the target version in isolation. Pick the PHP target only after you have checked CMS core, plugins or modules, Composer constraints, CLI tools, image libraries, database version, and cache layers.
A short audit that finds the real blockers
Start by collecting facts from the live environment and the staging environment. Do not assume they match. Also run the checks in the same context that serves the site and the CLI tools; mismatched CLI and PHP-FPM versions create false confidence.
php -v
php -m | egrep 'curl|dom|gd|json|mbstring|openssl|pdo|xml'
wp core version
wp plugin list --status=active
wp theme list
wp cron event list
drush status
composer outdated --directFor WordPress, review mu-plugins, deployment scripts, image optimization tooling, and anything that touches the filesystem. For Drupal, confirm required extensions and check custom modules for deprecated code before you schedule the server cutover. If Nginx or Apache config is changing too, validate it explicitly with nginx -t or apachectl -t before reload.
How to run the upgrade without creating new debt
- Inventory the full stack. Capture PHP version, CMS version, active extensions, cron jobs, CLI tooling, database version, cache layers, and hosting constraints.
- Map compatibility before touching production. Separate hard blockers from nice-to-fix issues. A single payment plugin, form add-on, or custom module can decide the order of work.
- Test the non-obvious paths. Check forms, search, logins, feeds, callbacks, scheduled tasks, redirects, sitemap generation, media handling, and editor workflows, not just the homepage.
- Cut over with rollback in mind. Snapshot what can be restored, keep the old package path or image available if your hosting model allows it, and watch logs immediately after deployment.
- Verify the edge. If Cloudflare or another CDN sits in front, confirm cache rules, bypass behavior for admin and previews, and whether any stale HTML or error responses could hide a failed rollout.
This is the difference between a boring upgrade and an expensive one. A boring upgrade is scoped early, tested on the right environment, and deployed with a checklist. An expensive one starts when marketing needs a launch, the host changes defaults, or a security update forces a rushed move.
Where Greg fits
If you need someone who can translate this into a practical project plan, Greg can help scope the upgrade, identify the blockers, coordinate the rollout, and handle the implementation details across WordPress, Drupal, Linux hosting, and edge caching. That is usually the fastest way to turn a vague "we should upgrade PHP" concern into a staged plan with real dates and a rollback path.
Plan a staged CMS upgrade with Greg.
Need help with this kind of work?
Plan a staged CMS upgrade with Greg Get in touch with Greg.