Data-archeologie: hoe je legacy data doorgrond voordat je migreert

Gevestigde bedrijven zitten vaak op decennia aan data in systemen die niemand meer begrijpt. De oorspronkelijke ontwikkelaars zijn vertrokken, documentatie ontbreekt of is verouderd, en de business rules zitten verborgen in code die niemand durft aan te raken. Toch draait de organisatie erop. Klantgegevens, transactiegeschiedenis, productcatalogi – allemaal opgeslagen in databases met cryptische tabelnamen, onduidelijke relaties en kolommen waarvan de betekenis geraden moet worden.

Data-archeologie is het proces waarbij je die legacy-systemen doorgrond. Niet om ze te bewaren, maar om te begrijpen wat erin zit voordat je beslist wat ermee gebeurt. Migreren naar moderne architectuur klinkt logisch, maar je kunt niet migreren wat je niet begrijpt. En je wilt niet alles migreren, want legacy systemen bevatten naast waardevolle kennis ook technische schuld, workarounds en verouderde aannames die je niet wilt meenemen.

Waarom legacy data ondoorgrondelijk wordt

Systemen groeien organisch. Wat begon als simpele database voor orderverwerking krijgt na tien jaar klantportaal, voorraadkoppeling, facturatiemodule en CRM-integratie. Elke toevoeging brengt nieuwe tabellen, kolommen en relaties. Soms worden oude structuren aangepast, soms worden ze omzeild met nieuwe tabellen die parallel bestaan. Niemand ruimt op omdat het werkt en verandering risico betekent. Soms gaat het om oude systemen, zoals de IBM S390 mainframe, of een verouderde programmeertaal zoals Cobalt.

Kennis verdwijnt geleidelijk. De ontwikkelaar die wist waarom de kolom customer_type_override bestaat en wanneer die wordt gebruikt, is vijf jaar geleden vertrokken of gepensioneerd. De business analist die de logica achter discount_category_special begreep, werkt nu ergens anders. Nieuwe medewerkers leren het systeem door te observeren wat het doet, niet waarom het zo werkt. Ze nemen gedrag over zonder de onderliggende logica te begrijpen. Ook documentatie veroudert sneller dan code. Een wijziging wordt doorgevoerd, de code aangepast, maar de documentatie blijft onveranderd. Na jaren zijn ze compleet uit sync. Teams vertrouwen documentatie niet meer en verlaten zich op de code zelf. Maar code zonder context vertelt je wat er gebeurt, niet waarom het zo is gebouwd of welk probleem het oplost.

Workarounds worden standaard. Een bug in het betalingssysteem wordt omzeild met een handmatige correctie in een nachtbatch. Jaren later draait die batch nog steeds, maar niemand weet meer welke bug het compenseerde of of die bug überhaupt nog bestaat. Het systeem functioneert, dus waarom zou je het aanpassen? Die houding stapelt lagen op elkaar totdat niemand meer weet welke onderdelen essentieel zijn en welke ballast.

Wat je ontdekt als je graaft

Data-archeologie onthult domeinkennis die nergens gedocumenteerd staat. Een tabel genaamd promo_eligibility_override bevat regels over welke klanten promoties mogen krijgen. Door data te analyseren zie je patronen: klanten in bepaalde regio’s zijn uitgesloten, bepaalde productcategorieën gelden niet, en bij orders boven een drempel vervalt de beperking. Die logica zit niet in handboeken maar in data en code. Het is business kennis die door de jaren heen is gegroeid en nu impliciet in het systeem leeft.

Ook ontdek je onbedoelde afhankelijkheden. Een kolom die ooit bedoeld was voor interne notities wordt gebruikt door een ander systeem om beslissingen te nemen. Een veld dat technisch optioneel is, blijkt in de praktijk altijd gevuld omdat downstream processen erop rekenen. Die afhankelijkheden zijn niet gedocumenteerd maar wel cruciaal. Als je migreert zonder ze te begrijpen, breken processen die op het oog losstaan van de data die je wijzigt.

Historische beslissingen krijgen context door data te onderzoeken. Waarom heeft de database zeven verschillende statuscodes voor “in behandeling”? Door orders te analyseren zie je dat elk een specifiek moment in het proces markeert dat vroeger handmatig werd afgehandeld. Die granulariteit was nodig toen mensen elke stap bevestigden. Nu alles geautomatiseerd is, zijn drie statussen voldoende. Maar dat begrijp je pas als je ziet hoe de codes historisch werden gebruikt.

Hoe je data-archeologie systematisch aanpakt

Begin met inventariseren wat je hebt. Welke databases bestaan? Welke tabellen bevatten welke data? Hoe groot zijn ze? Wanneer werden ze voor het laatst gewijzigd? Die basisinformatie geeft overzicht. Je ontdekt tabellen die jaren niet zijn aangeraakt en waarschijnlijk obsoleet zijn. Je ziet welke systemen actief worden gebruikt en prioriteit verdienen.

Analyseer relaties tussen tabellen. Foreign keys tonen formele koppelingen, maar die vertellen niet het hele verhaal. Join-patronen in queries onthullen hoe tabellen in de praktijk worden gecombineerd. Soms zie je dat twee tabellen altijd samen worden opgevraagd, wat suggereert dat ze conceptueel één entiteit vertegenwoordigen die toevallig over twee tabellen is verspreid. Die kennis helpt bij het ontwerpen van een gecleande architectuur.

