Upgrading PHP without breaking your site

Every PHP version gets two years of active support and then a period of security-only fixes. After that it gets nothing. Hosts follow the same calendar, so sooner or later an old version is switched off for you, often with little notice.

Which versions are still supported

Dates change; php.net’s supported versions page is the source to check. If your site runs 8.2 or older, plan the upgrade now.

Check what your platform needs

• Drupal 11 requires PHP 8.3 or newer. Drupal 10 needs at least 8.1.
• WordPress runs on a wide range of versions, but its requirements page recommends a current one, and many plugins drop old versions first.
• Custom PHP has no single rule: it depends on the libraries in composer.json.

To see what you run now, check your hosting control panel, or run php -v on the server. In Drupal, the status report shows it; in WordPress, Tools, then Site Health, then Info.

What usually breaks

Most breakage comes from features removed or deprecated between versions:

• Removed in PHP 8.0: each(), create_function() and several other old functions. Code still calling them stops with a fatal error.
• Stricter types: passing null to many built-in functions is deprecated from 8.1, and a lot of older code does it.
• Dynamic properties on classes are deprecated from 8.2, which fills logs with warnings in older plugins and modules.
• Outdated dependencies: an old library pinned in composer.json may refuse to install on the new version.

A safe upgrade, step by step

1. Take a full backup of files and database, and check that it restores.
2. Scan the code with the PHPCompatibility standard for PHP_CodeSniffer, or with Rector, to list problems before you change anything.
3. Update the platform and its extensions to versions that support the target PHP.
4. Fix custom code flagged by the scan.
5. Switch PHP on a staging copy and test the paths that matter: forms, checkout, logins, imports, scheduled tasks.
6. Watch the error log while you test. Deprecation warnings today are fatal errors in the next version.
7. Switch production, keep the old version available for a quick rollback, and watch the logs for a few days.

Most sites need a small amount of custom code fixed. The hours are in steps 2 and 4, which is why a scan comes before any fixed quote.