Datamigratie #1: Het opzetten van een Datamigratie-plan

Een datamigratie is een proces wat uiteenvalt in verschillende stappen. Soms zijn extra stappen nodig maar de volgende stappen zie je eigenlijk altijd wel terug:

• Extract: Extractie van data uit bron-applicatie
• Transform: Transformatie van data naar doel-formaat
• Load: Laden van data in de doel-applicatie

Datamigratie is een erg belangrijk proces welke goed begeleid moet worden en welke veel controle(s) nodig heeft. Een datamigratie is altijd een afgebakend geheel, waarbij data overgaat vanuit de bron naar het doel. Dit kan gaan om alle data uit de bron of slechts een deel.

 
Doordat ik zelf verschillende migraties heb meegemaakt ben ik op een rijtje gaan zetten hoe deze verliepen en welke activiteiten ik heb uitgevoerd om de migratie tot een succes te maken. Grofweg zie je 4 fases die variëren in lengte, naar gelang de hoeveelheid en complexiteit van het project. Ik heb migraties van 2 maanden begeleid, maar ook van 1,5 jaar.

Opzetten Datamigratie-Plan
Opzetten migratiestraat
Uitvoeren proefmigraties
Uitvoeren werkelijke migratie
 
Voor ieder van deze stappen zal ik handvatten geven in deze en de volgende twee blogs om zo tot een compleet beeld te komen omtrent het opzetten en uitvoeren van een datamigratie.

HET OPZETTEN VAN EEN DATAMIGRATIE-PLAN

Hoe zorg je dat je goed voorbereid bent voor de migratie? De volgende vragen helpen bij het voorbereiden van een migratie. De antwoorden op de vragen geven een helder plan en duidelijkheid over wat er moet gebeuren op hoog niveau.

WAT MOET WORDEN GEMIGREERD?

Een project begint met het concreet maken van wat er bereikt moet worden tijdens het project. In geval van datamigratie is er is een behoefte om data van A naar B over te brengen. Wees specifiek over welke data dat het gaat en waarom een migratie plaatsvindt. Bijvoorbeeld alle data moet over, want we willen af van licentiekosten voor applicatie x.

Probeer de brok te migreren data zo klein mogelijk te houden en niet meer data te migreren dan nodig, want meer data maakt het geheel complexer! Het kan bijvoorbeeld zijn dat bepaalde data niet meer nodig is in een nieuw systeem, zoals bijvoorbeeld historische data welke nooit geschoond is.

Uiteindelijk levert deze vraag de scope van de migratie op.

WAT ZIJN DE RISICO’S VOOR DE MIGRATIE?

Bij migratie loop je altijd risico. Dat de migratie uitgevoerd moet worden is al een feit, maar welke risico’s moeten worden afgedekt in tijdens de migratie? Hoe ga je deze afdekken? Ga je bepaalde risico’s verwaarlozen? Onder andere deze vragen moeten worden beantwoord.

Risico’s zijn niet alleen volledig falen van de migratie, maar bijvoorbeeld ook mogelijke onjuistheden welke in de data kunnen voorkomen na migratie of afwijkingen in data doordat in de transformatie keuzes gemaakt worden en wat voor gevolgen dit kan hebben voor een rapportageketen.

Beschrijf de onderkende risico’s en evt hoe je verwacht deze op te vangen, danwel of ze voor lief genomen moeten worden. Bedenk ook dat de data vaak in een keten zit en mogelijk later in externe rapportages komt, welke geen impact van de migratie mogen hebben.

Bedenk ook terugval-scenario’s welke je gaat gebruiken als de migraties niet sluitend/succesvol zijn. Kan en mag je een roll-back doen? Loop je extra risico vanwege beperkingen in de licenties van bron-applicaties? Alle grote risico’s en mogelijke oplossingen moeten de revue passeren en besproken worden. Kijk hierbij goed naar de kans van optreden en wat te doen als het voorkomt.

Een paar voorbeelden:

indien de migratie niet succesvol is hebben we een maand nodig voor verbeteringen waarna poging 2 wordt gedaan. Hier zitten dan de volgende kosten aan verbonden…
Als de nieuwe applicatie na migratie niet met de migratiedata kan werken, dan moet worden teruggevallen op het oude systeem.
We verliezen een detailniveau in de data welke invloed heeft op de rapportages naar buiten. Dit kunnen we niet voorkomen. In overleg met de rapportage-afdeling gaan we deze wijziging aankondigen.
Hiermee heb je beschreven welke risico’s je hebt bij grote calamiteiten en wat je dan moet doen om het op te lossen.

HOE GAAN WE MIGREREN?

Nadat je weet wat je wilt migreren en welke risico’s je loopt is het goed om te kijken hoe je wilt migreren. De keuze heeft veel te maken met risico’s welke je loopt. Migreren van data gebeurt op 2 manieren. ‘Big Bang’ of 2 of meer ‘Waves’. Vaak wordt gekozen voor in één keer alle data, oftewel “big bang”. Dit wordt gezien als de snelste methode. Migreren in meerdere waves heeft echter ook sterke voordelen.

In 1 keer om (Big Bang) lijkt altijd het makkelijkste en snelste. Iets om echter rekening mee te houden is dat de hele migratiestraat 100% af moet zijn om dit voor elkaar te krijgen. Gaat dat wel lukken? Is er voldoende controle op de data? Zijn alle mensen op het juiste moment beschikbaar? Wil je meer gefaseerd werken (Agile) is dit misschien ook niet de beste keuze.

Big Bang zorgt ervoor dat alle risico’s welke je loopt met de migratie op 1 moment samen komen. Vaak is er ook sprake van een alles of niets scenario. Alle data komt goed aan, of de migratie wordt teruggedraaid. Na dit moment ben je dus volledig over naar de doel-applicatie, of niet.

