WhatsApp Facebook Twitter LinkedIn Mail

Datamigratie

Inhoudsopgave

  1. Wat is datamigratie?
  2. Fases van ETL
    1. Extract-fase
    2. Transform-fase
    3. Load-fase
  3. Wie doet de datamigratie en met welke tools?
  4. Soort migratie afhankelijk van bron- en doelsystemen
  5. Veelvoorkomende problemen bij een migratie

Waaruit bestaat datamigratie?

Datamigratie is het proces waarbij data van het ene systeem naar het andere worden overgezet. De redenen voor deze migratie zijn divers: verandering van software, een update van de database, de installatie van een nieuw datawarehouse, etc. Door data elektronisch te migreren, zorgen bedrijven ervoor dat de overgang naar het nieuwe systeem vlot verloopt. Ze hoeven de data uit oude systemen niet handmatig over te zetten. Dit levert veel tijdwinst op. Bovendien is de kans dat data zoekraken kleiner.

Volgens een studie van Gartner uit 2020 gaat er in 83% van de datamigraties iets mis, of lopen deze vertraging op.

Uit welke fases bestaat het ETL-model?

Bij een datamigratie moeten de gegevens een ETL-proces doorlopen (Extract, Transform and Load). Bij ETL worden de data eerst geëxtraheerd vanuit de originele bron. Daarna worden ze gecontroleerd en getransformeerd in een formaat dat vlot kan worden geüpload in het nieuwe systeem.

datamigratie overzetten gegevens protocol etl

Extract

De data (zowel gestructureerde als ongestructureerde) worden uit de bronsystemen gehaald. Deze data kunnen komen uit: databases, juridische systemen, cloud-omgevingen, lokaal geïnstalleerde software en servers, datawarehouses, analytische systemen (bijvoorbeeld BI-systemen), etc.

Transform

De transformatiefase zorgt ervoor dat de gegevens correct, precies, compleet en betrouwbaar zijn. Dubbele, onvolledige, incorrecte of gemanipuleerde data worden eruit gefilterd en eventueel gecorrigeerd. Daarna wordt ervoor gezorgd dat de data compatibel zijn met het nieuwe systeem. Transformatie bestaat uit de volgende subprocessen:

  • Schoonmaak van de data: anomalieën, incoherente data en ontbrekende waarden worden geïdentificeerd en gecorrigeerd.
  • Standaardisering van de data: de gegevens krijgen allemaal dezelfde vorm. Dit gebeurt door het toepassen van normen. Deze normen kunnen wettelijk vastgelegd zijn, zoals het Toepassingsprofiel Metadatering Lokale Overheden, maar ook door het eigen bedrijf opgesteld worden. Een van de meest voorkomende vormen om data te standaardiseren is door de dragers te formatteren.
  • Elimineren van duplicaten: dubbele gegevens worden geïdentificeerd en de doublures worden verwijderd.
  • Classificatie van de data volgens de categorieën die het bedrijf heeft bepaald.
  • Andere subprocessen: eventueel moeten er nog extra subprocessen plaatsvinden, zoals een aanpassing van de dataschema’s (bijvoorbeeld herverdelen van kolommen), het linken van verschillende bronnen, etc.

Load

Het uploaden van de data in het nieuwe systeem is de laatste stap in het ETL-proces. De data kunnen op twee manieren worden geüpload:

    • Full load: bij deze methode worden alle data tegelijkertijd geüpload in het nieuwe systeem. Het nadeel hierbij is dat, zodra er een foutje in de upload sluipt, dit vaak een kettingreactie veroorzaakt. Eén verkeerd getransformeerd gegeven kan er namelijk voor zorgen dat alle daaraan gelinkte data ook verkeerd worden geladen. Daarom is het erg belangrijk om vooraf proeven te doen. Deze proeven kunnen in een testomgeving gedaan worden, ook wel gekend als sandbox. Er kan ook voor worden gekozen om kleine uploads als proef te doen in het nieuwe systeem, om zo het gedrag van de data en het proces na te gaan.

      De full-load-methode wordt meestal gebruikt door bedrijven die een Big Bang migration uitvoeren. Bij dit migratiemodel worden alle data overgezet binnen een vooraf vastgelegde tijdspanne en op een vooraf bepaald moment. Door de hele migratie strikt te plannen, kan de migratietijd erg beperkt worden. Het nadeel is dat het bedrijf de data en gerelateerde systemen tijdens de hele upload-periode niet kan gebruiken.

    • Incremental load: bij deze methode worden data in kleine hoeveelheden geüpload in het nieuwe systeem. Om doublures te voorkomen, worden de data telkens vergeleken met de data die al beschikbaar zijn in het nieuwe systeem. Deze methode is veiliger, want er is minder kans op een kettingreactie aan fouten. Het nadeel van deze methode is dat ze langer duurt.

      De incremental-load-methode wordt meestal gebruikt bij bedrijven die een Trickle migration uitvoeren. Bij deze methode worden de data per fase geüpload in het nieuwe systeem. Werknemers blijven parallel nog het oude systeem gebruiken. Hierdoor wordt de downtime van het bedrijf gelimiteerd, maar duurt het hele proces wel langer. De fasering moet bij dit soort migratie heel goed gestructureerd worden, anders zou het wel eens kunnen gebeuren dat een bepaalde ‘batch’ van data tussen de mazen van het net door glipt.

