PHP 8.1 / 8.2 upgrade risk checklist

PHP 8.1 and 8.2 now sit in the awkward part of the lifecycle conversation. PHP 8.1 is no longer supported. PHP 8.2 still receives security fixes, but active support ended on December 31, 2024 and security support ends on December 31, 2026.

Source facts last checked May 3, 2026: PHP supported versions and PHP unsupported branches.

The practical question is not “can we upgrade PHP?” It is “what else breaks when PHP moves?” On older production systems, the runtime is usually tied to Composer constraints, framework versions, extensions, cron paths, hosting images, and one or two third-party packages that nobody has looked at since the last emergency.

Use this checklist before quoting a PHP 8.1 to 8.3/8.4 upgrade, a PHP 8.2 to 8.4 upgrade, or a broader legacy PHP modernization project.

1. Identify every PHP runtime

Start by proving which PHP binary is actually used in each path.

• Web requests through PHP-FPM or Apache module
• CLI commands run by deploy scripts
• Cron jobs and scheduled workers
• Queue workers, daemons, and supervisors
• Composer install/update environment
• Any image used by CI or staging

Do not trust the hosting dashboard alone. It is common for a site to serve web traffic on one PHP version while cron runs another. That mismatch hides upgrade failures until the first nightly job runs.

2. Choose the target version deliberately

For most PHP 8.1/8.2 systems in 2026, the conservative targets are PHP 8.3 or PHP 8.4.

PHP 8.3 gives a longer support window than 8.2 and is often the easier compatibility step. PHP 8.4 gives a longer runway, but it may expose more package and framework constraints. The right target depends on the system, not on the newest number available in the host panel.

Avoid landing on PHP 8.2 as the final target unless there is a hard compatibility reason. It buys little time because its security support ends on December 31, 2026.

3. Read Composer before changing the server

Composer usually tells the truth before the server does.

Check:

• composer.json PHP constraint
• composer.lock package versions
• abandoned packages
• packages pinned to old framework majors
• required extensions, especially ext-intl, ext-gd, ext-imagick, ext-redis, ext-soap, and ext-zip
• private packages that may not install cleanly anymore

Run compatibility checks in a branch or staging environment first. The goal is not to make Composer green by force. The goal is to know whether the PHP upgrade is a runtime change, a dependency upgrade, or a framework upgrade disguised as a runtime change.

4. Map framework support before code fixes

Framework support often sets the real ceiling.

Laravel systems should be checked against the Laravel upgrade service path and the official Laravel support table. Symfony, CodeIgniter, and custom frameworks need the same treatment: version, PHP constraint, packages, and extension assumptions.

WordPress and WooCommerce sites need a plugin and theme audit before the runtime changes. WordPress core may run, but a checkout plugin, page builder, custom theme, or old payment gateway can still break. For commerce sites, read the WooCommerce PHP upgrade audit before touching production.

5. Build the smallest useful smoke suite

Do not start with a dream test suite. Start with the flows that would hurt if they broke.

• Login and password reset
• Checkout, payment callback, and receipt email
• Contact, quote, or lead forms
• Admin save actions
• File uploads and image processing
• Search, filtering, and reports
• Cron jobs that send mail, bill customers, or sync external systems

The smoke suite should run before and after the PHP change. It should also run after every package upgrade pulled into the same sequence.

6. Prove rollback before upgrade day

Rollback has to be more specific than “restore backup.”

Write down:

• how the PHP version is changed
• whether the old version remains installed
• how PHP-FPM pools are switched
• how Composer vendor files are rolled back
• whether database migrations are involved
• what cache needs to be cleared
• who can execute the rollback

If rollback requires restoring the whole server, the upgrade plan is probably too risky for a live revenue-critical system. Use staging, a parallel host, or a blue/green cutover where possible.

7. Separate runtime upgrades from modernization

A PHP upgrade is allowed to reveal modernization work. It should not silently become modernization work.

Keep three lists:

• blockers that must be fixed before the runtime moves
• compatibility fixes that can ship with the runtime move
• cleanup and refactoring that should wait

This is where most projects lose control. A deprecated function warning is not the same as a payment failure. A package that cannot install is not the same as a coding-style issue. Treat the upgrade as a risk-reduction sequence, not as a chance to clean every old file.

When to audit first

Start with an audit when the system has no staging environment, no tested rollback, unknown Composer state, old WordPress plugins, unsupported Laravel, or checkout/payment flows that cannot tolerate guesswork.

The audit output should be a version map, dependency map, risk register, smoke-test list, rollback path, and a 30 / 60 / 90-day upgrade sequence. Without those, the PHP version change is doing discovery in production.