Je hoort het maar al te vaak: “Als ik het mocht overdoen…” of “Als ik dat eerder had geweten…”.
Dit geldt zeker voor datamigraties. Dit is voor veel organisaties meestal een eenmalige activiteit. En juist als je iets voor het eerst doet, dan stap je in die valkuilen en maak je -maar al te begrijpelijk- ‘beginnersfouten’.
Wat zijn de belangrijkste valkuilen van een datamigratie?
- “De data kwaliteit valt buiten de scope”
Verreweg de belangrijkste valkuil is het negeren van de data kwaliteit. Als issues zich pas voordoen tijdens de acceptatietesten in het nieuwe systeem, of nog erger: als je al in productie bent, dan kost het onnodig veel tijd en geld om dit op te lossen (als het überhaupt te herstellen is). Data kwaliteit moet je binnen scope houden! En als je toch alles door de vingers krijgt, dan is dat toch hét moment om er iets mee te doen?!
- “De conversieprogrammatuur moeten we later nog wel wat versnellen”
Hier gaat het ook vaak fout. Vaak hoor je dat het converteren van een klein setje gegevens soms al enkele uren duurt. Een slechte performance van conversieprogrammatuur is niet alleen een risico voor de definitieve conversie. Hoeveel dagen ligt de business stil? Het zit je ook in de weg tijdens de ontwikkeling van je conversieprogrammatuur. Je wilt in staat zijn om meerdere malen per dag de conversieprogrammatuur te kunnen testen. Achterliggende oorzaak is vaak dat de programmatuur ‘record-gebaseerd’ (bijvoorbeeld op basis van triggers) wordt gebouwd en dat dit achteraf niet voldoende getuned kan worden.
- “We maken een ‘golden copy’ van de brondata”
De basisaanpak van de migratie zou moeten zijn: het extraheren van de gegevens uit het bronsysteem, het converteren van deze gegevens op basis van de conversieprogrammatuur en vervolgens het inlezen in het nieuwe systeem. En dit als herhaalbaar en controleerbaar proces. Toch zie je soms helaas de ‘strategie’ om eenmalig een ‘golden copy’ te maken en deze up-to-date te houden gedurende het gehele migratietraject, zodat deze uiteindelijk de basis voor het nieuwe systeem vormt. Tijdrovend en nagenoeg onmogelijk om dit ‘in sync’ te houden. Niet doen dus.
- “Kijk maar hoe je de brondata aanlevert”
Voor de ontwikkelaars van de conversiestraat is het cruciaal om te weten hoe de brongegevens exact worden aangeleverd. Krijgen we mutaties of alles? Is het formaat fixed of gescheiden door speciale karakters? Zitten er headers in de bestanden? Met welke frequentie krijgen we verse data? Is gegarandeerd dat we bij een nieuwe levering de gegevens in exact hetzelfde formaat krijgen? Als op dit soort antwoorden geen helder antwoord bestaat, dan weet je zeker dat je hier -op z’n zachtst gezegd- een uitdaging hebt. Onduidelijke afspraken over inhoud en formaat van dataleveringen brengt altijd een hoop ellende met zich mee. Heldere afspraken maken dus. Beter nog: eenduidig specificeren wat, hoe, wanneer, waar en door wie gegevens worden geleverd.
- “Het is nog niet duidelijk wie de conversie straks goedkeurt”
Een van de eerste stappen van het migratietraject is het vaststellen van de acceptanten en acceptatiecriteria. Wie keurt de conversie goed? En op basis waarvan? En hoe kan je tijdens het hele migratietraject je bewijsvoering opbouwen en valideren? Het ontwikkelen en testen van de controles is net zo belangrijk als de conversieprogrammatuur zelf. Vaak blijkt in de eindfase dat een migratie niet gefundeerd te accepteren valt en wordt toch maar in productie gegaan. Tsja, wat moet je anders?!
Mocht je met een datamigratie aan de slag gaan: Succes! Maar pas op! Je zal niet de eerste zijn…