Nieuwe systemen, oude data – tips rond datamigratie voor de projectleider!

Inmiddels is wel duidelijk dat ook IT-systemen verouderen. Niet alleen raakt de technologie uit de tijd en zijn er efficiëntere mogelijkheden voor de operatie en instandhouding (denk aan cloudtechnologie), ook worden er steeds andere eisen gesteld aan de wijze waarop de bedrijfsprocessen worden ondersteund. Het moet en kan veelal sneller, interactiever én geïntegreerd met andere IT-systemen binnen en buiten de organisatie, bij leveranciers en klanten.

Bij gevolg worden er binnen organisaties nieuwe systemen geïmplementeerd. Dit kunnen standaardoplossingen zijn, zoals ERP en CRM, maar ook nieuwe maatwerktoepassingen komen voor. In beide gevallen uitgebreide trajecten waarvoor veelal veel kennis, expertise en doorzettingsvermogen noodzakelijk is.

Een vaak onderschat aspect van de overgang naar een nieuw systeem is dat (veel van) de gegevens in het oude systeem behouden moeten blijven en dus in het nieuwe systeem beschikbaar moeten komen. Geen enkele organisatie wil immers, bijvoorbeeld, een nieuw klantenbestand opbouwen. Datamigratie naar het nieuwe systeem is daarmee onvermijdelijk en de migratie van deze data moet zorgvuldig gebeuren, omdat fouten kosten voor de organisatie en ergernis bij klanten veroorzaken.

Gezien het belang ervan moet aan de datamigratie naar een nieuw systeem veel aandacht worden besteed en moet er op tijd worden begonnen met de voorbereidingen . Op basis van onze ervaring hebben wij wat tips bij elkaar gebracht, in de hoop dat de datamigratie naar het nieuwe systeem niet de bottleneck wordt en dat organisaties snel de waardevolle ‘vruchten’ van het nieuwe systeem kunnen plukken.

Wat moet er eigenlijk (inhoudelijk) gebeuren?
Allereerst moet er natuurlijk gezorgd worden voor ‘transport’ van de data van het oude systeem naar het nieuwe. Technisch zijn hiervoor vele mogelijkheden. Er moet echter wel aandacht worden gegeven aan 1) beveiliging en 2) betrouwbaarheid. De datamigratie moet immers plaatsvinden zonder dat de vertrouwelijke gegevens op straat komen te liggen. Ten tweede moet zeker zijn dat elke datacomponent die uit het oude systeem komt ook daadwerkelijk in het nieuwe systeem terechtkomt; zeker omdat het even kan duren voordat gegevens die zijn achtergebleven daadwerkelijk worden gemist. Betrouwbare techniek, testen en controlemogelijkheden (‘audit trail’) zijn daarom belangrijke componenten in de transportlaag.

Omdat vrijwel zeker het datamodel van het oude systeem verschilt van dat van het nieuwe, zal er ook een ‘translatie’ moeten worden uitgevoerd van het oude naar het nieuwe datamodel. Dat kan relatief eenvoudig zijn, zoals het splitsen van het gegevensveld ‘adresregel’ in de velden ‘straatnaam’, ‘huisnummer’ en ‘toevoeging’. Het komt ook voor dat de gegevens moeten worden aangevuld vanuit een hulptabel, bijvoorbeeld om in het nieuwe systeem ook gegevens als ‘regio’ of ‘provincie’ vast te leggen. De software die wordt ontwikkeld om de translatie uit te voeren is vaak foutgevoelig en verreist daarom een gedegen testproces. Bij het verrijken van data kunnen bijvoorbeeld onterechte aannames (zoals dat er slechts één persoon met initialen + achternaam op een adres woont) leiden tot fouten in de gegevens en datalekken veroorzaken wanneer bijgevolg de verkeerde persoon wordt geadresseerd.

Aanpak
De aanpak van datamigratie heeft veel overeenkomsten met andere IT-realisatieprojecten. Er is een Ontwerp-component waarin zowel technisch als functioneel wordt bedacht hoe de datamigratie vorm dient te krijgen, een Bouw-component waarin de software voor de datamigratie wordt gerealiseerd en een Test-component waarin wordt getest of met de gerealiseerde software daadwerkelijk het doel wordt bereikt. Uiteraard is het mogelijk deze stappen iteratief uit te voeren, zodat snel kan worden vastgesteld dat het gekozen mechanisme werkbaar is. Belangrijk is wel om vast te stellen dat delen van de datamigratie niet zijn te prioriteren: de datamigratie naar het nieuwe systeem moet in zijn geheel gaan slagen! (Het is wel mogelijk om aan de hierna genoemde activiteiten, waaronder ‘archiveren en weggooien’ en ‘kwaliteitsverbetering’, hoge of lage prioriteit toe te kennen.)

Pak het verder aan als een IT-project. Dus deel de activiteiten die in de vorige alinea in grote brokken zijn beschreven op in kleine behapbare werkzaamheden. Maak een detailplanning. Ook visuele ondersteuning van de aanpak en de technische oplossing kan zeer helpen! En houd tijdens de uitvoering de progressie nauwlettend in de gaten en rapporteer periodiek (en vaak) over de voortgang!

Belangrijkst is vooral om op tijd te beginnen. Veel van de werkzaamheden kunnen onafhankelijk van het inrichten van het nieuwe systeem plaatsvinden en derhalve kan een specifiek team (van beperkte omvang) deze werkzaamheden oppakken. Door op tijd te beginnen komen tijdig eventuele issues naar boven die dan ook kunnen worden opgelost voordat de datamigratie een planningsissue wordt. Het is jammer als de ingebruikname van een nieuw systeem, met alle beoogde voordelen, moet wachten op de datamigratie.

