Leer in 8 minuten

  • Waar je vooraf over na moet denken bij een migratie naar de cloud
  • Waarom (data)migratie echt iets anders is dan replicatie
  • Hoe je een migratie naar een nieuwe data-architectuur kunt vereenvoudigen

Je herkent het vast wel: je mobiele telefoon heeft zijn beste tijd wel gehad. Er zitten de nodige krassen op, het scherm is gebarsten en hij werkt steeds langzamer. Gelukkig mag je je abonnement verlengen en een nieuw toestel uitzoeken. Na wat onderzoek koop je het meest uitgebreide nieuwe model van je favoriete leverancier. Maar wat is die nieuwe telefoon waard als je simkaart, apps, adressenboek, wifi-codes en foto’s nog op je oude telefoon staan? Bij het implementeren van een nieuwe data-architectuur is het eigenlijk net zo. Want wat heb je aan die architectuur als je relevante data en functionaliteit niet kunt migreren naar (en integreren in) de nieuwe architectuur?

Alexander van Helm beschrijft in zijn artikel de opbouw van een moderne, flexibele cloud data-architectuur en Michel van Tongeren legt uit hoe je die architectuur in vijf stappen werkelijkheid maakt. In dit artikel – de laatste in deze reeks – geef ik vijf tips om rekening mee te houden bij de migratie van data en functionaliteit van bestaande data warehouses, data marts en datalakes naar een nieuwe cloud data-architectuur.

1. Begin bij de eindgebruiker

Bij het migreren van componenten van de bestaande architectuur naar de nieuwe, is het heel belangrijk om het eindresultaat goed voor ogen te hebben en goed te kijken welke data en functionaliteit eigenlijk nog relevant is. Vergelijk het weer met je nieuwe telefoon. Op je oude mobiel staan veel belangrijke telefoonnummers die absoluut niet verloren mogen gaan, maar in de loop der jaren is je adressenboek ook vol komen te staan met mensen waar je al lang geen contact meer mee hebt.

Begin daarom altijd bij de eindgebruiker van informatie bij het nadenken over de migratie. Deze eindgebruiker kan uiteraard ook een applicatie, of bijvoorbeeld een servicebus zijn. Welke data is nog relevant? Welke data is verouderd of vervuild? Welke business logica is nog actueel en welke is verouderd? Aan welke eisen moet een bepaalde architectuurcomponent voldoen om aan de huidige verwachtingen van de eindgebruikers te voldoen? Veranderingen in de organisatiestructuur of processen binnen de organisatie kunnen grote gevolgen hebben voor de informatievoorziening. Net als nieuwe wet- en regelgeving. Welke eisen stelt de nieuwe AVG bijvoorbeeld aan de data van jouw organisatie?

Je kunt niet vroeg genoeg beginnen met het maken van een goed plan voor de migratie. Beschrijf daarbij de gebruikerswensen SMART. Daarmee leg je immers eenduidig vast wanneer de migratie succesvol afgerond is. Naast het bepalen welke componenten op welke wijze gemigreerd moeten worden naar de nieuwe architectuur, is het belangrijk om in je plan samen met de eindgebruiker te definiëren hoe je de migratie gaat organiseren. Op welke manier wil de eindgebruiker betrokken worden bij de migratie om uiteindelijk goedkeuring te kunnen geven aan het eindresultaat? Migraties waarvan de ‘definition of done’ niet duidelijk is, lopen het risico om vertraging op te lopen of zelfs geheel te mislukken, waardoor de toegevoegde waarde van de nieuwe architectuur veel minder gezien wordt.

2. Migratie is niet hetzelfde als replicatie

Er zijn verschillende methodes om een migratie uit te voeren:

  • Lift & shift: één-op-één alle data en functionaliteit migreren
  • Lift, improve & shift: tijdens het migreren onderdelen verbeteren
  • Re-design, re-architect & consolidate: uitgangspunten opnieuw tegen het licht houden en toetsen aan je principes.

Een ‘lift & shift’ migratie – waarbij data en functionaliteit eigenlijk gewoon gerepliceerd wordt – kost minder inspanning en lijkt een veilige en overzichtelijke manier van migreren. Maar bij zo’n aanpak zal een nieuwe component vaak niet voldoende extra waarde leveren ten opzichte van de benodigde investering. Goedkoop is in de meeste gevallen vaak duurkoop. Bedenk echter wel dat het ook kan voorkomen dat een ‘re-design, re-architect & consolidate’ aanpak te weinig toegevoegde waarde biedt ten opzichte van de investering, namelijk als de huidige en toekomstige situatie behoorlijk vergelijkbaar zijn. Iedere situatie is anders. Maak daarom altijd een bewuste keuze tussen de verschillende methodes.

3. Migratie alleen voegt geen waarde toe

Meer geheugen, een betere chip, een camera met meer pixels, een mooier design… Veel mensen kopen niet opnieuw exact dezelfde telefoon. Ze willen een telefoon die weer up-to-date is en aan de nieuwste standaarden voldoet. Hetzelfde geldt voor migreren naar een nieuwe data-architectuur. Je doet dit over het algemeen niet om een component te vervangen door een component met exact dezelfde specificaties. Er wordt geld geïnvesteerd om een architectuur te realiseren die meer toegevoegde waarde biedt dan de huidige. Waar mogelijk (en nodig) is het daarom aan te raden om minstens voor een ‘lift, improve & shift’ aanpak te kiezen. Zeker bij een migratie van een on-premise situatie naar de cloud is het van belang om kritisch naar bestaande en toekomstige uitgangspunten te kijken om zo de meerwaarde van de nieuwe architectuur optimaal te benutten.

