Hoe voeren jullie een datamigratie uit?

Allright! We gaan een (legacy) applicatie vervangen voor een moderne No-Code applicatie (goede keuze ?). Gebruikers moeten in de nieuwe applicatie blijven kunnen werken met de data uit de applicatie welke vervangen wordt. Kortom: tijd om data over te pompen!

Voor we gaan kijken naar de HOE, zullen we eerst moeten analyseren WAT er gemigreerd dient te worden. Dit is eigenlijk het belangrijkste onderdeel van de migratie: het ontleden van de te migreren data(base). Afwegingen die daarbij gemaakt moeten worden:

• Moeten we wel migreren? In het geval de dataset niet actief bewerkt wordt, en vooral bewaard moet worden om bijvoorbeeld te voldoen aan wet- en regelgeving, dan kan het interessant zijn om 1 licentie te behouden voor de oude applicatie. De oude applicatie wordt dan een archief dat enkel nog geraadpleegd kan worden.   
• Dient alle data gemigreerd te worden, of kan een subset gemigreerd worden? (bijvoorbeeld enkel de data van de laatste 2 jaar)
• Dienen alle entiteiten en attributen gemigreerd te worden? Welke entiteiten hebben informatiewaarde?
• Dienen bestanden gemigreerd te worden? Zouden die niet beter gemigreerd kunnen worden naar een geoptimaliseerde Blob-opslag in plaats van het opslaan van bestanden in een relationele database?

Deze analyse bepaalt de scope van de datamigratie en is het startpunt van een vervangingsproject.

In de regel zien we bij vervangingsvraagstukken dat circa 80% van de data gemigreerd wordt. Voor iedere entiteit die gemigreerd wordt, zal in de nieuwe applicatie ook functionaliteit moeten worden ontwikkeld. Immers, de data moet minimaal geraadpleegd kunnen worden. Meestal blijft het daar niet bij en dient er ook functionaliteit ontwikkeld te worden voor onder andere het bewerken, verwijderen, beheren, zoeken en exporteren van de data. 

De analyse om de scope vast te stellen van de datamigratie is een enorm leerzaam proces. De ontwikkelaars leren tot op detailniveau de entiteiten kennen die in de nieuwe applicatie ook afgebeeld moeten. Daarnaast leren ze zo het klantdomein snel kennen. Dat helpt enorm bij het opzetten van een robuuste software architectuur, en daarmee een toekomstbestendige nieuwe applicatie.

De projectmanager krijgt vroegtijdig een goed beeld van de daadwerkelijke systeemscope en kan de haalbaarheid van het project valideren (tijd, scope en budget). Is er een gap met de projectscope? Fijn dat die vroegtijdig gesignaleerd is en dat we niet gedurende het project tegen verassingen aanlopen. Nu is er nog mogelijkheid om bij te sturen.

Mogelijkheden
Nu we het eens zijn over de scope en de haalbaarheid van het project hebben gevalideerd, is het tijd om te starten en ons te buigen over de HOE-vraag. Daarvoor hebben we in WEM een aantal opties:

1. Manueel migreren

(Huh? Meen je dat?) In sommige gevallen kan dit de beste optie zijn, bijvoorbeeld bij minimale hoeveelheden data. Het overtypen kan sneller en goedkoper zijn dan het ontwikkelen en testen van migratiefunctionaliteiten. Bijkomende voordeel: gebruikers leren direct werken met de nieuwe applicatie.

1. Export – Import
   Indien de data uit de oude applicatie kan worden geëxporteerd in een gestructureerd gegevensbestand (bijvoorbeeld CSV, XML, JSON), dan kan deze eenvoudig en snel worden geïmporteerd in WEM. Grotere datasets kunnen het beste in batches worden geïmporteerd.
2. API’s
   Met API’s kan de datamigratie grotendeels geautomatiseerd worden uitgevoerd. Handig als je in de ontwikkelfase periodiek de testdata snel wilt verversen. Dit kan bijvoorbeeld door gebruik te maken van Odata, of door het consumeren van REST API’s. Vaak bieden legacy applicaties deze mogelijkheden niet.

1. Database dump
   Indien de tabeldefinitie identiek blijft, is het mogelijk om een database dump te maken van (specifieke tabellen) de oude database, en deze over te zetten naar de nieuwe database. WEM gebruikt een SQL database, dus voorwaarde hiervoor is dat de te vervangen database ook een SQL database is.

Deze opties kunnen in combinatie met elkaar gebruikt worden. Een datamigratie is meestal eenmalig, dus daarbij hanteren we de regel: Keep It Simple. De eenvoudigste oplossing is veelal doeltreffend en de goedkoopste. Meestal komen we dan bij optie 2 (export/import) uit als het beste alternatief.

Goed om te weten: als klant ben je eigenaar van de data. Leveranciers van software zijn verplicht om mee te werken aan het ontsluiten van de data in een gestructureerd formaat.