Hulpmiddelen en verantwoordelijken voor datamigratie

Alle fases van het ETL-proces kunnen handmatig door werknemers van het eigen bedrijf worden uitgevoerd, maar organisaties kunnen zich hierbij ook laten helpen. In de eerste plaats bestaan er softwaretools voor ETL. Deze applicaties worden aangeboden door de leveranciers van onder andere, ERP, CRM, DMS, HRM en QMS-software.

Een tweede mogelijkheid is dat de leverancier het ETL-proces voor zijn rekening neemt. In zo’n geval is het belangrijk dat er binnen de organisatie een persoon is, vaak de CIO, die de leverancier uitlegt hoe de migratie moet verlopen. Deze persoon moet ook controleren of:

      • de datacategorieën die het bedrijf heeft vastgelegd gerespecteerd worden;
      • en dat de leverancier geen enkele configuratie overslaat, bijvoorbeeld een klantenprofiel. Bij migraties komt het namelijk vaak voor dat de originele registratiedatum van gegevens verloren gaat, en dat daarvoor in de plaats de datum van de migratie verschijnt.

data geschiedenis migratie valkuilen

Tussen welke systemen kunnen data migreren?

Afhankelijk van de systemen waartussen data zich moeten bewegen, zal de migratie bepaalde eigenschappen hebben. De mogelijkheden zijn:

      • Storage migration: bij deze migratie worden data van het ene opslagmiddel naar het andere overgezet. Dit kan gaan over hardware van het eigen bedrijf (hard disk, USB-stick, lokale server etc.) of cloud-omgevingen. In de meeste gevallen moeten de opslagplaatsen eerst geformatteerd worden, voordat er kan worden overgegaan tot een migratie.
      • Database migration: bij deze migratie worden data overgezet van de ene database naar de andere. Dit kan nodig zijn wanneer een bedrijf verandert van databaseleverancier (bijvoorbeeld van MySQL van Oracle naar SAP HANA), of wanneer de software van het databasesysteem geüpdatet wordt. Bij dit proces is het belangrijk dat een bedrijf extra aandacht besteed aan het transformeren van de originele data. Als deze transformatie niet volledig correct verloopt, zal de nieuwe database of de geüpdate versie het formaat van de data niet erkennen.
        Let op: bij de keuze voor een databasesysteem moeten bedrijven niet over één nacht ijs gaan. Veel databasesystemen structureren de data op een vergelijkbare manier. Toch heeft elke database enkele unieke kenmerken. In de ERP Wijzer vindt u een vergelijking tussen verschillende databasesystemen.
      • Application migration: bij deze migratie worden data gemigreerd tussen applicaties (bijvoorbeeld van SAP Business One naar Microsoft Dynamics 365). Bij een verandering van applicaties van verschillende leveranciers zal er altijd een migratie moeten plaatsvinden. Als het om een nieuwe applicatie van dezelfde leverancier gaat, is dit niet altijd nodig. Alleen als het datamodel van de nieuwe applicatie anders is, moet er ook bij applicaties van dezelfde leverancier een migratie worden uitgevoerd. Een bedrijf dat van SAP R/3 (SAP Business All-in-One) verandert naar SAP S/4 HANA zal bijvoorbeeld een migratie moeten uitvoeren, want SAP heeft zijn datamodel volledig veranderd.
      • Business Process Management migration: bij deze migratie worden data uit bedrijfsprocessen overgezet. Het is de ingewikkeldste migratievorm, want ze bestaat uit het migreren van gegevens tussen systemen die onderling erg verschillen. Dit kan bijvoorbeeld het geval zijn bij een migratie van een desktop-applicatie naar een database, of van een database naar een software die lokaal geïnstalleerd is. Dit is vaak nodig in het geval van fuserende bedrijven, die tot dan toe verschillende systemen gebruikten. Over het algemeen wordt deze migratie uitgevoerd met behulp van BPM-hulpmiddelen.

