By Greg Nowak. Last updated 2026-09-19.
PHP 8.2 reaches end of life on December 31, 2026. From September 19, that gives teams 103 days to find every affected site, clear its compatibility issues, test a suitable replacement runtime, and book the production work.
Changing the PHP version in a hosting control panel may take seconds. Establishing that a live CMS will still work afterwards takes considerably longer. The CMS release is only one part of the picture. Plugins or modules, themes, custom code, Composer packages, PHP extensions, server configuration, scheduled jobs, and deployment tooling all have their own requirements. One compatibility check cannot speak for the whole application.
The official PHP support calendar sets the deadline: PHP 8.2 receives security fixes only until December 31, 2026. PHP 8.4 remains under security support through 2028, and PHP 8.5 through 2029. Every site needs to move beyond 8.2, but the right destination depends on the software it actually runs.
Audit applications, not hosting accounts
Start with one row for each production application. A single server or hosting account may contain several sites, each with a different CMS release, dependency lock, extension set, traffic profile, and level of business risk. Treating the server as one unit hides those differences.
For each site, record the domain, business function, owner, CMS and exact release, current web and command-line PHP versions, enabled extensions, package manager status, deployment method, hosting constraints, and availability of a representative staging environment. Name the person responsible for resolving blockers and the person who owns rollback. Otherwise, a known problem can remain nobody’s immediate job until the deadline is uncomfortably close.
Collect evidence from the environment itself. The PHP version reported by a browser request can differ from the interpreter used by scheduled jobs or command-line deployments. Extensions may also be present in one runtime and missing from another. The audit needs to reflect what executes each workload, not what the hosting dashboard appears to promise.
| Audit gate | What to collect | Question to answer |
|---|---|---|
| Runtime | Web, CLI, and scheduled-task PHP versions; enabled extensions | What is actually running today? |
| CMS core | Exact WordPress or Drupal release and its documented PHP support | Which target runtimes are viable? |
| Application code | Plugins, modules, themes, custom code, and migration warnings | What must be updated, fixed, replaced, or retired? |
| Dependencies | Lock file and Composer platform checks in the target environment | Are the PHP and extension requirements satisfied? |
| Operations | Staging results, monitoring plan, verified backups, and rollback steps | Is the production change ready to approve? |
Pick the target site by site
PHP 8.5 offers the longest support runway among the currently supported branches. That does not make it the automatic next step for every application. The PHP 8.5 migration guide lists backward-incompatible changes and deprecated features that need testing before a production move from PHP 8.4 to 8.5.
This distinction matters in a mixed WordPress estate. The WordPress server-environment guidance recommends PHP 8.4 or later for production and advises hosts to plan migrations for sites still running PHP 8.2. It states that PHP 8.4 is fully supported by WordPress 6.7 and later, while PHP 8.5 is fully supported by WordPress 6.9 and later. Core support is a useful first gate, but plugins and themes can introduce further server-level requirements.
Drupal’s PHP requirements matrix makes the release dependency especially clear. It shows PHP 8.4 support across the listed Drupal 10.4–10.6 and 11.1–11.4 releases. PHP 8.5 is supported by Drupal 11.3 and 11.4, but not by the listed Drupal 10 releases or Drupal 11.1 and 11.2. Individual modules may also require particular PHP extensions or configuration.
The sensible route will vary. Some sites can go directly to PHP 8.5. Others need a CMS upgrade first, or should move to PHP 8.4 as a supported intermediate step. A more consistent estate is worth pursuing, but choosing one target before checking each application can buy uniformity at the cost of downtime.
Check dependencies on the runtime you will use
Composer provides a concrete checkpoint for managed dependencies. Its check-platform-reqs documentation explains that the command compares installed package requirements with the actual PHP runtime and extensions. Unlike Composer install or update, it ignores config.platform and inspects the real platform packages.
Run the check inside the proposed staging environment or a production-equivalent runtime, rather than relying on a developer’s laptop. The --lock option checks requirements from the lock file, and --no-dev excludes development-only packages. Save the command, environment, output, and date. That turns a verbal assurance into evidence another person can reproduce.
A clean Composer result is necessary for Composer-managed projects, but it does not prove that the application works. It cannot tell you whether checkout completes, an editor can publish, a form reaches the right integration, or a scheduled task invokes the intended interpreter. Those checks belong in application testing.
Test the journeys that matter to the business
Build staging from the same code, dependency lock, relevant data shape, PHP extensions, and configuration model used in production. Enable appropriate error reporting, then inspect the logs for fatal errors, warnings, and deprecations. Minor-version migrations can include incompatibilities, which is why PHP publishes migration guidance in the first place.
Prioritise tests by consequence. On WordPress, that might cover login, editing, media handling, search, forms, multilingual features, ecommerce, payment callbacks, and scheduled jobs. On Drupal, include administrative workflows, cache rebuilds, queues, contributed modules, search, media processing, and external services. In both cases, test deployment and maintenance commands alongside browser requests.
Give custom plugins, modules, and integrations a named owner. When one fails, somebody needs to decide whether to update, patch, replace, or isolate it—or retire the site. CMS core support for PHP 8.5 does not solve an abandoned extension.
Design the rollback before scheduling the change
Document the current runtime, configuration, package state, database and file backups, cache behaviour, PHP-FPM settings, and OPcache settings. Agree on the signals that will trigger a rollback and who has authority to make the call. The previous runtime also needs to remain available long enough for the change to be reversed safely.
Move sites in controlled batches. Start with a representative application where the business impact is limited, watch its logs and important transactions, and update the runbook with what you learn. Later batches should group sites with similar CMS releases, dependency profiles, and hosting configurations. A shared domain pattern is less useful than a shared technical profile. Revenue-heavy or integration-heavy sites should wait until the process has worked on genuinely comparable applications.
Once compatibility is established, review PHP-FPM capacity and OPcache behaviour under the new runtime. Keep performance tuning separate from the compatibility change unless you have a measured baseline. Changing both at once makes any resulting fault much harder to trace.
What the next 103 days should produce
By the time production changes begin, you should have a verified estate register, a target PHP version for every site, named owners for each blocker, recorded test evidence, and a migration schedule the team can actually execute.
Greg can help build the register, examine dependencies and custom code, reproduce production conditions in staging, and test the administrative and revenue-critical paths that matter. He can also review PHP-FPM and OPcache, prepare rollback instructions, and coordinate migrations in manageable batches. The aim is a controlled move away from PHP 8.2, with enough evidence to make each change confidently.
Related on GrN.dk
- Drupal 10's December 2026 Deadline: Start With the Upgrade Inventory
- WordPress Jobs Are Late Again: Audit WP-Cron Before Adding Plugins
- MCP 2026-07-28 Is an Auth Migration, Not a Version Bump
Need help with this kind of work?
Plan your PHP estate audit Get in touch with Greg.
