Blog

Datamigratie - hoe complex is het?

Datamigratie - hoe complex is het?

Wanneer je met je website wil overstappen naar een nieuw platform, komen daar een hoop zaken bij kijken. Niet alleen een nieuw design, nieuwe user-flows en nieuwe functionaliteiten, maar ook de datamigratie. Het liefst wil je met één druk op de knop alles migreren. Maar omdat de nieuwe website en je bestaande database waarschijnlijk niet exact hetzelfde zijn opgebouwd, gaat dat niet zo eenvoudig.

Weet iedereen binnen je organisatie die bij je nieuwe platform betrokken is, wat datamigratie is? En hoe dit proces werkt? Waarschijnlijk niet. Dit blogartikel heb ik geschreven voor accountmanagers, product owners, scrum masters, communicatiemedewerkers, klantenservicemedewerkers, designers, marketeers, of beter gezegd: alle niet-developers. Ik geef graag meer inzicht in wat er allemaal bij komt kijken, waarom het tijd kost en waarom er vooraf goed over nagedacht moet worden. Meer leren over datamigreren? Lees dan mee! 
 

Wat is data migratie?

Een logische start van dit artikel is een korte uitleg: Datamigratie is de basis van het verplaatsen van data van het oude platform naar het nieuwe platform. Data kan van alles zijn. Bijvoorbeeld usernames en bijbehorende wachtwoorden en content zoals nieuwsartikelen, pagina’s met tekst, afbeeldingen; you name it. Maar data is niet: koppelingen met systemen of code van de oude website.

Wat komt er allemaal kijken bij datamigratie?

Om goed te begrijpen hoe datamigratie werkt, moet je eerst weten waar alle data wordt opgeslagen en hoe dit er ongeveer uitziet. Nu ga ik even een open deur intrappen: data wordt opgeslagen in een database. Dat heb je ongetwijfeld weleens gehoord. Je kunt een database ook wel zien als een soort Excelbestand of Google spreadsheet. Een bestand met meerdere tabbladen, waarin rijen en kolommen staan. In de kolommen staat de content. Per tabblad kan content ook naar elkaar verwijzen.
 

Alle content wordt in de ‘spreadsheet’ opgeslagen en verandert met iedere aanpassing in de website. Er worden bijvoorbeeld nieuwe nieuwsartikelen toegevoegd, afbeeldingen worden vervangen, nieuwe klanten melden zich aan, wachtwoorden worden aangepast. Afhankelijk van hoe groot je website is, is er sprake van meer data en zo mogelijk nog véél meer wijzigingen.

Wanneer je een nieuwe site laat ontwikkelen, heeft dat als gevolg dat er een nieuwe database nodig is met een nieuw datamodel. Je krijgt dus een nieuwe ‘spreadsheet’. Deze heeft een andere structuur dan je huidige site. Het aantal rijen, kolommen en tabbladen wordt helemaal anders. Niet alle data van je oude site, wil je meenemen naar de nieuwe site. Alleen wat daadwerkelijk nodig is. Vaak wordt dit moment ook gebruikt om data op te schonen. En er komt natuurlijk ook een hoop nieuwe content bij. Als je een nieuwe website ontwikkelt, moet er dus opnieuw gekeken worden naar de datastructuur. Een nieuwe website op een bestaande database bouwen raden wij af. Vaak zijn er in het verleden keuzes gemaakt voor de opzet van de database die niet meer aansluiten bij de nieuwe indeling of doelstellingen van de website.. Net zoals de structuur van je website verandert, verandert daarmee ook de datastructuur.

Hoeveel werk is jouw (automatische) migratie?

De hoeveelheid werk en de complexiteit bij jouw migratie is dus geheel afhankelijk van data, de benodigde nieuwe structuur en de hoeveelheid content en wijzigingen. Je weet vooraf nooit precies hoe de nieuwe datastructuur eruit gaat zien. Het is meestal een flinke puzzel, waarbij beoordeeld moet worden welke content van de oude website overgezet moet worden naar de nieuwe database en in welke nieuwe rijen en kolommen van je databasestructuur het geplaatst moet worden. Het is daarom vooraf vaak lastig inschatten hoeveel werk er bij jouw migratie komt kijken. Twee databases die volledig van elkaar verschillen, kan een complex proces inhouden.

Naast het opzetten van de nieuwe structuur en beoordeling van de content, zijn er ook nog de zogenoemde ‘business rules’ die van invloed zijn op de complexiteit van het traject. Omdat ook die geheel anders kunnen zijn bij een nieuwe website. 
 

Om ‘verandering in business rules’ toe te lichten, gebruik ik graag een voorbeeld: het postcode veld. Die kan voorheen ‘open’ zijn geweest, dan zaten geen validaties op en kon een gebruiker op de websites van alles in dit veld invullen. Als er voor de nieuwe website wordt gekozen om hier wel een validatie op te zetten, verandert dus de business rule. De invoer moet nu voldoen aan 4 cijfers en 2 letters. Maar wat doe je met data die niet voldoet aan de business rules? Of als je data mist? Hoe meer incorrecte data je hebt, des te lastiger het wordt. Handmatig werk is dan niet te voorkomen. 

Als alle data en business rules in kaart zijn gebracht (oud versus nieuw) wordt er, bij automatische datamigratie, een script geschreven. Het script gaat kijken naar de oude database en zet content over naar de nieuwe. Er is hierbij nog een belangrijke kanttekening: het migreren van data is een iteratief proces. Je kan niet handmatig voor 100.000 gebruikers controleren of alle data goed overgezet kan worden en of de data aan alle nieuwe business rules voldoet. Hier kom je pas achter, als het script stopt vanwege bepaalde errors. Voor de migratie daadwerkelijk start is dit in vaak in grote lijnen al wel inzichtelijk, maar de uitzonderlijke gevallen kom je tegen wanneer het script stopt. Wanneer een script stopt door errors, moet er onderzocht worden waarom het script stopt. Het script dient erop aangepast te worden. Daarna laten we het nieuwe script opnieuw lopen. 
 

Wat kost een datamigratie?

Het antwoord op die vraag is vooraf lastig te beantwoorden. Daar kun je pas aan het einde van al het voorbereidende werk op een migratie een inschatting voor afgeven. Het varieert uiteraard bij uiteenlopende projecten, maar wij hebben ervaring met migraties tussen de 30 en 90 uur. 

Data migratie is in veel gevallen het begin van een mooie samenwerking!

Een goed voorbeeld van een langdurige samenwerking is Fuentes.