Database migratie: van legacy naar SaaS.

Waarom migraties complex zijn

Een database migratie klinkt overzichtelijk: data uit het oude systeem halen en in het nieuwe systeem zetten. In de praktijk is het een van de meest onderschatte trajecten in softwareontwikkeling. Niet omdat de techniek zo ingewikkeld is, maar omdat de werkelijkheid van legacy data zelden overeenkomt met de aannames die je vooraf maakt.

Legacy databases zijn rommelig. Dat is geen oordeel, dat is een wetmatigheid. Na jaren van gebruik, wisselende developers en ad-hoc aanpassingen bevat vrijwel elke oudere database inconsistente formaten, ontbrekende velden, dubbele records en data die ooit ergens voor diende maar waar niemand meer de context van kent. Een klantnaam die in het ene veld als "J. de Vries" staat en in een ander als "Jan de Vries B.V." — dat soort dingen.

Daarbovenop komt het feit dat de business niet kan stoppen tijdens een migratie. Orders blijven binnenkomen, klanten blijven bellen, facturen moeten verstuurd worden. Een migratie die drie dagen downtime vereist is voor de meeste organisaties simpelweg geen optie.

En dan is er het fundamentele probleem: het datamodel van het oude systeem wijkt bijna altijd af van het nieuwe. Legacy systemen zijn organisch gegroeid, met tabellen die meerdere verantwoordelijkheden combineren, velden die iets anders betekenen dan hun naam suggereert, en relaties die alleen in de hoofden van de oorspronkelijke bouwers bestaan. Het nieuwe SaaS-platform heeft een schone, genormaliseerde structuur. Die twee werelden bij elkaar brengen is waar de echte complexiteit zit.

De migratiestrategie

De verleiding is groot om een migratie als een big bang aan te pakken: een weekend plannen, alles overzetten, maandagochtend live met het nieuwe systeem. In theorie efficiënt. In de praktijk een recept voor paniek, dataverlies en gebruikers die maandagochtend niet meer kunnen werken.

Een verantwoorde migratiestrategie is altijd gradueel. Het oude en nieuwe systeem draaien parallel, zodat je op elk moment kunt terugvallen als er iets misgaat. Je migreert per module of per tenant, niet alles tegelijk. Facturatie eerst, dan klantbeheer, dan rapportages. Elke stap wordt apart gevalideerd voordat je doorgaat naar de volgende.

Feature flags spelen hierbij een cruciale rol. Ze geven je de controle om per gebruikersgroep, per module of zelfs per individuele klant te bepalen welk systeem de bron van waarheid is. Is de migratie van module X geslaagd voor tenant A? Dan schakelt die tenant over. Zijn er problemen bij tenant B? Die blijft op het oude systeem tot alles is opgelost.

Deze aanpak kost meer tijd in de voorbereiding, maar bespaart je de nachtmerrie van een mislukte big bang waar je hele organisatie last van heeft. Een migratie die drie maanden duurt maar soepel verloopt, is altijd beter dan een migratie die een weekend zou duren maar drie weken nasleep heeft.

Data migreren is geen technisch klusje voor een vrijdagmiddag. Het is een strategisch traject dat evenveel aandacht verdient als het bouwen van het nieuwe systeem zelf.

ETL: Extract, Transform, Load

Het hart van elke datamigratie is het ETL-proces: Extract, Transform, Load. Drie stappen die eenvoudig klinken maar elk hun eigen uitdagingen kennen.

Extract

Eerst moet je de data uit het legacy systeem halen. Hoe je dat doet, hangt af van wat het oude systeem toelaat. Soms heb je directe toegang tot de database en kun je SQL-queries draaien. Soms is er een API beschikbaar, al zijn die bij oudere systemen vaak beperkt of slecht gedocumenteerd. In het slechtste geval werk je met CSV-exports, Excel-bestanden of zelfs handmatige data-extractie. De extractiemethode bepaalt mede hoe betrouwbaar en herhaalbaar je migratieproces wordt.

Transform

Dit is waar het echte werk zit. De ruwe data uit het oude systeem moet worden omgezet naar het formaat en de structuur van het nieuwe systeem. Dat betekent: data opschonen, formaten standaardiseren, duplicaten verwijderen, relaties herleggen en velden mappen naar het nieuwe schema. Een adresveld dat in het oude systeem straat, huisnummer en postcode combineerde, moet worden opgesplitst in aparte velden. Een statusveld met waarden als "actief", "Actief", "ACTIEF" en "1" moet worden genormaliseerd.

De transformatielaag is ook waar je bedrijfsregels toepast. Welke klantrecords zijn nog relevant? Hoe ga je om met orders die in het oude systeem een status hebben die in het nieuwe systeem niet bestaat? Wat doe je met data die niet valide is maar waar wel bedrijfskritische informatie in zit?

