PHP 7.4 upgrades to PHP 8.5, without breaking production

Is PHP 7.4 still safe to run?

No. PHP 7.4 received its last security release in November 2022. Every PHP vulnerability found since then is unpatched in 7.4, and the list grows every year. Some Linux distributions kept backporting fixes for longer, but most of those windows have closed or now need paid extended support.

The runtime is only part of it. Laravel, Symfony, WordPress plugins, payment SDKs and most Composer packages dropped PHP 7.4 long ago, so you are almost certainly missing their security fixes too. Cyber Essentials expects supported software, and client security questionnaires increasingly ask which PHP version you run. See our PHP end-of-life dates table for every version.

What breaks between PHP 7.4 and PHP 8.5

PHP 7.4 to 8.0 is the biggest jump in modern PHP. Most problems come from a handful of changes:

• Stricter errors. Many warnings became TypeError or ValueError exceptions. Code that used to log a notice and carry on now stops.
• String-to-number comparisons. 0 == "foo" is now false. Loose comparisons in validation, routing and permission checks can quietly change behaviour.
• Removed functions. each(), create_function(), money_format() and get_magic_quotes_gpc() are gone, along with curly-brace string offsets such as $str{0}.
• Resources became objects. cURL, GD and other extensions now return objects, so is_resource() checks fail silently.
• Passing null to built-in functions such as strlen() or trim() is deprecated from PHP 8.1. It is the most common deprecation we see in older code, and it floods logs.
• Dynamic properties are deprecated from PHP 8.2, and implicitly nullable parameters from 8.4.

Our article on PHP 8.2 end of life covers the smaller changes from 8.2 to 8.5.

How we upgrade PHP 7.4 applications

We go straight to PHP 8.5 rather than stopping at 8.1 or 8.2, which are already at or near end of life. Going straight there doesn't mean doing it in one go:

1. Static analysis against PHP 8.5. PHPStan and PHPCompatibility scan the code with the target version set, so we know where the problems are before changing anything.
2. Characterisation tests on critical paths. Login, checkout, forms, APIs and imports get tests that record what the application does today, so behaviour changes are caught in CI rather than by customers.
3. Rector, version by version. Rector applies the PHP 8.0, 8.1 and later rule sets in small, reviewable commits. A person reviews every change.
4. Dependencies upgraded alongside. Composer packages and the framework move to versions that support PHP 8.5, and abandoned packages are replaced.
5. CI on both versions, then a staged release. The test suite runs on 7.4 and 8.5 until cut-over. Production switches with a documented rollback plan.

You can keep shipping features throughout. There is no long-lived upgrade branch drifting away from main.

What a PHP 7.4 upgrade costs

Start with the fixed-price £350 audit: a Composer compatibility check, Rector dry run and PHPStan baseline against PHP 8.5, and a written plan with an effort estimate. The upgrade itself is a fixed quote, from £2,500, once the audit has sized the work. The audit fee is credited if you go ahead within 30 days.