When an upgrade needs development work
Changing PHP is not the same as updating every component that uses it. An unsupported plugin or custom integration may block the move even when hosting offers a newer version. We identify that dependency first. A temporary rollback can restore operation after a failed change, but retaining an unsupported runtime is not a long-term security solution.
Upgrade PHP with application acceptance checks
Inventory framework, extensions, Composer dependencies, jobs and custom integrations before selecting a target runtime. A supported runtime still needs compatibility testing against the actual application.
- Record runtime and dependencies.
- Check staging compatibility where available.
- Agree rollback including database implications.
- Test routes, forms, jobs and external calls.
Application tests after a PHP change
Record errors, extensions and unresolved dependencies. Reverting a runtime selector may not reverse database changes. Framework rebuilding, paid licences and code remediation are separate from the runtime change.
| Test | Evidence | Separate work |
|---|---|---|
| Web | Representative routes and logs | Legacy code repair |
| Job | Scheduled task completes | Queue redesign |
| Integration | Approved API/SMTP transaction | SDK replacement |
Example: a missing extension breaks a scheduled job
The homepage works after a version switch but a nightly job fails because an extension is missing. Including that job in acceptance detects the incomplete upgrade. This is an illustrative scenario, not a customer case or a promised result.