Upgrading from PHP 7.4 to PHP 8: A Practical Checklist

PHP 7.4 reached end of life in November 2022, and PHP 8.0 and 8.1 are no longer supported either. Yet a lot of business-critical applications and WordPress sites still run on them, usually because nobody wants to be the person who breaks production. The risk of staying is real: no security patches, hosting providers forcing upgrades on their own schedule, and newer libraries and plugins dropping support for old versions.

This is the checklist I follow when upgrading a PHP application or WordPress site. The target is a currently supported release — at the time of writing, PHP 8.4 is a good default for most projects.

1. Get a reproducible environment first

Before touching code, the project needs to run locally on both the old and the new PHP version. Docker makes this cheap: one container on 7.4 mirroring production, one on the target version. If the code is not in Git yet, that is step zero.

2. Scan for incompatibilities automatically

Two tools do most of the discovery work. PHPCompatibility is a PHP_CodeSniffer standard that reports code which will not run on a given version. Use a recent release that knows about the PHP version you are targeting:

composer require --dev squizlabs/php_codesniffer phpcompatibility/php-compatibility
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4 --extensions=php --ignore=vendor/*

For WordPress projects, use the PHPCompatibilityWP ruleset, which knows about the polyfills WordPress core ships. Then Rector can fix many issues automatically, upgrading syntax set by set:

<?php

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpSets(php84: true);

3. The breaking changes that actually bite

Static analysis finds removed functions easily. The changes that cause production incidents are behavioural:

• String to number comparison. In PHP 8, 0 == "foo" is false. Old code that relied on loose comparison in conditions, in_array or switch can silently change behaviour.
• Warnings became errors. Many operations that produced a warning in PHP 7 now throw TypeError or ValueError — for example passing the wrong type to built-in functions like strlen() or count() on a non-countable value.
• Removed functions. create_function(), each() and curly-brace string offsets are gone. Old plugins and libraries are the usual culprits.
• Null passed to built-in functions. Since PHP 8.1, passing null to a non-nullable parameter of an internal function such as trim() or str_replace() is deprecated. It floods logs and will become an error in a future version.
• Dynamic properties. Since PHP 8.2, creating properties that are not declared on a class is deprecated. Legacy code and older WordPress plugins do this a lot.

4. Update dependencies, not just your code

Your own code is often the easy part. Run composer outdated and upgrade libraries to versions that support the target PHP version. On WordPress, check every plugin and the theme: abandoned plugins that were never updated for PHP 8 are the most common blocker. Sometimes the right move is to replace one with a maintained alternative or a small custom plugin.

5. Test on staging with production-like data

• Turn on full error reporting and logging on staging and click through the critical flows: login, checkout, forms, admin screens, scheduled jobs.
• If there are automated tests, run them on both versions. If there are none, write a handful of end-to-end tests for the flows that make money before the upgrade.
• Watch the error log for deprecations too — they are next year's fatal errors.

6. Roll out with a way back

Most hosting control panels let you switch PHP version per site, which makes rollback a one-click operation — confirm that before launch. Switch during low traffic, keep watching logs for a few days, and only then remove compatibility shims.

A typical upgrade takes from a few days to a couple of weeks, depending mostly on how many outdated dependencies are involved. If you would rather hand this off, this is work I do regularly.