Before a PHP upgrade, follow the work that pays the bills

The homepage is an agreeable deployment witness: it often smiles while the overnight invoice job quietly packs its bags. A useful upgrade rehearsal invites the less photogenic parts of the application into the room.

A PHP upgrade can produce a perfectly healthy homepage while quietly breaking the task that makes the business money. The error may emerge days later, when an invoice fails to generate, an overnight export disappears, or a customer receives two confirmations for one order.

That is why the first useful question about a runtime upgrade is operational: which business workflows must still behave exactly as intended when the change is complete?

PHP upgrades deserve attention. Under PHP's published support schedule, PHP 8.2 reaches the end of security support on December 31, 2026. PHP 8.3 is already in its security-fixes-only period, while PHP 8.4 and 8.5 remain in active support. Those dates create a reason to plan carefully; they do not establish which version any particular application is running. [1]

Begin with the work people would notice

Imagine a hypothetical wholesale ordering portal. A dealer submits an order, pricing rules are applied, inventory is reserved, a payment is authorized, a confirmation is sent, and an accounting export is generated overnight.

The public page might load after a PHP upgrade while the accounting export fails because of a library or runtime behavior change. The order screen still looks fine. Finance notices when the numbers fail to arrive.

A useful regression plan begins with five to eight important workflows chosen alongside the people who own their outcomes. For each, write down the trigger, the expected decision, the database change, any outgoing message or file, and the person who would recognize a failure. Include the administrative and scheduled tasks that customers never see.

Capture the old behavior before replacing it

When an inherited system lacks reliable tests, record its current behavior using controlled, synthetic fixtures. These are sometimes called characterization tests: they establish what the application actually does today, including important quirks that still need a business decision before changing.

For a sample order, record its input, expected totals, resulting status, external side effects, and exported representation. Use test gateways and non-production destinations. Do not copy customer information into an unsecured testing environment simply to make a rehearsal realistic.

Then run the same fixtures under the candidate PHP runtime. Compare the outputs that matter: order status, calculated amount, queued jobs, generated documents, outbound notifications, and error events. An HTTP 200 response is a thin substitute for this comparison.

Some changes in the old behavior may be desirable. Mark them explicitly and get an owner to approve the new rule rather than accidentally treating a changed business decision as a passing regression.

Check the runtime and its dependencies

The compatibility investigation should include PHP's official migration guidance, installed extensions, Composer dependencies, and the code paths that load only during particular operations. PHP's migration guides call out backward-incompatible and deprecated behavior to test before production switching. [2] [3]

In a Composer-managed application, composer validate --strict can check project metadata and lock-file consistency; composer check-platform-reqs --no-dev checks whether the actual runtime and extensions satisfy installed production package requirements. Run the latter in the candidate environment with the intended dependencies installed. Passing either command says nothing about whether a monthly billing job produces the correct report. [3]

Review scheduled command-line jobs separately. A web request and a cron task can run with different PHP binaries, configuration, extensions, permissions, and working directories. The forgotten export script is often more consequential than the page used for the deployment smoke test.

Test failures as carefully as successes

A business process has awkward middle states. Suppose an order is saved, but the response times out before the customer sees confirmation. A retry must follow the application's declared rules for duplicate processing. It must not accidentally create a second charge or second fulfillment request.

Rehearse the partial-failure path in a sandbox. Check authorization and session boundaries, rejected input, external-service timeouts, job retries, and whether the application records enough correlation information to reconstruct the result. Use synthetic identities and transactions only.

This also helps separate two categories of problems: a PHP compatibility defect and a business workflow that was already fragile. Both deserve attention, but they have different root causes and remedies.

Deploy with an evidence sheet and a recovery plan

Before traffic moves, the release should have a named build, a tested deployment procedure, and a rollback decision. Record both the old and candidate PHP versions, extension inventory, dependency-lock identity, the fixtures used, and the observed workflow results.

After deployment, verify selected live paths using safe, authorized checks and monitor relevant application and operational signals. Plan for the possibility that data or schema changes cannot be reversed merely by restoring yesterday's application files. Recovery deserves the same attention as the upgrade.

A small scorecard is enough to make the review actionable: workflow, expected result, observed result, evidence, owner, and pass/fail decision.

The goal is to enter an upgrade knowing which decisions, records, messages, and scheduled jobs must remain correct—and to leave with proof that they did.