PHP in het MKB: wat elke versie kost om achter te laten

Een groothandel in Apeldoorn stuurt ons in maart zijn hostingpaneel door. PHP 5.6.40. De site draait. Bestellingen komen binnen. Niets staat in brand. De Marktplaats-advertentie voor een developer die de codebase kan lezen, staat al negen maanden online. Twintig sollicitanten. Niemand aangenomen.

Dit is het modale PHP-verhaal in het Nederlandse MKB in 2026. De code werkt. De versie is dood. Het budget voor vervanging is een offerte die nog door niemand is goedgekeurd. We zitten elke maand met vijf à zes van deze bedrijven aan tafel, en het gesprek begint altijd hetzelfde: hoe erg is het echt, en wat gaat het kosten?

Hieronder staat per PHP-versie die we nog in de praktijk tegenkomen wat het werkelijk kost om 'm achter je te laten. Cijfers uit onze eigen migratielogs, niet uit een benchmark op een leveranciersblog.

PHP 5.6 en 7.0

Het kerkhof. Beide gingen end-of-life in januari 2019. Zeven en een half jaar geleden. Draai je in 2026 nog een van beide, dan rekent je hoster ofwel een security-toeslag (TransIP, Hostnet en Versio doen dit dansje allemaal), of zit je op een zelfbeheerde VPS die niemand meer heeft aangeraakt sinds de laatste sysadmin vertrok.

Wat er in Nederland nog op 5.6 draait, binnen onze caseload: WordPress-sites die vastzitten op een plugin die de oorspronkelijke developer met de hand heeft aangepast, Joomla 3.x e-commerce-builds, custom factureringstools geschreven tussen 2010 en 2014, en een verrassend aantal interne Drupal 7-intranetten. Drupal 7 zelf bereikte op 5 januari 2025 de extended end-of-life, waarmee het laatste officiële vangnet voor die stack wegviel.

Kosten om te verlaten: het hoogst van alle versies. Niet omdat PHP 5.6 naar 8.3 op zichzelf een lastige taalsprong is. Het is omdat de dingen die je op 5.6 hielden meestal een custom-aangepast CMS zijn, een betaalintegratie die nog steeds mysql_*-functies aanroept, en een templating-systeem dat ouder is dan Composer. Reken op 80 tot 200 uur voor een kleine site. Meer voor alles met een checkout, een multicurrency-module of een zelfgebouwde BTW-berekening.

PHP 7.2 en 7.3

Minder vaak gezien dan 5.6, maar gevaarlijker, omdat de eigenaar denkt dat hij veilig zit. Dat is hij niet. Beide versies zijn jaren voorbij de security-support. De MySQL-driver werkt, de syntax oogt modern, de WordPress-admin laadt. Je kunt in 2026 prima een WooCommerce-installatie op PHP 7.2 draaien als je WP de waarschuwing laat negeren, en mensen doen dat ook.

Wat je verliest door te blijven: typed properties, arrow functions, null coalescing assignment, FFI, en elke security-patch sinds november 2020. Wat je wint met een upgrade naar 8.3: ergens tussen 15 en 25 procent minder wall-clock seconden op een gemiddelde WordPress-request, vooral door de JIT- en opcache-verbeteringen die zich sinds 7.4 hebben opgestapeld.

Kosten om te verlaten: 20 tot 60 uur voor een normale contentsite. WooCommerce, Magento 1 en elke custom checkout leggen er nog 40 tot 80 uur bovenop.

PHP 7.4

De comfortabele leugen. PHP 7.4 ging end-of-life in november 2022, maar het is de versie die we het vaakst tegenkomen op Nederlandse shared hosting, omdat het de laatste release is vóór de breaking-change-muur van 8.x. De hoster biedt 'm aan. Alle plugins werken. De developer die de site vijf jaar geleden bouwde, heeft er tegen getest.

De val: 7.4 naar 8.0 is de grootste code-rakende sprong in de geschiedenis van PHP. Warnings worden errors. {}-string-indexing is weg. Resource-types zijn nu objects. each() is weg. Reflection-signatures zijn veranderd. Elke interne functie die voorheen stilletjes null accepteerde, gooit nu een fout.

Een typische Symfony 4- of Laravel 6-codebase, door Rector gehaald met de juiste rule sets, komt er na 8 tot 24 uur echt engineeringwerk weer uit, plus nog een volle dag testen en handmatig patchen voor wat automatisering niet vangt (custom __call-magie, runtime-gegenereerde method-signatures, alles wat create_function gebruikte).

PHP 8.0

De halve migratie. Iemand, meestal een vorig bureau, heeft in 2022 of 2023 de runtime van 7.4 naar 8.0 gebumpt, genoeg warnings opgelost om de homepage te laten laden, en de klus afgevinkt. Daarna vertrokken ze. PHP 8.0 zelf ging in november 2023 end-of-life.

