Een legacy-PHP-applicatie vervangen vereist geen volledige herschrijving in één keer. Met een geleidelijke vervanging kun je functionaliteit overzetten terwijl het bedrijf operationeel blijft, maar dit werkt alleen als je nauwkeurig bepaalt welk systeem elke bewerking afhandelt en welk systeem de zeggenschap over elk gegeven heeft. Zonder die grenzen kunnen beide applicaties verschillende regels uitvoeren, onverenigbare schrijfbewerkingen accepteren en resultaten opleveren die moeilijk met elkaar te verenigen zijn.
Het doel is niet om twee implementaties voor onbepaalde tijd naast elkaar te laten bestaan. Het is om verantwoordelijkheden gecontroleerd over te dragen, te controleren of de nieuwe oplossing het vereiste gedrag behoudt en oude afhankelijkheden te verwijderen zodra daar voldoende bewijs voor is. Daarvoor zijn functionele grenzen, observability, één bron van waarheid per gegevensdomein en door zowel technologie als product overeengekomen criteria voor voortgang nodig.
Waarom twee applicaties naast elkaar niet genoeg zijn
Dat een oude en een nieuwe applicatie beschikbaar zijn, betekent nog niet dat er sprake is van een migratie. Als beide dezelfde bewerking accepteren, kunnen ze verschillende regels toepassen op validaties, rechten, prijzen, statussen of neveneffecten. Het probleem komt vaak pas laat aan het licht: een factuur wordt op twee manieren berekend, een melding wordt twee keer verstuurd of een statuswijziging wordt niet in alle systemen verwerkt.
Voor een geleidelijke vervanging van een legacy-PHP-systeem moet expliciet worden vastgelegd welke functionaliteit wordt overgezet, wie de verzoeken ontvangt en waar de zeggenschap over de gegevens ligt. De grens moet functioneel zijn, niet simpelweg een lijst met controllers of tabellen. Een functionaliteit als ‘een retour afhandelen’ kan autorisatie, een voorraadaanpassing en een terugbetaling omvatten; die opdelen zonder inzicht in die afhankelijkheden levert een misleidende grens op.
Leg voordat je de routering wijzigt het waarneembare gedrag vast: invoer, uitvoer, relevante fouten, rechten, neveneffecten en externe afhankelijkheden. Maak onderscheid tussen bedrijfsregels en toevallige implementatiedetails. Niet al het historische gedrag hoeft behouden te blijven, maar elke bewuste wijziging moet als zodanig worden goedgekeurd en getest, en mag niet stilzwijgend aan de migratie worden toegeschreven.
Kies een eerste functionaliteit die verifieerbaar is
De eerste kandidaat hoeft niet de kleinste of meest zichtbare te zijn. Het is raadzaam een functionaliteit te kiezen met begrijpelijke grenzen, redelijke koppeling en een verifieerbaar resultaat. Ook de operationele waarde telt: een migratie kan risico verminderen, frequente wijzigingen mogelijk maken of een onderdeel verbeteren dat het bedrijf verder moet kunnen ontwikkelen.
- Koppeling: breng aanroepen naar andere modules, directe toegang tot gedeelde tabellen, geplande taken en afhankelijkheden van globale status in kaart. Veel koppelingen maken migratie niet onmogelijk, maar verhogen wel de kosten om de grens te bepalen.
- Verifieerbaarheid: controleer of representatieve scenario’s kunnen worden opgesteld en het resultaat kan worden waargenomen zonder afhankelijk te zijn van subjectieve interpretaties.
- Impact en omkeerbaarheid: beoordeel wat er gebeurt als de functionaliteit uitvalt en of de oude route kan worden hersteld zonder gegevens te verliezen of externe effecten te herhalen.
- Operationele paraatheid: bevestig dat er verantwoordelijken, metrics en procedures zijn om afwijkingen te onderzoeken voordat echt verkeer wordt omgeleid.
Een korte inventarisatie helpt: functionaliteit, afnemers, gegevens die worden gelezen en gewijzigd, externe effecten, productverantwoordelijke en technisch verantwoordelijke. Als niet duidelijk is wie een bewerking gebruikt of welk systeem een gegeven bijwerkt, moet eerst de kennis van het systeem worden verbeterd; de functionaliteit meteen migreren vermindert de onzekerheid niet.
Routering en zeggenschap over gegevens bepalen
De router moet expliciet bepalen welke implementatie een verzoek afhandelt. Afhankelijk van de architectuur kan dat een applicatielaag, een gateway of een beslissing op het ingangspunt zijn. Het belangrijkste is dat het criterium waarneembaar en consistent is: op basis van functionaliteit, klant, bewerking of een gecontroleerde cohort. Voorkom dat twee routes dezelfde opdracht zonder coördinatie kunnen verwerken.
Wijs bij elke grens één eigenaar toe per gegeven of aggregate. Als het nieuwe systeem bijvoorbeeld eigenaar is van bestellingen, moet het oude systeem deze niet rechtstreeks blijven wijzigen via gedeelde toegang tot tabellen. Andere componenten kunnen een gedefinieerde interface raadplegen of wijzigingen via events ontvangen, afhankelijk van de consistentiebehoeften. Een database delen kan een overgangsfase zijn, maar betekent niet dat de zeggenschap wordt gedeeld.
Leg bij synchronisatie de richting en het doel vast. Een leesreplica kan rapportages of oude afnemers voeden; ze mag niet per ongeluk uitgroeien tot een tweede geautoriseerde schrijfbron. Als events worden uitgewisseld, definieer dan waar nodig identifiers en volgorde, evenals retries, deduplicatie en de afhandeling van mislukte berichten. Maak ook duidelijk hoe vertragingen worden vastgesteld en wie afwijkingen oplost.
Voorkom onduidelijke dubbele schrijfbewerkingen
Schrijven naar twee systemen tijdens één verzoek lijkt een eenvoudige manier om ze synchroon te houden, maar veroorzaakt gedeeltelijke fouten: de ene schrijfbewerking kan slagen en de andere mislukken. Een verzoek opnieuw uitvoeren kan een bewerking dupliceren. Zonder een strategie voor idempotentie, reconciliatie en foutafhandeling bestaat er geen enkele transactie die consistentie tussen onafhankelijke applicaties garandeert.
Geef bij elke bewerking voorrang aan één schrijfautoriteit. Tijdens een overgang kan het eigenaarsysteem wijzigingen publiceren om een projectie of compatibiliteitskopie bij te werken. Registreer voor asynchrone processen de wijziging en het bijbehorende bericht betrouwbaar binnen dezelfde transactionele grens, als de infrastructuur dat toelaat, en ontwerp idempotente consumers. Als een specifieke beperking dual writes noodzakelijk maakt, behandel dit dan als een tijdelijke uitzondering: specificeer de volgorde, mogelijke fouten, reconciliatie en de datum of voorwaarde voor verwijdering.
Ook voor historische gegevens zijn regels nodig. Bepaal hoe de beginstatus wordt geladen, hoe gelijktijdige wijzigingen worden verwerkt en hoe het resultaat wordt gecontroleerd voordat het eigenaarschap wordt overgedragen. Ga er niet van uit dat een geslaagde import betekent dat relaties, afgeleide statussen en rechten volledig zijn overgenomen.
Gedrag vergelijken zonder effecten te dupliceren
Vergelijken vermindert het risico als berekening en uitvoering van elkaar worden onderscheiden. Een aanpak is een kopie van de invoer naar de nieuwe implementatie te sturen in observatiemodus en het antwoord te vergelijken met dat van het actieve systeem, zonder dat de kopie e-mails verstuurt, betalingen uitvoert, voorraad wijzigt of andere externe effecten veroorzaakt. Die uitvoering moet gebruikmaken van gecontroleerde gegevens en afhankelijkheden, of effecten vervangen door adapters die alleen de intentie registreren.
Vergelijk resultaten semantisch: statussen, bedragen, beslissingen en relevante fouten, niet noodzakelijk de volgorde van velden of tijdstempels. Gebruik representatieve scenario’s met grensgevallen, onvolledige gegevens, rechten en fouten van afhankelijkheden. Voeg geautomatiseerde tests toe voor kritieke regels en bewaar geanonimiseerde of synthetische voorbeelden wanneer echte gegevens niet geschikt zijn voor evaluatie.
Een shadow run bewijst op zichzelf niet dat het nieuwe systeem operationeel kan functioneren. Latenties, concurrency of echte integraties worden mogelijk niet nagebootst, en een verschil kan zowel op een defect als op een ongedocumenteerde oude regel wijzen. Elk verschil moet worden geclassificeerd, aan een verantwoordelijke worden toegewezen en worden opgelost: corrigeren, een goedgekeurde wijziging accepteren of het geval met een verifieerbare reden uitsluiten.
De voortgang instrumenteren en terugschakelen voorbereiden
Registreer de gekozen route, de implementieversie, de correlatie-ID en het resultaat van elke bewerking. Meet fouten, latentie, retries, synchronisatievertragingen en afwijkingen, uitgesplitst naar functionaliteit. Voorkom dat onnodige geheimen of persoonsgegevens worden vastgelegd; definieer toegangscontroles en bewaartermijnen voor logs.
Spreek voordat je de blootstelling vergroot af welke stopdrempels gelden en wie de voortgang mag stilleggen. Terugschakelen betekent niet altijd dat de routering wordt gewijzigd: als het nieuwe systeem al schrijfbewerkingen heeft geaccepteerd, kan het oude systeem achterlopen op de nieuwste status. De procedure moet aangeven wat er gebeurt met lopende bewerkingen, openstaande berichten en geschreven gegevens; oefen dit in een geschikte omgeving. Omkeerbaarheid hangt af van de status en de effecten, niet alleen van een configuratieoptie.
Het oude systeem onder verifieerbare voorwaarden uitfaseren
Uitfasering moet gebaseerd zijn op bewijs, niet op één afzonderlijke datum. Bevestig voor een functionaliteit dat alle geplande routes naar de nieuwe eigenaar leiden; dat kritieke bewerkingen en hun foutscenario’s zijn afgedekt; dat afnemers en geplande taken niet meer afhankelijk zijn van het oude onderdeel; en dat er geen directe schrijfbewerkingen of reconciliatieprocessen zonder verantwoordelijke overblijven.
Observeer daarna de werking gedurende een met product en operations overeengekomen periode, met aandacht voor de belasting en relevante cycli van die functionaliteit. Controleer openstaande gegevens, compatibiliteitskopieën en audit- of bewaareisen voordat je onderdelen verwijdert. Werk documentatie, alerts en supportprocedures bij. Ook een oud onderdeel ‘voor de zekerheid’ behouden heeft kosten: het kan rechten, kwetsbaarheden en schrijfroutes in stand houden die het eigenaarschap onduidelijk maken.
Een praktische volgorde is: de functionaliteit afbakenen, zeggenschap over gegevens toewijzen, gedrag documenteren, tests en observability voorbereiden, gegevens laden of synchroniseren, vergelijken zonder neveneffecten, het nieuwe systeem gecontroleerd blootstellen aan verkeer, resultaten beoordelen en afhankelijkheden met expliciete goedkeuring verwijderen. Als een fase geen acceptatiecriteria of verantwoordelijke heeft, is de migratie nog niet klaar om verder te gaan.
