PHP 7 naar PHP 8 migreren

Van een versie zonder security-support naar een versie die weer jaren meekan.

Ongeveer 30% van alle PHP-websites draait nog op PHP 7 en ruim 8% zelfs op PHP 5 — versies die al jaren geen beveiligingsupdates meer krijgen. Een migratie is technisch goed te overzien en voor een groot deel te automatiseren. Het uitstellen is meestal duurder dan het doen.

Investering

Vanaf € 4.500

Doorlooptijd

2 tot 6 weken

Reactietijd

1 werkdag

Voor een middelgrote applicatie. Na een korte scan weten we hoeveel van de migratie automatiseerbaar is en hoeveel handwerk overblijft — dat bepaalt de prijs.

Herken je dit?

Geen beveiligingsupdates meer

Bij een End-of-Life-versie worden nieuw ontdekte kwetsbaarheden simpelweg niet meer gedicht. Dat is een oplopend risico dat vanzelf groter wordt.

Je hoster dwingt je

Hostingpartijen zetten oude PHP-versies uit. Dan is de deadline niet meer van jou en moet het onder tijdsdruk.

Pakketten haken af

Composer-packages laten oude PHP-versies vallen. Op een gegeven moment kun je geen enkele dependency meer bijwerken, inclusief de dependency met de kwetsbaarheid.

Je laat performance liggen

PHP 8 is aanzienlijk sneller dan PHP 7. Op drukke applicaties scheelt dat direct in serverkosten.

Onze aanpak

Het grootste deel van een versiemigratie is mechanisch werk dat gereedschap beter doet dan een mens. Rector past duizenden wijzigingen consistent toe; wij besteden onze tijd aan het deel dat echt beoordeling vraagt.

1

Compatibiliteitsscan

PHPStan en Rector in dry-run over de codebase: wat breekt er, hoeveel plekken zijn het, en hoeveel daarvan is automatisch op te lossen? Je krijgt dit als losse quickscan, ook als je daarna niets doet.
2

Testvangnet

Ontbreken er tests op de kritieke paden, dan komen die er eerst. Zonder tests weet je na de migratie niet of alles nog werkt — je hoopt het alleen.
3

Geautomatiseerde upgrade

Rector past de bekende wijzigingen toe in kleine, reviewbare stappen. Elke stap is een aparte commit, zodat te volgen is wat er is veranderd en waarom.
4

Handwerk

Wat overblijft is het interessante deel: verwijderde extensies, gewijzigd gedrag bij vergelijkingen, stringfuncties die nu strenger zijn, en dependencies zonder PHP 8-versie.
5

Uitrol

Eerst naar een testomgeving op de nieuwe versie, dan productie — met een teruggangsscenario dat vooraf is uitgeprobeerd.

Wat je krijgt

Compatibiliteitsrapport: wat breekt, hoeveel plekken, wat is automatiseerbaar
Applicatie draaiend op een actueel ondersteunde PHP 8-versie
Bijgewerkte Composer-dependencies zonder bekende kwetsbaarheden
Tests rond de kritieke paden, zodat een volgende upgrade routine wordt
Rector-configuratie in de repository, zodat je zelf mee kunt naar 8.5 en verder

Wie het werk doet

PHP.nl is het Nederlandse PHP-platform, geen bureau. Aanvragen worden gekoppeld aan een specialist uit het eigen netwerk; Serff Webdevelopment is de vaste uitvoerende partner voor grotere trajecten. Je weet vóór ondertekening wie het werk doet en spreekt die persoon zelf.

Alle code, tests en documentatie blijven in jouw repository. Elke fase levert op zichzelf werkende, overdraagbare software op — ook als je besluit het vervolg zelf of met een andere partij te doen.

Veelgestelde vragen

Welke PHP-versies worden nog ondersteund?

Dat verschuift elk jaar. PHP.nl houdt een altijd actuele EOL-tracker bij met per versie de datum waarop actieve support en security-support aflopen. Vuistregel: elke versie krijgt twee jaar actieve support en daarna één jaar alleen beveiligingsfixes.

Hoeveel van de migratie is te automatiseren?

Bij een gemiddelde applicatie het grootste deel van de wijzigingen — Rector kent de breaking changes tussen versies en past ze consistent toe. Wat overblijft is doorgaans het werk rond verwijderde extensies, dependencies zonder PHP 8-versie, en code die leunde op gedrag dat PHP 8 strenger maakt. De quickscan geeft het precieze getal voor jouw codebase.

Wat als een dependency geen PHP 8-versie heeft?

Dat komt voor en is meestal het echte knelpunt. Er zijn drie routes: een onderhouden alternatief, de functionaliteit zelf overnemen, of de dependency isoleren achter een eigen laag zodat vervanging later makkelijk is. Welke route past hangt af van hoe diep het pakket in de applicatie zit; dat staat in het compatibiliteitsrapport.

Kan dit zonder downtime?

Ja, in vrijwel alle gevallen. De nieuwe versie wordt eerst op een testomgeving gedraaid; de omschakeling in productie is daarna een kwestie van minuten, met een vooraf beproefd teruggangsscenario.

Kunnen we alleen de scan afnemen?

Ja. De compatibiliteitsscan is een losse opdracht met een vaste prijs. Je krijgt het rapport en bent nergens aan verbonden — veel bedrijven gebruiken hem om intern budget te onderbouwen.