Migreren
Allright! We weten WAT we gaan migreren, en we weten HOE we gaan migreren. Dan starten we met de realisatie! Daarvoor creëren we een “schaduw datamodel”, waar we de data naar migreren. Dat heeft als voordeel dat we altijd de brondata behouden, ook als de oude applicatie straks niet meer beschikbaar is. Bij het in gebruik nemen van de nieuwe applicatie wordt de gemigreerde data weer bewerkt. Mochten er in de loop van de tijd dan nog inzichten of bugs naar voren komen waardoor gemigreerde data overschreven is, dan kunnen we altijd nog terugkijken en data herstellen. Na verloop van tijd kan dit “schaduw datamodel” opgeruimd worden, aangezien het extra opslag kost in de database. Dit is vergelijkbaar met een upgrade van Windows 10 naar Windows 11, waarbij de Windows 10 back-up kopie op de schijf automatisch na 90 dagen wordt opgeschoond – of eerder mits de gebruiker dat aangeeft.

Als alles in het “schaduw datamodel” zit, kunnen we ervoor zorgen dat de data op de juiste manier landt in het nieuwe datamodel. Hiervoor maken we in WEM migratieflowcharts. In deze flowcharts zetten we de data per entiteit over. Dat kan 1:1 zijn, maar meestal is additionele logica nodig zoals:

1. Vertaalslag van data om de mogelijkheden van het WEM Platform optimaal te benutten. Denk hierbij aan het omzetten van tabellen, naar Ontology lijsten in het WEM Platform.
2. Validaties op datakwaliteit (bijvoorbeeld geldig e-mailadres). Validaties die in de nieuwe applicatie worden getriggerd bij data-invoer, moeten ook gelden voor oude / gemigreerde data.
3. Regels om geautomatiseerd data op te schonen. Over het algemeen geld: Garbage In, Garbage Out. Een datamigratie is een kans om de kwaliteit van je data te verbeteren door het opstellen van kwaliteit regels.
4. Default waardes toekennen. Voor nieuwe functionaliteiten in de nieuwe applicaties worden meestal nieuwe attributen geïntroduceerd. Voor oude / gemigreerde data dienen deze attributen meestal een default waarde te krijgen.
5. Herstellen van relaties tussen entiteiten (foreign key referenties).

Allmost ready! Data gemigreerd, check! Data geland in nieuwe datamodel, check! Klaar?

Bijna… Want we willen graag wel een aantal controles uitvoeren en niet zomaar de aanname doen dat alles de eerste keer goed is gegaan. Dus naast de migratieflowcharts bouwen we een pagina waar we makkelijk kunnen zien of het aantal records wat gemigreerd is overeenkomt met het aantal records in het nieuwe datamodel. Daarnaast houden we de doorlooptijden bij zodat we een draaiboek voor livegang kunnen samenstellen.

Geen afwijkingen? Mooi, dan kunnen we hetzelfde trucje nog een keer uitvoeren bij de livegang. Nu eerst de applicatie verder ontwikkelen en testen met de (gemigreerde) data.

Aanpak
De aanpak zoals hierboven beschreven wekt de indruk dat de nieuwe applicatie al ontwikkeld moet zijn en dat daarna pas de data volledig wordt overgezet. Dat is incorrect. Wij ontwikkelen applicaties via een iteratieve ontwikkelaanpak. Per iteratie zal functionaliteit ontwikkeld worden. Onderdeel van iedere iteratie is het migreren van een gedeelte van de oude applicatie. Wel zo handig met testen! Immers kun je pas representatief testen als je de functionaliteit zowel met oude, als met nieuwe data test. Applicatie volledig gerealiseerd en getest? Dan publiceren we de applicatie naar de live omgeving en voeren we op een afgesproken moment de datamigratie uit. Op dat moment dient de oude applicatie bevroren te worden om te voorkomen dat er tijdens de migratie bewerkingen plaats vinden. Vaak wordt de migratie daarom in een weekend uitgevoerd.

Tipstipstips

• Begin zo snel mogelijk in het project met de datamigratie. Vaak is er een afhankelijkheid van specifieke personen met specifieke kennis, welke niet altijd beschikbaar zijn. Daarnaast kan het ontleden van het oude relationeel model veel tijd kosten. Dus hoe eerder je begint, hoe kleiner de kans dat de projectdeadline in gevaar komt.
• Migreer altijd naar zowel de testomgeving als de liveomgeving. Hiermee creëer je een representatieve testomgeving.
• Bewaar van de gemigreerde data altijd de ID’s van het bronsysteem. Op die manier kun je altijd terug zien welke data wel en niet gemigreerd is.
• Beperk zo veel mogelijk de handmatige acties die nodig zijn om de migratie te laten slagen. Zeker bij het handmatig importeren/exporteren is een foutje snel gemaakt.
• Bij grote, complexe datamigraties raden we aan om het gehele proces op te hakken in losse processen, een rollback scenario in te bouwen om bij een foutmelding niet geheel opnieuw te moeten beginnen, en logging in te bouwen om onder andere de doorlooptijd, afwijkingen en status van de complete migratie te monitoren.
• Testen, testen, testen – en vooral niets onderschatten.