PHP and MySQL
PHP 8.4 upgrade checklist
Test PHP 8.4 compatibility, deprecations, extensions and rollback before changing a production application.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Treat a minor PHP upgrade as a compatibility change: read the migration guide, update dependencies that declare support, test deprecated and backward-incompatible behaviour, verify required extensions, then run the release in staging with production-like configuration.
What this means in plain English
Moving to PHP 8.4 changes the language runtime underneath the application. Some old behaviour is deprecated or changed, and packages may need newer releases. Read the official migration guide and test the exact app rather than assuming every PHP 8 release is interchangeable.
Check all ways PHP runs: the website, command line, scheduled tasks and queue workers. A server can accidentally use PHP 8.4 for web requests while cron still runs an older binary.
What must be tested before PHP 8.4?
| Code | Tests cover changed and deprecated behaviour |
|---|---|
| Dependencies | Composer packages and extensions support 8.4 |
| Operations | FPM, CLI, cron and workers use intended binaries |
A simple example
The staging homepage works on PHP 8.4, but a nightly import fails because its command-line script uses an old library. Testing the scheduled job before launch catches a problem that browser-only testing missed.
What to do, step by step
1. Run composer why-not php 8.4 where applicable.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on code: tests cover changed and deprecated behaviour. Write the result down so you can compare it later.
2. Enable comprehensive error reporting outside production.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Test uploads, mail, database and scheduled jobs.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Keep the old runtime available for rollback.
Finish by checking the result against operations: fpm, cli, cron and workers use intended binaries. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Do not combine the PHP upgrade with a large application rewrite if you can avoid it. Smaller separate changes make failures easier to understand and roll back.
Common mistakes and how to avoid them
Testing only the homepage.
This gives a misleading or unsafe result because it leaves out code. A better approach is to run composer why-not php 8.4 where applicable, then check the result before making the change permanent.
Upgrading PHP-FPM but not cron PHP.
This gives a misleading or unsafe result because it leaves out dependencies. A better approach is to enable comprehensive error reporting outside production, then check the result before making the change permanent.
Suppressing deprecations without reviewing them.
This gives a misleading or unsafe result because it leaves out operations. A better approach is to test uploads, mail, database and scheduled jobs, then check the result before making the change permanent.
Words explained
- PHP
- The programming language that runs the server-side part of many websites and applications.
- PHP-FPM
- A common service that keeps PHP workers ready to handle web requests.
- worker
- A running process that handles one job or request at a time. More workers allow more work at once but also use more memory.
- migration
- A planned change to database structure or stored data when a new application version is released.
Quick checklist
- Run composer why-not php 8.4 where applicable.
- Enable comprehensive error reporting outside production.
- Test uploads, mail, database and scheduled jobs.
- Keep the old runtime available for rollback.
Common questions
What is the simple answer?
Treat a minor PHP upgrade as a compatibility change: read the migration guide, update dependencies that declare support, test deprecated and backward-incompatible behaviour, verify required extensions, then run the release in staging with production-like configuration.
What should I check first?
Start with code: tests cover changed and deprecated behaviour. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Run composer why-not php 8.4 where applicable. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Testing only the homepage. Avoiding that one mistake makes the rest of the comparison much more trustworthy.