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.

Use this checklist before planning a PHP upgrade or quoting one for a client.

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.

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.