PHP EOL checklist

Unsupported PHP is not only a version problem. It is a system problem: framework compatibility, extensions, hosting images, Composer packages, cron jobs, and old assumptions in the code.

Last checked against official lifecycle docs: May 3, 2026. Official sources: PHP supported versions and PHP unsupported branches.

Use this checklist before planning a PHP upgrade or quoting one for a client. For the broader playbook this checklist sits inside, see legacy PHP modernization.

Current PHP lifecycle snapshot

PHP branch	Status on May 3, 2026	Security support ends	Planning note
8.1	End of life	December 31, 2025	Treat as urgent if it serves production traffic.
8.2	Security fixes only	December 31, 2026	Accept as a temporary bridge, not as a long-term target.
8.3	Security fixes only	December 31, 2027	Often the conservative upgrade target for legacy apps.
8.4	Active support	December 31, 2028	Better runway, but check package and framework support first.
8.5	Active support	December 31, 2029	Current, but too new for many inherited legacy stacks.

1. Identify the real runtime

Confirm the version used by web requests, CLI jobs, queue workers, and cron. These are often not the same on older servers.

• php -v
• PHP-FPM pool version
• Web server configuration
• Cron and queue command paths
• Docker image or host OS package source

2. Inventory framework and package constraints

Before changing PHP, check whether the framework can run there.

• Laravel, Symfony, CodeIgniter, WordPress, or custom framework version
• composer.json PHP constraints
• Locked package versions
• Abandoned Composer packages
• Required PHP extensions

3. Check hosting and rollback

The upgrade path should not start directly on production.

• Is there a staging environment?
• Can staging run the target PHP version?
• Is rollback a host switch, package downgrade, or backup restore?
• Has rollback been tested recently?

4. Smoke test business-critical flows

Do not aim for perfect coverage first. Aim for trusted checks around the flows that make or lose money.

• Login
• Checkout or payment
• Lead form
• Admin save actions
• File uploads
• Scheduled jobs
• Email delivery

5. Separate urgent risk from cleanup

An EOL upgrade often exposes years of unrelated cleanup. Resist doing it all at once. The first goal is a maintainable baseline. Refactors, UI work, and architecture improvements can follow once the runtime is safe. If the risk register feels too big to act on, our audit is the structured way to turn it into a sequenced plan.

Decision tree: what should happen next?

Use this as the first pass before estimating:

1. Is production on PHP 8.1 or older? Start an upgrade plan now. Do not wait for the next feature cycle.
2. Is production on PHP 8.2? Decide whether PHP 8.3 is a safe bridge or PHP 8.4 is realistic.
3. Does Composer block the target version? Quote dependency/framework work before server work.
4. Does staging match production? If not, staging parity is the first task.
5. Can rollback be executed without a full server restore? If not, make rollback safer before the version switch.

The useful output

A good PHP EOL plan should end with:

• Current and target version
• Blocking dependencies
• Required code changes
• Staging test plan
• Rollback plan
• Estimated effort by phase

That is enough to turn “we need to upgrade PHP” into work the team can actually sequence.