PHP 7 to PHP 8: test changed behaviour, not just syntax

Choose an exact target

PHP 8 is a family of releases, not a single compatibility target. Record the current version, intended version, extensions and dependency constraints. Read the incompatibility notes for every release crossed; this guide highlights PHP 8.0 changes and is not a claim that later versions have no additional changes.

• Build a safe baseline with the agreed critical flows.
• Inventory libraries, scheduled commands, uploads and database access.
• Use synthetic data rather than a production dump.

Target behaviour that can silently change

PHP 8.0 changes loose comparison between numbers and non-numeric strings: for example, 0 == 'foo' changes from true to false. Legacy validation and branching logic can therefore behave differently without a syntax error. Test representative valid, empty and invalid inputs using expected business results.

• Check price, identifier and form-validation comparisons.
• Review reliance on undefined variables, array keys or constants.
• Verify both successful and rejected requests.

Check error paths

Some warnings become TypeError or Error, inherited method-signature incompatibilities become fatal, and PDO's default error mode becomes exceptions. The @ operator no longer silences fatal errors. A site that appears fine with one valid input can still fail under an ordinary missing value or failed database operation.

• Keep detailed errors out of the public response.
• Test failed database connections and validation failures safely.
• Do not suppress all errors to claim compatibility.

Acceptance and reversal

Acceptance should name the agreed visitor and administrative flows on the exact target runtime, with baseline comparisons and independent review. A runtime rollback may not reverse schema, stored-data or external-service changes. Set those boundaries before live publication. A successful lint or home-page load alone is not an application upgrade.