Upgrading your PHP version

Running a supported PHP version is a security baseline, not a luxury. PHP offers four years of support per branch: two years of active support with regular fixes, then two years of security-only updates, then end of life with no patches at all. Upgrading is therefore recurring maintenance, and doing it in the open with a compatibility scan beats doing it under pressure when an EOL deadline or a host announcement forces the change.

What is currently supported

Check the official table before relying on memory; the numbers shift as branches age. The important fact is that an out-of-support branch receives no security patches, so any vulnerability disclosed stays open on your site. Supporting versions change, but the recent pattern is:

The exact dates move; confirm them against php.net supported versions before planning a window. Teams on an EOL branch are running with unpatched exposure, and that is the reason to upgrade, separate from any performance gain.

Scan for breakage first

PHP point releases add deprecations and remove old behaviour, and the risk is one function, extension or library call your page uses. Before changing anything:

1. List your dependencies: the CMS version, active plugins and themes, and any custom scripts that call PHP functions directly.
2. Check CMS and plugin support for the target version. A plugin that declares it only supports old PHP is a blocker to resolve, not to ignore.
3. Enable strict error reporting on a staging copy so deprecation and fatal errors surface immediately:

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

1. Run your critical paths: login, a write to the database, image upload, forms, and any admin pages that differ from the public site.

A failed upgrade is rarely a PHP engine fault; it is almost always a single abandoned library or function. Find those on staging before the switch, per the WordPress-specific troubleshooting order when the site runs WordPress.

Stage and cut over

Keep the change reversible the same way as any migration:

1. Back up files and database, and test you can restore. A PHP upgrade must be undone as cleanly as it is applied.
2. Run the new version on a staging copy of the same code and data until every path you depend on passes.
3. Switch the PHP version at the hosting layer (panel selection, .htaccess, or a CLI tool), one environment at a time, staging first then production.
4. Confirm the live site after the flip: site and admin load, errors are gone, and error logs show nothing new from the runtime change.
5. If the live site fatals, switch back to the previous version immediately; a PHP version is a rollback point, not a commitment.

A fatal error from an incompatibility surfaces instantly and is reversible (see the PHP fatal error article). Because a version change can undo itself cleanly, staging is the decisive step: the version you never ran is the version you never trusted.

Keep the window current

Treat PHP support as a repeating cycle. Note the end of life for your current branch and plan the next upgrade several months before it, so you are never the site that must move on a host's deadline. If an extension is stuck on an old dependency, replace it now rather than carrying a blocker to the next upgrade. The host migration checklist describes the surrounding move if you are also changing servers, and the PHP max execution time article covers a runtime limit that surprises people after a version change.