Legacy software moderniseren zonder uw bedrijf stil te zetten

AI-tools doen inmiddels het grootste deel van het mechanische werk: verouderde taalconstructies herschrijven, bibliotheken vervangen, projectbestanden omzetten. Microsofts GitHub Copilot-upgradeagent zet .NET Framework-projecten van elke versie om naar .NET 8 of later, heeft een scenario voor ASP.NET Web Forms naar Blazor en maakt per deelstap een Git-commit, zodat elke wijziging terug te draaien is. Voor PHP past Rector upgraderegels toe van PHP 5.3 tot en met 8.5.

Snelheid is dus niet meer het probleem. Het risico zit in gedrag dat nergens beschreven staat. Daarom beginnen wij met karakteriseringstests: tests die vastleggen wat het systeem vandaag doet, inclusief de eigenaardigheden waar gebruikers op rekenen. AI schrijft een eerste versie, een engineer toetst die aan echte gevallen, en daarna gaat geen wijziging door zonder groene tests en zonder dat een engineer haar heeft gelezen. Wat er in de praktijk breekt, staat in onze analyse van PHP2Shell en oude PHP-code.

Code omzetten gaat met de huidige tooling snel; data verhuizen niet. In een Access-database of een oude SQL Server-omgeving zitten dubbele klanten, velden die in de loop der jaren een andere betekenis kregen, en regels die alleen in een query van een vertrokken collega staan.

Wij werken in vier stappen. Eerst een inventaris: welke tabellen, wie leest en schrijft erin, welke rapporten en koppelingen hangen eraan. Dan de mapping van oud naar nieuw, met per veld een besluit over opschonen. Dan proefmigraties op een kopie, net zo vaak tot de reconciliatie klopt: aantallen, totalen en steekproeven per tabel, afgetekend door iemand uit de business. Pas dan de definitieve overzetting, in een afgesproken bevriezingsvenster.

Bij stapsgewijze vervanging gebruiken oud en nieuw tijdelijk dezelfde data. Microsoft wijst er bij het strangler fig-patroon op dat beide systemen dan tegelijk bij die gegevens moeten kunnen; dat ontwerp leggen we vast voordat de eerste module live gaat.

Veel legacy-problemen zijn eigendomsproblemen: de broncode staat bij een leverancier, de enige ontwikkelaar is vertrokken, of niemand weet nog welke versie in productie draait.

Bij ons staat de code vanaf de eerste dag in uw eigen repository. U krijgt de testset die het gedrag bewijst, de datamigratiescripts, een runbook waarmee uw ICT-partner de applicatie kan uitrollen en herstellen, en een verslag van de architectuurkeuzes. Er zit geen eigen framework of platformlicentie van ons onder, dus een andere leverancier of uw eigen team kan zonder ons verder.

Vraag elke leverancier, ons inbegrepen: in welke repository staat de code, wie heeft de rechten, en kan een derde de applicatie bouwen en uitrollen met alleen de overdracht?