Archiveren en weggooien
Veruit de meeste systemen hebben geen functionaliteit om gegevens te archiveren en/of weg te gooien. Eenmaal opgeslagen, blijft data derhalve ‘voor altijd’ in het systeem. Naast dat het opslaan van overbodige gegevens geld en performance kost, betekent het ook dat deze dataopslag mogelijk niet in lijn is met dataretentieregels rond met name persoonsgegevens!

De overgang naar een nieuw systeem is een goed moment om zo veel mogelijk overbodige gegevens NIET over te zetten. Dat klinkt eenvoudiger dan het vaak is; het is een nauwkeurig werkje om precies alle overbodige gegevens, en niet meer, in beeld te krijgen en ervoor te zorgen dat deze gegevens niet worden overgezet. Deze activiteiten lonen echter veelal wel; zoals gezegd leidt dit tot lagere opslagkosten en betere performance en met de tegenwoordig mogelijk omvangrijke boetes is ook compliance met wet- en regelgeving meer dan een ‘nice to have’!

Het spreekt daarbij overigens vanzelf dat bij de selectie van een nieuw systeem het archiveren en weggooien van verouderde gegevens op de requirementslijst wordt geplaatst!

Kwaliteitsverbetering
In vrijwel elke gegevensverzameling komt op den duur vervuiling voor. Dubbele records van klantgegevens, onjuiste gegevens van ‘virtuele klanten’ waarmee nooit een transactie tot stand is gebracht en e-mailadressen die niet meer werken zijn maar enkele voorbeelden van de mogelijke oorzaken van gegevensvervuiling.

Deze gegevensvervuiling neemt men beter niet een-op-een over in het nieuwe systeem. Vandaar dat er veelal een dataschoningsproject (ook wel ‘data cleansing’ genoemd) wordt opgestart. Vaak gebeurt dit naast het datamigratieproject; dat beperkt de afhankelijkheden ook omdat eventueel gevonden verbeteringen (voor migratie) in het oude systeem kunnen worden doorgevoerd (waarna geschoonde gegevens worden gemigreerd).

Het is na ingebruikname van het nieuwe systeem raadzaam regelmatig te controleren op vervuiling en de eventueel gevonden problemen op te lossen en te bezien of er maatregelen genomen kunnen worden (in het nieuwe systeem of de processen) die deze vervuiling in de toekomst kunnen voorkomen!

Roll-back
Hoe goed een migratie ook is voorbereid en getest – er blijft een kleine kans dat de daadwerkelijke migratie naar het nieuwe productiesysteem (óf het nieuwe systeem zelf) faalt. Dat is natuurlijk jammer, maar bij goede voorbereiding hoeft de impact niet meer te zijn dan wat tijdverlies en wat extra werk.

Om de migratie goed te doen, moet vooraf bedacht zijn hoe wordt omgegaan met een mislukte migratie. Dat kan overigens zo simpel zijn als het opnieuw beschikbaar maken van de oude systemen, maar het kan ook complexer zijn, bijvoorbeeld wanneer er data met (keten)partners uitgewisseld wordt die niet langer in het oude systeem wordt bijgehouden. De strategie en werkinstructies voor een dergelijke roll-back zijn daarbij iets om vooraf te oefenen en te testen.

Is de roll-back geslaagd, dan kan daarna enige rust ontstaan om goed uit te zoeken wat er nu misging, zodat de volgende migratiepoging wel slaagt!

Performance
Laat niet te gemakkelijk het excuus ‘de hele database moet gekopieerd worden dus dat duurt lang’ toe. Er zijn goede redenen om de migratie zo vlot mogelijk te laten verlopen. Allereerst, tijdens de migratie moet veelal ‘de winkel dicht’ om te voorkomen dat er dataverlies optreedt. In de 24uurseconomie waar veel organisaties inzitten wil je vanzelfsprekend deze periode zo kort mogelijk houden.

Een vlot lopend proces heeft nog meer voordelen. Zo vereenvoudigt een snel proces het testen, waarbij ook kleine verbeteringen stap voor stap kunnen worden getest. En, hoewel hopelijk onnodig, verkleint een vlot migratieproces de impact van roll-backbeslissingen; een zo kort mogelijk durend migratieproces ondersteunt daarmee juiste besluitvorming.

Testen
Zoals alle IT, moet ook de datamigratie goed getest worden. Hoewel het nieuwe systeem gebruikt kan worden voor deze testen, is het belangrijk dat de datamigratie wordt getest en niet het nieuwe systeem. Het is daarom geen gek idee om bij de datamigratie ook testtools te ontwikkelen waarmee op automatische wijze wordt vastgesteld dat gegevens goed zijn gemigreerd. Controlegegevens, zoals aantallen records in het oude en het nieuwe systeem, horen daarbij!

Belangrijk bij testen is ook dat verwacht mag worden dat in een eerste poging niet alles tot tevredenheid werkt. Er zullen issues zijn die opgelost moeten worden. Een beetje ruimte in de planning om voor het oplossen enige tijd beschikbaar te hebben helpt overmatige druk, en het overwerken in avonden en weekenden, te voorkomen!

Ten slotte
Datamigratie verreist naast kennis van het nieuwe IT-systeem ook kennis van het systeem dat wordt vervangen. Dit moet worden aangevuld met kennis over technologie die tussen deze twee systemen gebruikt kan worden. Het is op zich helemaal niet vreemd dat leveranciers/implementatiepartijen van nieuwe systemen niet op al deze vlakken over de noodzakelijke competenties beschikken.

Bij KPMG is een team ingericht om klanten te ondersteunen bij het op een juiste wijze implementeren van datamigratie en om zo nodig te helpen (technische) problemen op te lossen.