Praat met mensen die het systeem dagelijks gebruiken. Ze weten welke velden cruciaal zijn en welke worden genegeerd. Ze kennen de workarounds die nodig zijn om resultaten te krijgen. Een sales manager vertelt dat ze altijd kolom X handmatig corrigeren omdat het systeem daar foute data genereert. Dat is waardevolle kennis: ofwel los je de oorzaak op in de nieuwe architectuur, ofwel accepteer je dat handmatige correctie inherent aan het proces is.

Test hypotheses met data-analyse. Als je vermoedt dat een kolom alleen wordt gebruikt voor legacy klanten, query de database en check of recente records die kolom leeg laten. Als een relatie optioneel lijkt maar altijd aanwezig is, tel hoeveel records de relatie missen. Data liegt niet, maar vraagt wel interpretatie. Lage aantallen kunnen betekenen dat iets obsoleet is, of juist dat edge cases belangrijk zijn.

Beslissen wat je behoudt en wat je loslaat

Niet alles uit legacy systemen verdient migratie. Data die tien jaar niet is opgevraagd, heeft geen operationele waarde. Tabellen die duplicaten bevatten van data die elders master is, zijn overbodig. Kolommen die alleen werden gebruikt voor rapportages die niet meer draaien, kun je weglaten. Data-archeologie helpt die scheiding te maken tussen essentieel en ballast.

Domeinkennis extraheren is niet hetzelfde als systemen kopiëren. Een legacy database met zestig tabellen kan conceptueel dezelfde informatie bevatten als een moderne architectuur met twintig tabellen. De oude structuur weerspiegelt technische beperkingen of historische beslissingen die niet meer relevant zijn. Je behoudt de kennis – welke klanttypen bestaan, welke promotieregels gelden, welke productcategorieën worden onderscheiden – maar implementeert die in een schonere structuur.

Sommige legacy logica was een workaround voor beperkingen die niet meer bestaan. Een nightly batch die data synchroniseerde tussen systemen omdat real-time integratie niet mogelijk was, hoeft niet te worden gemigreerd als moderne API’s directe communicatie ondersteunen. Een kolom die handmatig werd gevuld omdat automatische berekening te traag was, is overbodig met hedendaagse rekenkracht. Archeologisch onderzoek onthult welke logica probleem-oplossingen waren en welke daadwerkelijke business rules.

Migreren volgens Lift & Shift

Een pragmatische migratiestrategie is het legacy systeem eerst technisch te moderniseren zonder de logica te herschrijven. Je vertaalt oude code naar een moderne runtime-omgeving, vaak geautomatiseerd, zodat het systeem blijft functioneren maar op eigentijdse infrastructuur draait. Die stap elimineert het grootste risico: dat het bedrijf stilvalt tijdens migratie. Vervolgens identificeer je welke modules daadwerkelijk vervangen moeten worden en welke gewoon kunnen blijven draaien in de nieuwe omgeving. Order-processing dat perfect werkt sinds 1995? Laat het. Een rapportagemodule die niemand meer gebruikt? Drop het. Een klantportaal dat verouderd is? Vervang het door moderne componenten. Die gefaseerde aanpak geeft je tijd om te begrijpen wat essentieel is terwijl je al van oude hardware en platformen af bent. Het is niet sexy, maar het voorkomt dat je drie jaar investeert in een complete herschrijving die halverwege strandt omdat de scope onderschat was.

RAG als brug tussen oud en nieuw

Volledige migratie is niet altijd nodig of wenselijk. RAG biedt een alternatief: maak legacy data doorzoekbaar zonder het te verplaatsen. Je indexeert de oude database, documenteert wat elke tabel en kolom betekent, en geeft een AI-systeem toegang via queries. Medewerkers kunnen in natuurlijke taal vragen stellen over historische data en krijgen antwoorden zonder dat ze SQL hoeven te schrijven of de oude structuur moeten begrijpen.

Die aanpak is vooral waardevol voor data die zelden nodig is maar niet mag verdwijnen. Oude contracten, afgehandelde projecten, historische prijsafspraken – ze moeten beschikbaar blijven voor audits of juridische vragen, maar rechtvaardigen geen volledige migratie naar de nieuwe architectuur. RAG geeft toegang wanneer nodig zonder dat je legacy systemen operationeel hoeft te houden.

Van archeologie naar architectuur

Data-archeologie is geen doel maar een middel. Het einddoel is een data-architectuur die begrijpelijk, onderhoudbaar en schaalbaar is. Maar om daar te komen moet je eerst snappen wat je hebt, waarom het zo is en wat daarvan essentieel blijft. Graven in legacy systemen is frustrerend werk. Code zonder documentatie, tabellen zonder betekenis, logica zonder context. Maar elke ontdekking brengt je dichter bij een weloverwogen migratiestrategie.

De waarde zit niet in het behouden van oude systemen maar in het bewaren van de kennis die erin zit. Business rules die twintig jaar zijn verfijnd, klantinzichten die door duizenden transacties zijn bevestigd, processen die zijn geoptimaliseerd door praktijk in plaats van theorie. Die kennis verdient behoud. De systemen die het bevatten niet per se. Data-archeologie helpt die scheiding te maken, zodat je vooruitgaat zonder te vergeten wat werkte.