Datamigratie of dataconversie, is er een verschil?

Datamigratie en dataconversie gebruiken we in de automatisering vaak door elkaar, waarbij het woord migratie aan populariteit lijkt te winnen. Migratie gebruiken we meestal voor het overzetten van complete systemen terwijl een conversie zich veelal beperkt blijft tot het omzetten van data.

Dataconversie

Bij een dataconversie vindt er meestal een omzetting van data plaats zodat we deze data na de conversie in een ander systeem kunnen gebruiken. Daarbij kan het nieuwe datamodel geheel afwijken van het oorspronkelijke datamodel. Tabellen splitsen we of verenigen we dan met andere tabellen. Door het inbrengen van weer andere data uit geheel andere systemen kan verrijking van de data plaatsvinden. Het gewenste resultaat hangt sterk af van de applicatie die met de nieuwe dataset moet gaan werken. Een conversie voeren we meestal uit bij het uitfaseren van een oud informatiesysteem. Dit systeem wordt dan vervangen door een nieuw systeem. Bijvoorbeeld bij het vervangen van on premise business software door een SaaS oplossing in de Cloud. In veel gevallen zal dus ook de onderliggende technologie wijzigen. Bijvoorbeeld door “Platte bestanden” te vervangen door een relationele database.

Datamigratie

Dataconversie is vaak een belangrijk onderdeel van een systeemmigratie. Er zijn velerlei redenen om een systeemmigratie uit te voeren. Denk aan de nieuwbouw van systemen of de keuze voor een andere software oplossing. De aanleidingen hiervoor zijn fusies, overnames, uitbesteden van bedrijfsprocessen en nieuwe marktkansen. Het migreren van data is een samenspel van alle betrokkenen. Niet alleen programmeurs maar ook eindgebruikers, informatie analisten, systeemontwerpers en software-engineers van pakketleveranciers werken samen. Standaard software waaronder SaaS, heeft vaak voorgeprogrammeerde functies waarmee we conversie bestanden kunnen aanmaken of kunnen inlezen.

Regulier onderhoud

De meest voorkomende vorm van datamigratie vloeit voort uit het invoeren van nieuwe software releases. Leveranciers van standaard software (zoals SAP) of systeemsoftware (zoals Oracle) brengen regelmatig nieuwe updates uit van hun software. Deze updates verschillen nogal in complexiteit en omvang en kunnen een enorme impact op het systeem hebben. Daarbij wordt vaak ook de data op een andere manier opgeslagen. Onderdeel van zo’n migratie is dan ook een datamigratie. Op zich zijn dit vervelende migraties. Men wordt min of meer door de leverancier gedwongen om mee te gaan naar de nieuwe versie. Op de oude versie is geen ondersteuning meer of er is een groot beveiligingsrisico. De belasting op de organisatie is groot terwijl het rendement van deze migratie nul is. Immers, na de migratie is er voor de eindgebruiker niets veranderd…

Het enige doel van de migratie is de data foutloos in te lezen in het ontvangende systeem. Meestal dient het overzetten van data foutloos plaatst te vinden. Als er bijvoorbeeld fouten in financiële systemen ontstaan kan dat funest zijn voor de opdrachtgever. Op datamigraties van enige omvang moeten dus doorgewinterde specialisten worden ingezet. Zij zullen deze activiteiten projectmatig uitvoeren.

Fasering van een datamigratie-project

1. Data analyse: het projectteam brengt de situatie in beeld

• Opbouw kennis van het vakgebied.
• Opbouw kennis van bedrijfsprocessen.
• Ontwikkeling van migratie- en datastrategie.
  – Dient de historie van beëindigde contracten ook overgezet te worden?
  – Wordt alles in één keer overgezet, of in meerdere stappen?
  – Kunnen we het uitvalpercentage voorspellen?
  – Welke bedrijfsprocessen draaien er op welk moment? (Op welk moment kan de migratie het beste plaatsvinden?)

2. Technisch ontwerp: het projectteam voert de volgende activiteiten uit:

