PHP 7: Maintaining and Upgrading Legacy Apps · Upgrading from PHP 7 to PHP 8
Rolling Out PHP 8 in Production
Test, deploy gradually, monitor and keep a rollback path.
Roll out PHP 8 like any risky change: build images for both versions, run the full test suite and a staging soak test, then deploy to a canary (one server or a percentage of traffic) while monitoring error rates, deprecation logs and performance. Keep the PHP 7.4 image ready for rollback until the new version is stable, and remember cron/CLI workers run PHP too.
# Compare error rates during canary (example with logs)
grep -c "PHP Fatal\|TypeError\|ValueError" /var/log/php-fpm/error.log
# Make sure CLI and FPM use the same version
php -v && php-fpm8.3 -v
Common pitfalls
- Upgrading web servers but forgetting cron jobs, queue workers and CLI scripts.
- No baseline metrics to compare against.
- Removing the old runtime image before the new one is proven.
Key points
- Canary with monitoring
- Upgrade CLI, cron and workers too
- Keep a rollback image
Further reading: PHP supported versions
Practice questions
What should you monitor during a PHP 8 canary?
Answer
Error rates (TypeError/ValueError/fatal), deprecation logs, latency and memory usage, and business metrics, compared with servers still on 7.4.
Which parts of a PHP system are often forgotten during upgrades?
Answer
Cron jobs, CLI scripts, queue workers and scheduled tasks that run with a different PHP binary or image than the web servers.
Open in the app to mark lessons complete, take notes and track your progress.