PHP in the wild: what each version costs Dutch SMEs to leave

A wholesaler in Apeldoorn forwards us their hosting panel in March. PHP 5.6.40. The site runs. Orders come in. Nothing is on fire. The Marktplaats ad for a developer who can read the codebase has been live for nine months. Twenty applicants. Zero hires.

This is the modal Dutch SME PHP story in 2026. The code works. The version is dead. The replacement budget is a quote nobody has approved. We sit down with five or six of these companies a month, and the conversation always starts the same way: how bad is it, really, and what is it going to cost?

Here is what each PHP version we still see in the wild actually costs to leave. Numbers from our own migration logs, not benchmarks from a vendor blog.

PHP 5.6 and 7.0

The boneyard. Both went end-of-life in January 2019. Seven and a half years ago. If you are running either one in 2026, your hoster is either charging you a security premium (TransIP, Hostnet, Versio all offer this dance) or you are on a self-managed VPS that nobody has touched since the last sysadmin left.

What runs on 5.6 in the Netherlands, in our caseload: WordPress sites stuck on a plugin that the original developer modified by hand, Joomla 3.x e-commerce builds, custom invoicing tools written between 2010 and 2014, and a surprising number of internal Drupal 7 intranets. Drupal 7 itself reached extended end-of-life on January 5, 2025, which removed the last official lifeline for that stack.

Cost to leave: highest of any version. Not because PHP 5.6 to 8.3 is a hard language jump in isolation. It is because the things that pinned you on 5.6 are usually a custom-modified CMS, a payment integration that still calls mysql_* functions, and a templating system that predates Composer. Budget 80 to 200 hours for a small site. More for anything with a checkout, a multi-currency module, or a homegrown BTW calculation.

PHP 7.2 and 7.3

Less common than 5.6 but more dangerous, because the owner thinks they are safe. They are not. Both are years past security support. The MySQL driver works, the syntax looks modern, the WordPress admin loads. You can run a 2026 WooCommerce installation on PHP 7.2 if you tell WP to ignore the warning, and people do.

What you lose by staying: typed properties, arrow functions, null coalescing assignment, FFI, and every security patch since November 2020. What you gain by upgrading to 8.3: somewhere between 15 and 25 percent fewer wall-clock seconds on a typical WordPress request, mostly from the JIT and opcache improvements stacked since 7.4.

Cost to leave: 20 to 60 hours for a typical content site. WooCommerce, Magento 1, and any custom checkout add another 40 to 80 on top.

PHP 7.4

The comfortable lie. PHP 7.4 reached end-of-life in November 2022, but it is the version we see most often on Dutch shared hosting, because it is the last release before the 8.x breaking-change wall. The hoster offers it. The plugins all work. The developer who built the site five years ago tested against it.

The trap: 7.4 to 8.0 is the single biggest code-touching jump in PHP's history. Warnings become errors. {} string indexing is gone. Resource types are objects now. each() is gone. Reflection signatures changed. Every internal function that used to silently accept null now throws.

A typical Symfony 4 or Laravel 6 codebase, run through Rector with the right rule sets, comes out the other side in 8 to 24 hours of real engineering work, plus another full day of test-running and manual patches for the things automation cannot catch (custom __call magic, runtime-generated method signatures, anything that used create_function).

PHP 8.0

The half-migration. Someone, usually a previous agency, bumped the runtime from 7.4 to 8.0 in 2022 or 2023, fixed enough warnings to make the homepage load, and called the job done. Then they left. PHP 8.0 itself went end-of-life in November 2023.

The risk profile here is specific. The site is on a modern runtime, so it does not flag as obviously legacy in any audit tool, but it has been off security support for two and a half years. Composer dependencies have been frozen since the upgrade, because nothing released after 2023 supports 8.0 cleanly.

Cost to leave to 8.3: 4 to 16 hours, mostly Composer thrash. The language jump is small. The dependency-resolution headaches are not.

PHP 8.1

The version that just fell off the cliff. PHP 8.1 reached end-of-life on December 31, 2025. Five months ago, as of this post. If your hoster has not nudged you yet, they will.

8.1 to 8.2 is the dynamic-properties deprecation, which is the one to know about. In 8.2, writing to an undeclared property triggers a deprecation notice. In 9.0, it will throw. The fix is mechanical, but you have to find every site.

// PHP 8.1: works silently
class OptionsBag {
    public function __construct(array $config) {
        $this->options = $config; // undeclared property
    }
}

// PHP 8.2: deprecation notice on every request
// PHP 9.0: throws Error

// Fix A: declare the property
class OptionsBag {
    public array $options;
    public function __construct(array $config) {
        $this->options = $config;
    }
}

// Fix B: opt in to dynamic properties
#[\AllowDynamicProperties]
class OptionsBag {
    public function __construct(array $config) {
        $this->options = $config;
    }
}

Cost to leave 8.1: 4 to 12 hours for most sites. Higher if you discover that a critical plugin has not been maintained since 2022 and the author has gone quiet on the support forum.

PHP 8.2

Security-only support runs until the end of 2026. About six months from now. This is where we land most clients who started a migration in 2024 or 2025. It is a fine place to be for the rest of this year, and the jump to 8.3 from here is small: typed class constants, the #[\Override] attribute, json_validate(), a few targeted deprecations.

Cost to leave to 8.3 or 8.4: 2 to 6 hours, almost all of it in dependency updates rather than code.

PHP 8.3 and 8.4

The green. 8.3 holds security support through the end of 2027. 8.4 (released November 2024) is supported through the end of 2028 and adds property hooks and asymmetric visibility, which are the first language features in a long time that make legacy refactors meaningfully easier to write. If you are starting a new project in 2026, start on 8.4. If you have a healthy 8.3 codebase, do not rush the jump.

The official PHP supported-versions table is the canonical source for every date in this post. Print it. Stick it next to your monitor.

The math nobody runs

Here is the calculation we walk every client through. It is not subtle, but nobody runs it until we sit them down.

Take your annual hosting bill, including any security-premium surcharge for the unsupported runtime. Add the hours your team spends each year working around the legacy stack (the deploy that takes 40 minutes, the staging environment that does not exist, the plugin you cannot update, the developer-search ad on Marktplaats). Multiply by your loaded hourly cost. Add the expected cost of one security incident on an unpatched runtime, discounted by the probability you assign to it in any given year.

For most of the SMEs we audit, that number lands somewhere between €8,000 and €25,000 a year. The migration is usually a one-time €15,000 to €40,000. The payback is rarely longer than two years, and that is before you count the features your team can actually ship once the codebase is on a supported runtime again.

Old PHP runtimes are exactly what automated scanners find first. The constant background hum of bots probing /wp-login.php, /xmlrpc.php, and known plugin paths on every IPv4 address does not need an academic citation. The longer your runtime sits past EOL, the larger the gap between what your server knows about and what someone else's scanner already does.

What to do in the next hour

SSH into your production host and run php -v. Write the version down. Open the PHP supported-versions table in another tab. If your version is in the red zone, you do not need a migration plan today. You need a single calendar entry, with a date, for when you will get the quote.

When we last migrated a Drupal 7 wholesale catalogue off PHP 5.6, the thing that ate the budget was not the language jump. It was a single custom module that handled BTW calculations for a discontinued tax regime, written by a developer who left in 2017. We rebuilt it from the database schema up. That kind of archaeology is the actual work in a legacy migration, and it is why the quote always comes in higher than the version-bump suggests.