If your application still runs on PHP 7.4, you're not alone — and you're not a bad engineer. Upgrades get postponed because the app works, the team is busy, and nobody wants to be the person who broke checkout. But PHP 7.4 reached end of life in November 2022. Every month since then, any newly discovered vulnerability stays unpatched on your servers.

The good news: this upgrade is far more manageable than it looks if you take it in small steps.

Step 1: Find out what you're dealing with

Before changing anything, get a picture of the codebase:

  • Run PHPCompatibility (a PHP_CodeSniffer standard) against your code to list incompatible calls.
  • Run PHPStan at a low level to catch obvious type problems.
  • Check composer.json for packages that don't support PHP 8. composer why-not php 8.3 is a quick way to see what's blocking you.

Write the results down. That list is your project plan.

Step 2: Fix what changed

The changes that bite most teams:

  • String-to-number comparisons. In PHP 8, 0 == "foo" is false. Code that relied on loose comparison with strings can behave differently.
  • Stricter internal functions. Many functions that used to emit a warning and return null now throw a TypeError — for example, passing null or an array where a string is expected.
  • Removed functions. each(), create_function() and a handful of others are gone.
  • Dynamic properties are deprecated from PHP 8.2. Setting $this->foo on a class that never declared $foo now raises a deprecation notice.

Rector can automate a large share of these fixes. Run it with the PHP 8 rule sets, review the diff carefully, and commit in small pieces so each change is easy to revert.

Step 3: Run both versions side by side

Add PHP 8 to your CI pipeline next to 7.4, not instead of it. Keep both green until you're ready. If you have a staging environment, run it on PHP 8 for a week with real traffic patterns and keep an eye on the error logs — deprecation notices are your early warning system.

Step 4: Switch, but keep a way back

When you deploy, make rollback boring. Containers make this easy: the old image is still there. On traditional servers, install the new PHP version alongside the old one and switch the FPM pool, so going back is a config change, not a reinstall.

Which version?

Don't stop at 8.0 or 8.1 — both are already out of support. Aim for 8.3 or newer so you're not doing this again next year. Check the official supported-versions page on php.net when you plan.

A word on tests

If you have few automated tests, write a small set of "smoke tests" before starting: log in, place an order, submit the contact form. They don't need to be clever. They just need to tell you, quickly, whether the most important paths still work.