Het risicoprofiel hier is specifiek. De site draait op een moderne runtime, dus in audit-tools rolt 'ie er niet uit als duidelijk legacy, maar hij staat al tweeënhalf jaar zonder security-support. Composer-dependencies zijn sinds de upgrade bevroren, omdat niets dat na 2023 is uitgebracht netjes op 8.0 draait.

Kosten om naar 8.3 te verlaten: 4 tot 16 uur, het meeste daarvan Composer-gehannes. De taalsprong is klein. De dependency-resolutie-hoofdpijn niet.

PHP 8.1

De versie die net van de klif is gevallen. PHP 8.1 ging end-of-life op 31 december 2025. Vijf maanden geleden, op het moment van schrijven. Heeft je hoster je nog niet aangestoten, dan komt dat nog.

8.1 naar 8.2 is de dynamic-properties-deprecation, en dat is degene om te kennen. In 8.2 levert schrijven naar een niet-gedeclareerde property een deprecation notice op. In 9.0 gaat dat een Error gooien. De fix is mechanisch, maar je moet wel elke plek vinden.

// 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;
    }
}

Kosten om 8.1 te verlaten: 4 tot 12 uur voor de meeste sites. Hoger als je ontdekt dat een kritieke plugin niet meer is onderhouden sinds 2022 en de auteur stil is gevallen op het supportforum.

PHP 8.2

Security-only support loopt door tot eind 2026. Over ongeveer zes maanden. Hier landen de meeste klanten die in 2024 of 2025 met een migratie zijn begonnen. Het is een prima plek om de rest van dit jaar uit te zitten, en de sprong vanaf hier naar 8.3 is klein: typed class constants, het #[\Override]-attribute, json_validate(), en een paar gerichte deprecations.

Kosten om naar 8.3 of 8.4 te verlaten: 2 tot 6 uur, vrijwel allemaal in dependency-updates en niet in code.

PHP 8.3 en 8.4

De groene zone. 8.3 houdt security-support tot eind 2027. 8.4 (uitgebracht november 2024) wordt ondersteund tot eind 2028 en voegt property hooks en asymmetric visibility toe. Dat zijn de eerste taalfeatures in lange tijd die legacy-refactors echt makkelijker maken om te schrijven. Begin je in 2026 een nieuw project, ga dan direct op 8.4. Heb je een gezonde 8.3-codebase, jaag de sprong dan niet door.

De officiële PHP supported-versions-tabel is de canonieke bron voor elke datum in deze post. Print 'm. Hang 'm naast je monitor.

De rekensom die niemand maakt

Dit is de berekening die we elke klant doorlopen. Niet subtiel, maar niemand maakt 'm tot we ze ervoor laten zitten.

Neem je jaarlijkse hostingrekening, inclusief eventuele security-toeslag voor de niet-ondersteunde runtime. Tel daar de uren bij op die je team per jaar besteedt aan het omzeilen van de legacy-stack (de deploy die 40 minuten kost, de staging-omgeving die niet bestaat, de plugin die je niet kunt updaten, de developer-vacature op Marktplaats). Vermenigvuldig met je interne uurtarief. Tel daar de verwachte kosten bij op van één security-incident op een niet-gepatchte runtime, verdisconteerd met de kans die je er per jaar aan toekent.

Voor de meeste MKB'ers die we doorlichten, komt dat getal ergens tussen €8.000 en €25.000 per jaar uit. De migratie is meestal een eenmalige €15.000 tot €40.000. De terugverdientijd is zelden langer dan twee jaar, en dat is nog vóór je meerekent welke features je team weer kan opleveren zodra de codebase op een ondersteunde runtime draait.

Oude PHP-runtimes zijn precies wat geautomatiseerde scanners als eerste vinden. Het constante achtergrondgezoem van bots die /wp-login.php, /xmlrpc.php en bekende plugin-paden afkloppen op elk IPv4-adres heeft geen academische bron nodig. Hoe langer je runtime na EOL blijft draaien, hoe groter het gat tussen wat jouw server kent en wat de scanner van iemand anders allang weet.

Wat je in het komende uur kunt doen

SSH in je productie-host en draai php -v. Schrijf de versie op. Open de PHP supported-versions-tabel in een ander tabblad. Staat jouw versie in de rode zone, dan heb je vandaag nog geen migratieplan nodig. Je hebt één agenda-afspraak nodig, met een datum, voor het moment dat je de offerte gaat opvragen.

Toen we voor het laatst een Drupal 7-groothandelscatalogus van PHP 5.6 af migreerden, was het niet de taalsprong die het budget opvrat. Het was één custom module die de BTW-berekening deed voor een afgeschaft belastingregime, geschreven door een developer die in 2017 was vertrokken. Die hebben we vanaf het databaseschema weer opgebouwd. Dat soort archeologie is het echte werk in een legacy-migratie, en daarom valt de offerte altijd hoger uit dan de versie-bump op het eerste gezicht suggereert.