Migreren van Legacy PHP-sites zonder Bedrijfsprocessen te Verstoren

Bij DigiForge hebben we te veel legacy PHP-migratieprojecten zien mislukken — niet omdat de technologie moeilijk was, maar omdat het bedrijf tijdens de verhuizing gewoon bleef draaien. Het woord 'migratie' komt zelf van het Latijn voor 'verhuizen van de ene naar de andere plaats', en in de computerwereld betekent het specifiek 'een nieuw computersysteem gaan gebruiken, of informatie van het ene type systeem naar het andere verplaatsen' [1]. Dat klinkt eenvoudig, maar wanneer je een PHP-monoliet migreert die orders, gebruikerssessies en betalingsintegraties afhandelt, is de echte uitdaging ervoor te zorgen dat je klanten er niets van merken.

Beoordeel voordat je een regel code aanraakt

Voordat we ook maar denken aan het schrijven van nieuwe routers of het installeren van een modern framework, voeren we een audit uit van de bestaande applicatie — niet alleen van de code, maar ook van het runtime-gedrag. Begin met een grondige inventarisatie van alle ingangspunten: elke route, elke cron-job, elke taak in de wachtrij. Legacy PHP-apps hebben vaak verborgen eindpunten — misschien een cron.php die elke zondag de salarisadministratie draait, of een aangepast API-eindpunt dat door een externe verzendservice wordt gebruikt. Als je er één mist, zal de migratie iets breken.

Documenteer tijdens de audit ook de gegevensstroom: hoe maakt de oude applicatie verbinding met de database? Zijn er opgeslagen procedures? Is er een gedeeld bestandssysteem voor geüploade afbeeldingen of sessiebestanden? Veel legacy PHP-apps vertrouwen op bestandsgebaseerde sessies, die niet horizontaal schalen. Dat is een rode vlag die we vroeg aanpakken, vaak door sessies naar Redis of een database te migreren.

Kies een migratiestrategie die past bij uw risicobereidheid

Bij DigiForge raden we doorgaans een van de drie strategieën aan, afhankelijk van hoeveel risico het bedrijf kan verdragen.

De Big Bang-herschrijving

