The customer portal has run without complaints for years. Then a critical PHP flaw is announced, the hosting provider calls, and it turns out the portal runs on PHP 7.4, a version that stopped getting updates long ago. "Then we upgrade," someone says. A day later the test environment is full of errors.
You upgrade PHP from 7.4 or 8.1 to 8.4 in five steps: record what is running, choose a target version, let tools scan and rewrite the code, test against current behaviour, and switch over in phases. Most of the work is usually not in PHP itself but in the framework and the packages that depend on it.
Why a PHP upgrade can no longer wait
The PHP project currently maintains four versions. According to the supported versions overview on php.net, PHP 8.2 gets security updates until 31 December 2026, PHP 8.3 until the end of 2027, PHP 8.4 until the end of 2028 and PHP 8.5 until the end of 2029. Everything older, including 7.4, 8.0 and 8.1, gets no fixes from the project at all.
What that means became clear on 21 October. For two critical flaws, updates came out for 8.2 through 8.5. For 7.4, 8.0 and 8.1 there were only minimal source patches for people who compile PHP themselves, and for anything older nothing from the project itself. Our post on the October PHP vulnerability covers what to do right away in a case like that.
You are not alone with an old version. Of the websites that use PHP, 27.0 percent still run PHP 7 and 7.7 percent run PHP 5, according to W3Techs measurements from October 2026. No such figures exist for applications behind a login, such as portals and back-office systems, but the cause is the same: as long as everything works, upgrading sits at the bottom of the list.
What changes between PHP 7 and PHP 8.4
The biggest step is the one from 7.4 to 8.0. That release removed things older code still relies on:
- The functions
each()andcreate_function()no longer exist. Code that calls them stops with a fatal error. - Reading characters from a string with curly braces, such as
$text{0}, no longer works. It has to be$text[0]. 0 == "abc"is nowfalse, where it used to betrue. Validation that relies on such a loose comparison suddenly behaves differently, without any error.- A constant that does not exist now throws an error instead of a warning.
- PDO, the standard way to talk to a database, now throws an exception on a database error by default instead of quietly returning
false.
After 8.0 the changes are more gradual. PHP 8.1 deprecates passing null to built-in functions that do not expect it, 8.2 deprecates properties you add to an object on the fly without declaring them, and 8.4 deprecates parameters that are implicitly allowed to be null. Deprecations give a notice now and become errors in a later version. If you are coming from 8.1, the heaviest work is behind you.
The framework almost always has to move too. An old version of Laravel, Symfony or a WordPress plugin often does not run on PHP 8, and a framework upgrade has its own list of changes. In practice that is often the largest part of the work.
How to do a PHP upgrade in five steps
- Record what is running.
php -vgives the version,php -mthe installed extensions. Keepcomposer.jsonandcomposer.lock, note the framework version and do not forget cron jobs and command-line scripts: they sometimes run on a different PHP version than the website. - Choose the target version. PHP 8.4 is the safe choice for most applications. If everything already runs on 8.5, you get a year more of updates.
composer why-not php 8.4shows which packages block the move. - Let tools do the first pass. PHPCompatibility, a rule set for PHP_CodeSniffer, flags code that no longer works. PHPStan finds type errors. Rector rewrites many old patterns automatically. Treat every Rector change as normal code: review it and test it.
- Test against current behaviour. Old applications often have few tests. In that case, first write tests that capture what the key processes do today, such as logging in, placing an order or running an export, and only then upgrade.
- Switch over in phases. Put the new version in a test environment with realistic data first, then acceptance, then production. Keep the old server or the old container image ready so you can go back within minutes.
That fourth step is where it usually goes wrong. In legacy modernization we first capture the rules of the old system and then prove with automated tests against the old behaviour that the new system does what the old one did. A PHP upgrade works exactly the same way.
Upgrade or replace?
Not every application is worth an upgrade. If the framework has been unmaintained for years, if nobody knows what large parts of the code do, or if the upgrade means rewriting half of it anyway, the PHP version is the smallest problem. Our post on legacy systems explains how to recognise such a system.
Replacing it does not have to happen in one go. We migrate component by component, so old and new run side by side and every phase can be rolled back. In the meantime the old application can move to a supported PHP version, so it stays secure until the last part has moved over.
How to keep up after the upgrade
A new PHP version comes out every year at the end of November or early December, and each version gets about four years of updates: two years of full support and two years of security fixes only. PHP 8.4 came out in November 2024 and gets updates until the end of 2028. Put that rhythm in your planning and you never have to catch up three versions at once again.
Two habits keep the next upgrade small. Update your Composer packages every month, so your code never falls far behind. And let your test pipeline run on the next PHP version too, so you see what breaks before you have to switch.
Frequently asked questions
Can't I just switch the PHP version on the server?
For an application on 8.2 or 8.3 that often works, after a proper test round. On 7.4 or older it almost always goes wrong, often on pages you don't look at straight away. So put the new version in a test environment first.
Which PHP version should I choose?
PHP 8.4 if your framework and packages support it, PHP 8.5 if everything is ready for it. Don't choose 8.2 anymore: it gets no updates after 31 December 2026.
How long does a PHP upgrade take?
That depends on the size of the code, the number of tests, the age of the framework and the number of packages. A recent application on 8.1 with good tests is a manageable job. An application on 7.4 with an old framework and few tests is a project. The first two steps give you a reliable estimate.
Do I have to go to PHP 8.0 first and then step up?
No, you don't need to put every intermediate version into production. PHPCompatibility and Rector can check directly against 8.4. Do read the migration notes of every version in between, because the changes add up.
Is one of your applications running on PHP 7 or 8.1, and are you unsure how big the step is? Get in touch for a short call about your situation. You will hear back within 24 hours.