4. Werk samen met de data management afdeling

Jaren geleden was het migreren van je oude mobiele telefoon naar een nieuwe een tijdrovende klus. Telefoonnummers overzetten kon nog wel via de simkaart, maar andere gegevens moest je overtypen of overzetten via een ingewikkelde backup & restore procedure via je PC. Tegenwoordig leveren telefoonproducenten tools waarmee het migreren van je data en instellingen heel eenvoudig is geworden. Kan een migratie naar een nieuwe data-architectuur ook zo makkelijk gemaakt worden?

In een data-architectuur met alleen virtuele componenten hoeft er helemaal geen aandacht besteed te worden aan datamigratie. Data blijft immers in de bronsystemen en wordt nergens in de architectuur gerepliceerd. In de praktijk komt een architectuur met 100% datavirtualisatie echter bijna niet voor. Er zullen meestal componenten in de architectuur aanwezig zijn die zorgen voor replicatie en (fysieke) bewerking van data. Deze componenten maken een datamigratie noodzakelijk. Is handmatig controleren van de datakwaliteit en het maken van eenmalige scripts de enige manier om die data te migreren? Nee, zeker niet. Veel bedrijven hebben al een afdeling die moeite doet om de datakwaliteit binnen de organisatie te bewaken, die ervaring heeft op het gebied van analyse van datakwaliteit en al ervaring heeft met tools voor het meten en verbeteren van datakwaliteit, die nuttig gebruikt kunnen worden bij de datamigratie: de data management afdeling en/of de data stewards. Betrek de expertise en hulpmiddelen van deze afdeling om de migratie efficiënt en effectief te realiseren en testen. Zo sla je namelijk twee vliegen in één klap. De kwaliteit van de migratie wordt verbeterd en kennis die is opgedaan tijdens de migratie gaat niet verloren na de migratie, maar vormt een solide basis voor de data governance afdeling om op voort te bouwen. Kijk samen met data governance experts welke componenten uit de nieuwe architectuur tijdelijk opgeschaald kunnen worden voor migratie van data uit bestaande oplossingen. Op die manier wordt logica hergebruikt die toch al deel uitmaakt van je nieuwe architectuur en dat betekent een behoorlijke reductie van de benodigde inspanning. In cloud architecturen is het vaak relatief eenvoudig om een component tijdelijk op te schalen en na de migratie af te schalen naar de voor dagelijks gebruik benodigde proporties. Als dat niet kan, probeer dan de migratie zoveel mogelijk te automatiseren zodat deze eenvoudig meerdere keren uitgevoerd en getest kan worden (wat in de praktijk vrijwel zeker nodig zal zijn).

5. Automatiseer testen

Er is een activiteit waar meestal veel aandacht voor is tijdens migratieprojecten, maar vaak tijdens het latere gebruik van de gemigreerde componenten behoorlijk onderbelicht blijft. Weet je al waar ik op doel? Inderdaad, op testen. Tijdens migraties wordt er vaak uitgebreid getest op de kwaliteit en volledigheid van de migratie. Hiervoor worden scripts geschreven en testsets gemaakt die helaas na de migratie vaak weggegooid worden. Veel inspanning voor een eenmalige migratie. Is dat niet zonde? Ja, want de testcriteria die tijdens de migratie golden, gelden ook in het dagelijks gebruik van de gemigreerde data en functionaliteit. Componenten in je data-architectuur opnemen die zowel voor de migratie gebruikt worden als voor het monitoren van het dagelijks gebruik, kunnen een waarde hebben die ver boven de benodigde investering uitstijgt.

Tot slot: hou vast aan je (architectuur)principes

Bij het ontwerpen van je nieuwe data-architectuur heb je uitgebreid nagedacht over uitgangspunten en principes waaraan de architectuur moet voldoen. Als je het goed doet, zul jij bij de migratiecomponenten die niet passen in de architectuurvisie uitfaseren of herontwerpen. In de praktijk zie je echter vaak dat migraties niet helemaal succesvol verlopen, waardoor (delen van) deze componenten toch voor langere termijn deel blijven uitmaken van de architectuur. Op zo’n moment is het uitermate belangrijk om je architectuurprincipes te blijven bewaken en direct acties te definiëren om deze oude componenten snel uit te faseren, te herontwerpen óf om de architectuurprincipes aan te passen. De toegevoegde waarde van de nieuwe architectuur betaalt zich alleen uit als alle gedefinieerde acties uitgevoerd worden. Want voor je het weet heb je last van oude problemen in je nieuwe architectuur. Dit is een extra reden om te zorgen voor nieuwe samenwerkingen en duidelijke en relevante documentatie die nodig zijn om architectuur, data governance, datamanagement en compliance te bewaken.

“Hoe zorg jij dat de migratie naar een flexibele cloud architectuur meer wordt dan een één-op-één replicatie zonder toegevoegde waarde?”