Dit is de meest ingrijpende aanpak: u bouwt het nieuwe systeem helemaal opnieuw en schakelt in één keer over. Het is ook de riskantste. We hebben gezien dat dit alleen werkt als de legacy-app klein is (denk aan een paar dozijn pagina's) of als het bedrijf een gepland onderhoudsvenster kan tolereren. Vermijd deze aanpak voor alles met realtime transacties of 24/7 klanten.

Het Strangler Fig-patroon

Dit patroon, vernoemd naar de tropische plant die langzaam zijn gastheer omhult, stelt je in staat om stukjes van de legacy-applicatie stapsgewijs te vervangen. Je routeert specifieke URL's of API-eindpunten naar de nieuwe code, terwijl de rest nog op oude PHP draait. Een load balancer of reverse proxy (zoals Nginx of HAProxy) kan verkeer sturen op basis van het aanvraagpad. Elk vervangen stuk vermindert het risico omdat je telkens maar een klein oppervlak wijzigt. We gebruiken dit patroon in bijna elke grote migratie.

Feature Flags Overal

Zelfs met een strangler fig geven feature flags je een noodschakelaar. Als het nieuwe afreken-eindpunt fouten geeft, zet je een vlag om en gaat het verkeer terug naar de oude code — allemaal zonder een deploy. Tools zoals LaunchDarkly of een eenvoudige database-gestuurde toggle werken goed. We zetten alles achter een vlag, zelfs de databaseverbinding. Zo kunnen we een nieuwe query in productie testen met slechts een paar gebruikers voordat we deze uitrollen naar iedereen.

Voer de Migratie Uit met Nul Downtime

Nul downtime betekent niet nul risico — het betekent dat de gebruiker nooit een foutpagina ziet. De sleutel is dubbel schrijven: wanneer je naar een nieuw databaseschema of een andere opslagbackend migreert, schrijf je gegevens tegelijkertijd naar zowel het oude als het nieuwe systeem. Begin met naar beide te schrijven, maar lees van het oude. Zodra het nieuwe systeem is bijgewerkt en je de gegevensintegriteit hebt geverifieerd, schakel je het lezen over naar het nieuwe systeem. Stop ten slotte met schrijven naar het oude systeem. Dit werkt voor databases, wachtrijen, bestandsopslag en zelfs API-integraties.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

Tijdens de dual-write-fase voer je elke paar minuten reconciliatiescripts uit om de twee opslagen te vergelijken. Eventuele afwijkingen worden snel opgemerkt. Zodra het nieuwe systeem een volledige bedrijfscyclus (meestal 48 uur) overeenkomt, schakel je de leesoperaties om. Houd de foutenlogboeken het eerste uur nauwlettend in de gaten — als er iets mis lijkt, schakel dan terug.

Omgaan met sessiestatus

Legacy PHP gebruikt vaak $_SESSION opgeslagen in bestanden. Een nieuwe Laravel- of Symfony-app verwacht waarschijnlijk database- of Redis-sessies. Om gebruikers tijdens de migratie ingelogd te houden, implementeren we een sessiebrug: de oude app schrijft sessies naar zowel bestanden als een gedeelde Redis-opslag; de nieuwe app leest uit Redis. Zodra de migratie is voltooid, schakel je de bestandsschrijver uit en verwijder je de oude sessiehandler.

Validatie na migratie en terugdraaiplanning

Zelfs met zorgvuldige planning gaat er wel eens iets mis. Dat is geen pessimisme, maar technisch realisme. Voordat je de laatste schakelaar omzet, schrijf je een terugdraaiplan dat het herstellen van DNS-records, het terugdraaien van databaseschema-wijzigingen en het opstarten van de oude applicatie vanaf een snapshot omvat. Oefen de terugdraaiing minstens één keer in de staging-omgeving.

Bij DigiForge houden we de oude productieomgeving altijd minstens twee weken draaiende na een grote migratie. De kosten van een paar extra servers zijn verwaarloosbaar vergeleken met de kosten van een mislukte terugdraaiing die uren duurt.

Validatie gaat verder dan controleren of pagina's laden. We voeren geautomatiseerde zakelijke transactietests uit: plaats een bestelling, werk een profiel bij, verwerk een terugbetaling. Vergelijk de uitvoer van kritieke API-eindpunten tussen oud en nieuw. Als je een monitoringtool zoals New Relic of Sentry gebruikt, stel dan aangepaste waarschuwingen in voor 5xx-fouten of trage queries. Betrek ten slotte het zakelijke team — laat hen hun dagelijkse workflows in een staging-omgeving op het nieuwe systeem uitvoeren voordat je live gaat.

Veelvoorkomende valkuilen en hoe we ze vermijden

• Aannemen dat de oude code correct is. Legacy PHP bevat vaak stille bugs die 'features' werden. Elk gedrag repliceren? Soms is het veiliger om de bug in de nieuwe versie te repareren als het bedrijf ermee instemt.
• Cronjobs en geplande taken vergeten. Die oude curl-aanroepen naar een aangepast script? Ze hebben een thuis nodig in het nieuwe systeem. We migreren cron-taken naar een taakplanner zoals Laravel's scheduler of een speciale worker.
• Integraties van derden verwaarlozen. Betalingsgateways, verzend-API's en partner-webhooks sturen gegevens in specifieke formaten. Test de integratie-eindpunten vroeg — je wilt geen formaat-mismatch ontdekken op Black Friday.

Nog een les die we hebben geleerd: vertrouw niet op de oude documentatie. De code is de enige bron van waarheid. We doen altijd een grondige code-analyse met de ontwikkelaar die het origineel schreef (indien beschikbaar) of met een teamlid dat het jarenlang heeft onderhouden. Hun mentale model van de eigenaardigheden van de app is van onschatbare waarde.

Conclusie

Het migreren van een legacy PHP-site is als het uitvoeren van een openhartoperatie bij een patiënt die een marathon loopt. Het risico is reëel, maar de beloning — moderne prestaties, beveiliging en ontwikkelproductiviteit — is enorm. Bij DigiForge hebben we tientallen bedrijven door dit proces begeleid. De sleutel is om in kleine, omkeerbare stappen te bewegen, het oude systeem altijd draaiende te houden en nooit te stoppen met monitoren totdat je zeker weet dat het nieuwe systeem stabiel is.

Onthoud: migratie gaat niet alleen over de technologie — het gaat erom dat je bedrijf operationeel blijft terwijl je de motor in de vlucht vervangt. Plan zorgvuldig, test onophoudelijk en zorg altijd voor een terugdraaioptie. Je gebruikers zullen nooit merken dat er iets is veranderd.