A PHP upgrade is ready when the application completes its important work correctly on the target environment. A successful installation or a working homepage provides only a small part of that evidence. Use this checklist to turn an upgrade proposal into a release that technical and business owners can review.
Check the runtime that actually serves the application
Record the PHP version and extensions used by the web server, command-line scripts and workers. These can differ on the same host. Confirm database drivers, locale settings, file permissions and scheduled-job configuration in staging before testing the application.
Composer's check-platform-reqs command checks installed packages against the actual PHP and extension environment. Its audit command reports package security advisories and other configured package-policy findings. Use both as evidence in the upgrade review, while recognising that neither proves the application is free of vulnerabilities.
Review dependency changes before deployment
- Validate composer.json and the lock file, and review the packages the upgrade changes.
- Investigate security findings and abandoned dependencies with a documented resolution.
- Check extension requirements on the deployment environment, not only a developer laptop.
- Create a repeatable install from the reviewed lock file.
- Keep dependency updates out of the live deployment step unless explicitly planned and tested.
A framework upgrade also has its own migration requirements. Laravel's version-specific upgrade guide is one example of the documentation to consult when that framework is present. An old custom PHP project needs an assessment of its own libraries and conventions; a framework guide is not a universal migration recipe.
Test business outcomes and access boundaries
| Area | Example check | Evidence |
|---|---|---|
| Authentication | Login, recovery and role restrictions | Expected access and denied access both verified |
| Transactions | Create, adjust and refund a representative record | Totals and history match expected results |
| Files | Upload, download and export supported formats | Correct content and permissions |
| Background work | Run reminders, reports and queue jobs | Successful completion without duplicate actions |
| Integration | Process success, failure and repeated callbacks | Correct state and traceable errors |
Use the application's own critical paths to expand this table. For a school system that could include fees and results; for a healthcare workforce application it could include a shift crossing midnight. Include malformed or missing inputs because stricter runtime behaviour may expose assumptions that ordinary demo data never reaches.
Rehearse database changes with reconciliation
Run migrations on a representative copy of the database and compare counts, balances and key relationships. Record the time taken and the expected impact on writes. If columns or stored formats change, verify whether the previous code can still operate during rollback.
Backups must be restorable, and their age must be understood. Rehearse recovery in an isolated environment. If users will create transactions during the release window, document how those transactions are preserved or reconciled after a recovery. A backup alone does not answer that question.
Compare representative workloads
Measure important requests and jobs using comparable data and infrastructure. Include a busy report, a transaction flow and a background task rather than reporting only homepage speed. Review error logs, memory use and database behaviour alongside response times.
Set thresholds that match business needs before running the comparison. If a report becomes faster but returns the wrong rows, the release has failed. Correctness and access control take priority over a favourable performance number.
Make release approval and monitoring explicit
- Approve the evidenceTechnical and business owners review unresolved issues and critical workflow results.
- Prepare the releaseUse the tested artifact, configuration and migration steps with a named release owner.
- Verify productionRun the agreed smoke checks and confirm callbacks, scheduled work and important reports.
- Observe and reconcileWatch errors and outcomes, then compare records through the first representative operating cycle.
Define what triggers rollback and who can make that decision. Keep release notes that explain the target environment, migrations, known limitations and recovery instructions. Give the support team enough information to distinguish a new regression from an existing issue.
Turn the checklist into a Techimpace project scope
Techimpace's enterprise software and cloud services provide a starting point for discussing legacy modernisation, deployment and ongoing support. Bring the current stack, critical workflows and acceptable maintenance window. Ask for a proposal that names the tests, migration responsibilities and post-release monitoring included in the work.
Frequently asked questions
Is a passing Composer audit enough to approve a PHP upgrade?
No. It provides package-level findings. The application also needs compatibility, workflow, access-control, integration and recovery checks.
Should we run composer update on the live server?
Resolve and review dependency changes in a controlled environment first. Deploy the tested dependency set from the lock file so production matches the validated release.
Can a PHP upgrade be released without downtime?
Sometimes, depending on infrastructure and database compatibility. Agree and test the deployment approach; do not assume zero downtime before assessing the application.