• Analyse van zowel het bronsysteem als het ontvangende systeem.
• Maken van een technisch ontwerp van ieder conversieprogramma.
• Uitwerken van de teststrategie.
• Alle betrokkenen dienen het ontwerp te beoordelen.

In het ontwerp speelt controle een belangrijke rol. De juistheid van de data moeten we namelijk kunnen laten controleren door auditors en accountants. Een uitgebreide controleraamwerk bestaat uit:

• Voor de traceerbaarheid van alle bewerkingen dient een audit trail in het ontwerp te worden opgenomen.
• Conversieverslagen met controletellingen en check-sums dienen afgedrukt te worden.
• In verband met fraudepreventie dient de conversie in een afgeschermde omgeving plaatst te vinden.

3. Realisatie: In de bouwfase wordt de ontworpen programmatuur gerealiseerd

• Bouw van de conversie programmatuur.
• In de programmatuur worden vaak extra tellingen opgenomen, zogenaamde hash-totals om de consistentie van een dataregel aan te tonen.
• Opstellen van een integraal draaiboek voor de migratie.
• Het testen van de werking met behulp van kleine datasets.
• Het draaien van meerdere proefconversies om de uitkomsten te voorspellen.

4. Uitvoering migratie

Pas als alle testen akkoord zijn bevonden kan de conversie volgens het draaiboek plaatsvinden. Voorafgaand aan de conversie maken we van alle betrokken systemen een integrale back-up. Het ontvangende systeem kan een reeds operationeel systeem zijn waar we een ander systeem aan toevoegen. Dan zijn er grotere risico’s waarvoor we maatregelen moeten nemen. Goedkeuring van de migratie vindt plaats door de opdrachtgever.

Data security tijdens de datamigratie

Als de data het kroonjuweel van de organisatie is of als de privacy in het geding is, is een maximale bescherming noodzakelijk. Aanvullende data security maatregelen kunnen zijn:

• De datamigratie dienen we op een onafhankelijk systeem uit te voeren.
• Daarop mogen we alleen de systeemsoftware en de conversieprogrammatuur installeren.
• Versleuteling van de data tijdens de conversie kan een vereiste zijn.
• Screening van medewerkers, verklaring omtrent het gedrag.
• Contractuele afspraken met de uitvoerenden.

Knelpunten en valkuilen bij datamigratie

• Migraties van en naar de cloud of tussen cloudoplossingen onderling zijn vaak lastig. Dat komt omdat de cloud een blackbox is voor de gebruiker en niet alle cloudaanbieders open staan voor een conversie.
• Migratie en conversie zijn meestal een onderdeel van een groter project. Het migratieplan zullen we in die gevallen moeten integreren in het projectplan.
• Het komt voor dat de (financiële) administraties niet meer op elkaar aansluiten na de migratie. Deze aansluitingen moeten we dus herstellen.
• In de planning moeten we tijd reserveren voor het schonen van de bestaande data. In het lange bestaan van het oude systeem kan vervuiling zijn opgetreden. Velden die plotseling een ander doel kregen, of gebruikers die steevast de verkeerde waarden invoerden. Data schoning kan een project op zich zijn.
• In de planning moeten we ook tijd reserveren voor het ontdubbelen van gegevens, dit kost namelijk vaak meer tijd dan verwacht.
• Daarnaast moeten we tijd reserveren voor het alsnog invoeren van conversie uitval. In de praktijk blijkt namelijk dat niet alle data te converteren is. Deze moeten we dan achteraf handmatig invoeren.
• Als het ontvangende systeem een andere datastructuur heeft zullen niet alle velden met de migratie worden gevuld. De lege velden moeten een default waarde krijgen zodat het ontvangende systeem kan werken.
• Speciale aandacht is vereist als de technologieën waarop de datasets gebaseerd zijn van elkaar verschillen. Bijvoorbeeld van EBCDIC naar ASCII tekenset of de waarde ‘null’ in een database, of de vastlegging van financiële bedragen met of zonder punten en komma’s.
• Het aanbrengen van wijzigingen in de oude dataset moet worden vermeden. Zodoende blijft herhaalbaarheid van de migratie namelijk mogelijk.

Discussieer mee op LinkedIn.