Load

De getransformeerde data wordt geimporteerd in het nieuwe systeem. Cruciaal hierbij is validatie: elke record wordt gecontroleerd tegen de constraints van het nieuwe datamodel voordat hij wordt opgeslagen. Records die niet door de validatie komen, worden gelogd voor handmatige afhandeling — niet stilzwijgend overgeslagen.

Minstens zo belangrijk is dat het importproces idempotent is. Je moet het meerdere keren kunnen draaien zonder dat er duplicaten ontstaan. Tijdens een migratie draai je het ETL-proces tientallen keren: eerst op testdata, dan op een subset van productiedata, dan op de volledige dataset. Als elke run duplicaten creëert, wordt je nieuwe database net zo rommelig als de oude.

Validatie en reconciliatie

Data is pas gemigreerd als je kunt bewijzen dat het klopt. Vertrouwen op het gevoel dat het er goed uitziet is niet genoeg. Je hebt een gestructureerd validatieproces nodig dat objectief vaststelt dat de migratie geslaagd is.

De eerste stap is de eenvoudigste: recordtellingen vergelijken. Staan er evenveel klanten in het nieuwe systeem als in het oude? Evenveel orders, facturen, producten? Een verschil in aantallen is het eerste signaal dat er iets mis is gegaan in het ETL-proces.

Vervolgens checksum-verificatie op kritieke velden. Komen de totaalbedragen van alle facturen overeen? Zijn alle e-mailadressen intact overgekomen? Dit soort checksums vang je fouten mee die bij een simpele telling niet zichtbaar zijn, zoals records die wel zijn overgezet maar met incorrecte waarden.

Daarna volgt validatie op bedrijfslogicaniveau. Kloppen de saldi? Zijn de openstaande orders consistent met de voorraadstanden? Matchen de debiteuren met de factuurhistorie? Dit zijn de controles die een boekhouder of operations manager zou uitvoeren — en dat is precies wie je hierbij betrekt.

Tot slot is er user acceptance testing met echte data. Laat de mensen die dagelijks met het systeem werken controleren of hun klanten, orders en rapportages kloppen. Zij kennen de data beter dan welk geautomatiseerd script dan ook en vinden afwijkingen die geen technische validatie detecteert.

Rollback-strategie

Geen enkele migratie zou mogen starten zonder een duidelijke rollback-strategie. Niet omdat je verwacht dat het misgaat, maar omdat je voorbereid moet zijn op het moment dat het wel misgaat. En bij een voldoende complex systeem gaat er altijd iets mis.

De basis is eenvoudig: houd het oude systeem draaiend gedurende de hele transitieperiode. Niet op een backup-server ergens in een hoek, maar volledig operationeel en bereikbaar. Als de migratie van een module problemen oplevert, schakel je die module terug naar het oude systeem terwijl je het probleem oplost.

Bij een parallelle run moet je ook nadenken over terugschrijven. Als gebruikers al data invoeren in het nieuwe systeem en je moet terugvallen op het oude, moeten die wijzigingen dan worden gesynchroniseerd? Zo ja, dan heb je een bidirectionele sync nodig — wat de complexiteit aanzienlijk verhoogt maar soms onvermijdelijk is.

Definieer vooraf heldere go/no-go criteria. Welk percentage van de records moet succesvol gemigreerd zijn? Welke validatiechecks moeten slagen? Hoeveel uur mag de parallelle run zonder problemen draaien voordat je het oude systeem uitschakelt? Door deze criteria vooraf vast te leggen voorkom je dat de beslissing om door te gaan of terug te draaien wordt genomen onder tijdsdruk of op basis van onderbuikgevoel.

Een migratie zonder rollback-strategie is geen migratie. Het is een gok. En gokken doe je niet met bedrijfskritische data.

Conclusie

Database migraties van legacy naar SaaS zijn geen eenvoudige kopieeractie. Het zijn strategische trajecten die grondig moeten worden voorbereid, gefaseerd uitgevoerd en rigoureus gevalideerd. De combinatie van rommelige brondata, afwijkende datamodellen en de eis van continuiteit maakt elke migratie uniek.

De sleutel tot een succesvolle migratie ligt in drie principes: migreer nooit alles in een keer, valideer elke stap en zorg altijd voor een weg terug. Met een doordacht ETL-proces, gedegen reconciliatie en een waterdichte rollback-strategie transformeer je wat een van de riskantste IT-trajecten is tot een beheerst en voorspelbaar proces.

Sta je voor een datamigratie van een legacy systeem naar een nieuw platform? Wij helpen je met het opzetten van een migratiestrategie die past bij jouw situatie — zonder big bang, zonder dataverlies en zonder slapeloze nachten.