Welke problemen duiken het vaakst op bij datamigratie?

Bij datamigratie denken veel mensen aan eenvoudig ‘knip-en-plakwerk’. Door deze onderschatting duiken er wel eens problemen op. De meest voorkomende fouten zijn de volgende:

    1. Geen back-ups maken van alle data die gemigreerd zullen worden: voordat er met een datamigratie begonnen wordt is het erg belangrijk dat een bedrijf een back-up maakt van de betreffende data. Als dit niet gebeurt, en er gaat iets mis bij de migratie, gaan deze data verloren. Er kan een menselijke fout gemaakt worden, maar ook zaken die het bedrijf niet in de hand heeft, kunnen ervoor zorgen dat data verloren raken. Denk hierbij aan een uitval van de elektriciteit of de internetverbinding.
    2. Zich er niet van vergewissen dat de data voldoen aan de voorwaarden van het nieuwe systeem: bij het overzetten van data moet er eerst en vooral gecontroleerd worden of het formaat van de data compatibel is met het nieuwe systeem. Als het om hetzelfde datamodel gaat (vaak bij dezelfde leverancier), is het niet nodig een ETL-proces te doorlopen. In dit geval is het voldoende een vereenvoudigd protocol te volgen, het FTP (File Transfer Protocol). Als de datamodellen echter verschillend zijn, moeten wél alle stappen van het ETL-proces minutieus worden opgevolgd.
    3. Geen rekening houden met de downtime: bij een implementatie zal er bijna altijd een tijdspanne zijn waarin geen van beide systemen beschikbaar is. Tijdens deze downtime kunnen er namelijk geen gegevens worden opgeslagen. De duur van deze downtime hangt af van de hoeveelheid data die er moeten worden gemigreerd, en de complexiteit van de datatransformatie. Als er bij de migratie bovendien een cloudsysteem komt kijken (als bron- of doelsysteem), is ook de internetsnelheid een bepalende factor.

      Bijvoorbeeld: in een bedrijf neemt de migratie van e-mails van de ene cloudserver naar de andere twee uur in beslag. Maar, als het gehele intranet van het bedrijf gemigreerd moet worden naar een andere server, dan kan de downtime oplopen tot 48 uur. Veel bedrijven kiezen ervoor om grote migraties in het weekend te laten plaatsvinden, wanneer er minder of niet gewerkt wordt. Dit geldt natuurlijk niet voor alle migraties. Een bedrijf met een webshop zal liever op werkdagen migreren (eventueel ‘s nachts), omdat klanten in het weekend juist veel aankopen doen.

    4. Geen tests uitvoeren in het nieuwe systeem voordat het oude wordt verwijderd: voordat een oud systeem (met de originele data) verwijderd wordt, moet er worden nagegaan of alle data daadwerkelijk zijn overgezet, en of ze bruikbaar zijn in het nieuwe systeem. Controleer hierbij of ze kunnen worden geopend en (indien nodig) bewerkt. Om dit snel te controleren kan het volgende trucje worden toegepast: zoek het jongste en oudste gegeven in het nieuwe systeem en probeer deze te openen en/of bewerken. Als deze data aanwezig zijn, en ze kunnen worden gebruikt, dan is dit normaal gesproken ook het geval voor alle data ertussenin. Controleer ook zeker data van verschillende categorieën. Zo weet u dat elke categorie correct geconverteerd is. Als het doelsysteem een groot systeem is, kunnen er bovendien vaak geautomatiseerde proeven worden gedaan.

Dit artikel als bron gebruiken? Klik en kopieer:

European Knowledge Center for Information Technology. (2024, 14 maart). Datamigratie. ICT Portal. https://www.ictportal.nl/ict-lexicon/datamigratie