Prepare for PHP 9.
Start on 8.x.

Make the noise visible.

Enable all errors and log them in your test and development environments. Keep error display off in production. Exercise web requests, queues, scheduled commands and seldom-used integrations.

error_reporting(E_ALL);
ini_set('log_errors', '1');
ini_set('display_errors', '0');

Update the code you don't own.

Inventory your PHP constraint, extensions and Composer dependencies. Read each package's upgrade guide. Upgrade in small steps, keep the lockfile, and test after every step. Do not edit vendor files to silence a warning.

Let static analysis find the boring bugs.

PHPStan level 0 already checks unknown variables and properties; raise the level as you clear findings. Aim for the highest level you can sustain. Level 6 adds missing type checks; higher levels tighten null and mixed handling. A baseline should stop new debt, not hide every future warning. Psalm is another option; start at a usable error level and tighten it as you add types.

vendor/bin/phpstan analyse app --level=6

Automate syntax fixes, then read the diff.

Use Rector's PHP sets for the version you're targeting. Its prepared PHP sets can select upgrades from your Composer PHP constraint. Run a dry run first; review changed signatures and serialized data carefully. There is no PHP 9 set promised here.

// rector.php, inside RectorConfig::configure()
->withPhpSets()

vendor/bin/rector process app --dry-run

Test on 8.5. Try 8.6 before it ships.

Use PHP 8.5 for stable coverage. Test PHP 8.6 release candidates in an isolated development environment and report regressions upstream. A release candidate is for testing, not a reason to change a working production runtime today.

Keep the log clean.

Check the accepted breaking changes, rerun your tests, and watch deprecation logs after your next regular release. This is continuing maintenance. PHP 9 can acquire more changes before it ships.