Meerdere waves is de andere mogelijkheid. Dit geeft je tussentijds extra controle en niet alle data loopt meteen een risico. Vaak werkt dit goed omdat de data in categorieën kan worden ingedeeld. Wat handig is van meerdere waves is ook dat het iteratief werken extra ondersteunt. Je kunt je team(s) richten op het scenario wat nu moet worden gemigreerd, vaak beginnend met het makkelijkste en door naar steeds complexere scenario’s. Hoe de split te maken kan complex zijn, maar in overleg met de business- en de migratie-specialisten kan er een keus worden gemaakt waar iedereen mee uit de voeten kan.

Als je migreert in waves, dan beperk je de risico’s welke je tijdens migratie loopt. Slechts een deel van de data loopt risico, niet het geheel. Slechts beperkte complexiteit is per migratiemoment van belang. Tot de laatste wave moet je echter wel rekening houden met het feit dat je 2 applicaties moet ondersteunen, namelijk bron- en doel-applicatie. Medewerkers moeten weten waar de data die ze zoeken staat of in beide systemen gaan zoeken. Zeker als het data betreft welke tot aan het moment van migratie kan veranderen is dit een belangrijke afweging.

Uiteindelijk krijg je een afgewogen beslissing omtrent het hoe te migreren op basis van de risico’s welke onderkend zijn voor de datamigratie.

HOE CONTROLEER JE DAT ER GEEN DATA VERLOREN GAAT?

Een van de grootste risico’s welke je loopt bij datamigratie is verlies van data. Verlies van data kan al snel leiden tot een onbetrouwbaarheid in het systeem en/of terug moeten vallen naar het oude systeem. Het kan hier gaan om een verlies objecten, maar ook een detaillering welke wegvalt. Dus van 1000 objecten komen er 999 door of een lijst van 10 opties wordt ingedikt naar 5 opties. Hoe weet je zeker dat er geen data verloren is gegaan?

Deze vragen hebben betrekking op de kwaliteit van het op te zetten systeem. Hoe controleer je dat data goed door komt en wat voor controles ga je uitvoeren om dit te controleren? Probeer de stappen van de migratie te volgen en meetmomenten op te zetten na iedere stap. Dit geeft controle op iedere stap in het proces. Weet wat erin gaat en controleer of dat nog steeds aanwezig is op het einde van een stap. De controle kan grof middels kengetallen of erg gedetailleerd middels hashes per object o.i.d. schematisch ziet dit er als volgt uit:

Ieder van de stappen kan verschillen opleveren welke nader bekeken moeten worden. Houdt rekening met het feit dat als je verschillen ziet in de export-controle dat deze doorwerken in de transformeer-laag en bij de doelapplicatie. Verschillen kunnen worden veroorzaakt omdat waardes niet goed zijn doorgekomen (niet naar verwachting) of omdat er uitval optreedt.

De plek waar normaliter de meeste issues zullen optreden is de transformeer-laag, maar ook bij het maken van de export en het inlezen in de doel-applicatie kunnen er verschillen ontstaan.

In alle gevallen is het goed om naast de kengetallen ook individuele objecten te bekijken. Dit is wat omslachtig om voor alles te doen (gezien dit vaak gaat om duizenden of miljoenen objecten) maar een steekproef met wat specifieke scenario’s kan geen kwaad.

Enkele voorbeelden van controles welke uit te voeren zijn tijdens een controle:

Controleer totale waarde van de portefeuille
Controleer de gemiddelde rente na migratie
Controleer per lening of de som van de lening-delen overeenkomt
Controleer het aantal lening-delen van type x.
Let op: Deze stap gaat om het opzetten van wanneer je wat gaat controleren. Nog niet alle controles hoeven hier uitgewerkt te zijn!

Deze vraag heeft ons een controlemodel opgeleverd welke we kunnen toepassen op de verschillende stappen in het migratieproces.

WAT GEBEURT ER ALS DATA UITVALT?

Bij een migratie kan het gebeuren, ook al willen we dat natuurlijk niet, dat er data uitvalt. Dit kan komen doordat de import niet geslaagd is, vanwege onvoorziene omstandigheden. Wanneer dit gebeurt moet er wel een plan zijn omtrent wat te doen om de data toch door te kunnen zetten.

In geval van uitval zal een object niet verwerkt zijn. Meestal kun je uitval vinden in speciale tabellen/uitvallijsten of logging van de stap. Als dit niet zo is dan kan er mogelijk handmatig bepaald worden wat er uitgevallen is door twee lijsten met elkaar te vergelijken. Bijvoorbeeld: is hypotheek A ook doorgekomen in de transformeer-laag en ingelezen in de doel-applicatie? Afhankelijk van hoe de stappen zijn opgebouwd kan dit eenvoudig of heel lastig zijn.

Zorg bovendien dat er beschreven is wat er moet gebeuren als er data uitvalt. Ga je deze handmatig verwerken? Gaat deze mee in een tweede wave? Kan er iets stuk zijn omdat samenhang niet meer klopt? Deze laatste kan bijvoorbeeld gebeuren als een object uit 2 delen bestaat en 1 deel uitvalt, terwijl de andere goed door kwam. Mogelijk is er ook een limiet op hoeveel data uit mag vallen voor het kritiek wordt.

Het resultaat is een overzicht waarin staat wat te doen als er issues optreden tijdens de migratie.

TOT SLOT

Er staat nu een eerste plan. Mogelijkerwijs moet deze nog aangescherpt worden naarmate het project loopt, maar de basis staat en dit geeft duidelijkheid aan team(s) en aan de business.

Wil je meer weten? Over 2 weken komt er een vervolg blog: opzetten migratiestraat.