Cloudmigratie en gegevensmigratie: verhuizen zonder dat je data onderweg problemen veroorzaakt

Een cloudmigratie lijkt op papier eenvoudig.

Je hebt een lokale server met bestanden. Je kiest een cloudplatform. Je kopieert de bestanden. Je schakelt de oude server uit. Klaar.

In de praktijk is vooral de gegevensmigratie een stuk complexer.

Bestandsnamen kunnen niet voldoen aan de regels van het nieuwe platform. Folderstructuren kunnen te lang zijn. Medewerkers blijven ondertussen werken. Bestanden veranderen tijdens de migratie. Een migratieproces kan worden onderbroken. En een succesvolle kopie betekent nog niet automatisch dat alle bedrijfsdata ook bruikbaar is in de nieuwe omgeving.

Ik heb dat zelf ervaren bij een migratie van ongeveer 200 GB aan bedrijfsdata vanaf een Mac Mini naar Microsoft SharePoint Online. Die ervaring bevestigde voor mij een eenvoudig uitgangspunt:

Een gegevensmigratie is vooral een voorbereidings- en controleproces. Het kopiëren van de bestanden is slechts één onderdeel.

Waarom een cloudmigratie meer is dan bestanden kopiëren

Cloudopslag kan voor kleine bedrijven een praktische oplossing zijn.

Medewerkers kunnen vanaf verschillende locaties toegang krijgen tot bedrijfsdata. Een lokale fileserver hoeft niet langer de centrale plaats te zijn waar alle bestanden beschikbaar moeten blijven. Voor startende ondernemingen kan dat betekenen dat er minder lokale infrastructuur nodig is.

Ook bestaande bedrijven kunnen hun traditionele fileserver vervangen door bijvoorbeeld SharePoint Online.

Daarbij verandert echter meer dan alleen de opslaglocatie.

Een fileserver bepaalt jarenlang hoe gebruikers bestanden en folders organiseren. Die structuur groeit meestal geleidelijk. Nieuwe folders worden toegevoegd, bestanden worden verplaatst en medewerkers ontwikkelen hun eigen werkwijze.

Na enkele jaren kan zo’n omgeving duizenden bestanden en honderden folders bevatten.

Microsoft 365 legt technische voorwaarden op aan bestanden en paden. Microsoft ondersteunt momenteel bestanden tot 250 GB voor file share-migraties naar Microsoft 365. Het pad in SharePoint en OneDrive is na migratie beperkt tot 400 tekens.

Daarom begint een goede migratie met een andere vraag:

Is de bestaande data geschikt voor de nieuwe omgeving?

Mijn ervaring met een migratie van 200 GB naar SharePoint Online

In mijn situatie ging het om een Mac Mini waarop ongeveer 200 GB aan bedrijfsdata stond.

De doelomgeving was Microsoft SharePoint Online.

De uitgangssituatie had vier belangrijke kenmerken:

• de bestaande folder- en bestandsnaamgeving voldeed niet volledig aan de vereisten van Microsoft;
• medewerkers moesten tijdens de migratie kunnen blijven werken;
• bestanden konden daardoor tijdens het migratieproces wijzigen;
• na de migratie moest de bestaande server kunnen verdwijnen.

Dat laatste heeft gevolgen voor de migratieaanpak.

Stel dat een migratie drie dagen duurt. Een medewerker wijzigt op dag twee een bestaand document. Dan moet je weten welke versie uiteindelijk in SharePoint terechtkomt.

Een eenmalige kopie is in zo’n situatie onvoldoende.

Welke problemen moet je vóór de migratie vinden?

Voor je een migratietool start, moet je weten wat je eigenlijk gaat migreren.

Dat betekent onder meer:

• hoeveel data is er?
• hoeveel bestanden zijn er?
• hoeveel folders zijn er?
• welke bestanden worden nog gebruikt?
• welke data is verouderd?
• bestaan er dubbele bestanden?
• zijn er bestanden die niet naar de nieuwe omgeving mogen?
• zijn bestandsnamen compatibel?
• zijn folderstructuren compatibel?
• zijn bestandspaden niet te lang?
• welke toegangsrechten bestaan er?

Microsoft beschrijft voor zijn migratietools een vergelijkbare aanpak: eerst analyseren en voorbereiden, daarna migreren en vervolgens de resultaten controleren. SPMT ondersteunt daarbij zowel scanning en assessment als het uitvoeren en opvolgen van migratietaken.

Die voorbereiding voorkomt dat problemen pas zichtbaar worden nadat de data al naar de cloud is verplaatst.

Bestandsnamen zijn een onderschat probleem

Een van de problemen die ik tijdens mijn migratie tegenkwam, was de naamgeving.

Door jarenlang gebruik waren bestands- en foldernamen ontstaan die niet geschikt waren voor SharePoint.

Bij een kleine dataset kun je zulke problemen misschien handmatig oplossen. Bij duizenden bestanden wordt dat al snel onwerkbaar.

Automatisatie is dan noodzakelijk.

In mijn migratie gebruikte ik Transnomino op macOS. Daarmee kon ik bestands- en foldernamen volgens een Windows Compatibility-profiel aanpassen en vooraf controleren welke wijzigingen zouden worden uitgevoerd.

Mijn eerste poging gebruikte een Regular Expression om verboden tekens door een koppelteken te vervangen. Dat loste een deel van het probleem op. Andere naamgevingsproblemen bleven echter bestaan.

Het resultaat was dat OneDrive tijdens een eerdere kopie nog steeds uploadconflicten rapporteerde.

De praktische les was duidelijk:

Controleer de volledige naamgeving volgens de regels van het doelplatform.

Een eenvoudige zoek-en-vervangactie is daarvoor niet altijd voldoende.

Kies ook de juiste bestemming voor je data

Een cloudmigratie is een goed moment om te bepalen waar verschillende soorten informatie thuishoren.

Bedrijfsdata die door meerdere medewerkers wordt gebruikt, kan bijvoorbeeld in een gedeelde SharePoint-documentbibliotheek thuishoren. Persoonlijke werkbestanden kunnen in OneDrive worden geplaatst.

Microsoft adviseert bij file share-migraties vooraf te bepalen welke inhoud persoonlijk is en welke inhoud voor samenwerking bedoeld is.

Dat voorkomt dat een oude fileserverstructuur simpelweg wordt gekopieerd naar een nieuwe omgeving.

Een fileserverstructuur die twintig jaar geleden logisch was, hoeft vandaag geen goede structuur voor SharePoint te zijn.

Een cloudmigratie is daarom ook een geschikt moment om verouderde informatie te verwijderen of te archiveren en de resterende data opnieuw te organiseren.

Kies de migratietool op basis van de bron

Microsoft biedt verschillende mogelijkheden voor het migreren van file shares naar Microsoft 365.

De SharePoint Migration Tool, SPMT, is een gratis Microsoft-tool voor het migreren van onder meer lokale en netwerkshares naar SharePoint, OneDrive en Teams.

Microsoft biedt daarnaast Migration Manager voor file share-migraties. Migration Manager gebruikt agents die op een computer of virtuele machine worden geïnstalleerd. Vanuit de SharePoint Admin Center-omgeving kun je vervolgens migratietaken aanmaken, opvolgen en rapporteren.

Voor mijn oorspronkelijke Apple-omgeving ontstond daardoor een praktisch probleem.

De huidige Microsoft-migratietools zijn Windows-gebaseerd. De actuele vereisten voor SPMT noemen Windows 10 of later en Windows Server 2016 of later. Microsoft adviseert voor goede prestaties onder meer 16 GB RAM, 150 GB vrije lokale opslag en een netwerkinterface van 1 Gbps.

De vraag is daarom niet alleen welke migratietool je gebruikt.

Je moet ook bepalen:

Op welk systeem draait de migratietool en hoe krijgt die toegang tot de brondata?

In een Apple-omgeving kan een tijdelijke Windows 11-machine bijvoorbeeld via SMB toegang krijgen tot de bestaande fileserver.

Migration Manager gebruikt voor file shares eveneens SMB 2.0 of hoger als vereiste aan de bron.

Een migratie is geen momentopname

Dit is een van de aspecten die bij cloudmigraties vaak te weinig aandacht krijgen.

Stel dat je maandag start met 200 GB data.

Dinsdag werken medewerkers verder.

Een bestaand bestand wordt aangepast.

Woensdag wordt een nieuwe folder aangemaakt.

Donderdag worden nieuwe documenten toegevoegd.

Als je vrijdag alleen opnieuw de oorspronkelijke dataset kopieert, moet je kunnen bepalen welke bestanden sinds de vorige migratieronde zijn gewijzigd.

Daarom is incrementele migratie belangrijk.

Microsoft ondersteunt bij SPMT het opnieuw uitvoeren van een migratietaak waarbij nieuwe of gewijzigde bestanden worden verwerkt. Ook Migration Manager voert incrementele migraties uit.

Bij een file share gebruikt SPMT onder meer het bestandspad om te bepalen of bestanden opnieuw moeten worden verwerkt. Microsoft waarschuwt bovendien dat je gemigreerde bestanden tijdens het migratieproces beter niet hernoemt of verplaatst, omdat dit tot overschrijvingen kan leiden.

Daarmee wordt een belangrijk principe duidelijk:

De migratie moet rekening houden met de periode waarin de brondata nog verandert.

Mijn eerste poging liep tegen de praktijk aan

Tijdens mijn eigen migratie werd het proces onderbroken door powersaving en een macOS-update.

Bij het hervatten ontstond een probleem waarbij bij twee pogingen alleen bestanden werden overgenomen en de folderstructuur niet correct werd meegenomen.

Dat is precies het soort probleem dat je in een testomgeving wilt ontdekken.

Een migratieproces is afhankelijk van meer dan de migratiesoftware.

Ook de computer waarop de migratie draait speelt een rol. Denk aan:

• slaapstand en stroombeheer;
• netwerkverbindingen;
• geplande updates;
• beschikbare lokale opslag;
• toegang tot de brondata;
• stabiliteit van de bronserver.

Een migratie van honderden gigabytes kan uren of langer duren. De migratiemachine moet daarom gedurende het volledige proces beschikbaar en stabiel zijn.

Test eerst met een beperkte dataset

Een volledige fileserver meteen migreren brengt onnodig risico met zich mee.

Begin met een beperkte dataset.

Controleer daarbij:

• worden alle bestanden overgezet?
• blijft de folderstructuur correct?
• zijn bestandsnamen aangepast waar nodig?
• werken bestanden na de migratie?
• zijn de toegangsrechten correct?
• kunnen gebruikers de bestanden terugvinden?
• werkt de gekozen synchronisatie en toegang zoals verwacht?

Pas wanneer deze test goed verloopt, heeft het zin om de volledige dataset te migreren.

In mijn eigen situatie gebruikte ik FreeFileSync op macOS om bron en bestemming met elkaar te vergelijken. Daarmee kon ik zichtbaar maken welke bestanden en folders moesten worden overgezet.

De eindgebruikers zijn onderdeel van de migratie

Techniek bepaalt slechts een deel van het resultaat.

Medewerkers moeten weten waar hun bestanden na de migratie staan. Ze moeten begrijpen welke informatie naar SharePoint gaat en welke informatie bijvoorbeeld in OneDrive thuishoort.

Ook hun dagelijkse werkwijze kan veranderen.

Een lokale fileserver wordt vaak gebruikt via een bekende folderstructuur. SharePoint introduceert andere concepten, zoals sites, documentbibliotheken, rechten en gedeelde toegang.

Daarom hoort gebruikerscommunicatie bij de migratie.

Een technisch correcte migratie kan voor gebruikers alsnog problematisch zijn wanneer zij hun bestanden niet kunnen terugvinden of niet begrijpen hoe ze ermee moeten werken.

Migreren is ook architectuur

Hier zie ik een belangrijk verschil tussen een technische gegevensoverdracht en een infrastructuurmigratie.

Een Systems Engineer kan ervoor zorgen dat bestanden worden overgezet.

Een Infrastructure Architect moet daarnaast nadenken over de reden van de migratie, de manier waarop medewerkers met de data werken, de gewenste structuur, toegangsrechten, beveiliging, continuïteit en toekomstige beheerlast.

Dat sluit aan bij mijn visie op de rol van Infrastructure Architect.

Technologie moet aansluiten op bedrijfsprocessen, continuïteit, beveiliging en kosten.

Voor een Belgische KMO is die bredere beslissing vaak relevanter dan de keuze tussen twee migratietools.

De technologie is een middel.

De bedrijfsdata moet tijdens en na de migratie bruikbaar blijven.

Mijn aanpak voor een gecontroleerde cloudmigratie

Op basis van mijn ervaring zou ik een file share-migratie in deze volgorde aanpakken.

1. Inventariseer

Breng de omvang van de data, het aantal bestanden en folders, bestandstypes, gebruikers en toegangsrechten in kaart.

2. Analyseer

Zoek naar verouderde data, dubbele bestanden, ongeldige namen, te lange paden en andere incompatibiliteiten.

3. Bepaal de doelstructuur

Beslis welke data naar SharePoint gaat, welke data in OneDrive thuishoort en welke informatie verwijderd of gearchiveerd kan worden.

4. Remedieer

Los problemen met bestandsnamen, folderstructuren en andere beperkingen op voordat je de productiegegevens migreert.

5. Test

Migreer een beperkte dataset. Controleer bestanden, folderstructuur, rechten en gebruikerservaring.

6. Voer een eerste volledige migratie uit

Verplaats de volledige dataset naar de doelomgeving.

7. Synchroniseer wijzigingen

Voer incrementele migraties uit zolang gebruikers nog op de oude omgeving werken. SPMT en Migration Manager ondersteunen hiervoor incrementele migratie.

8. Plan de omschakeling

Kies een moment waarop gebruikers tijdelijk niet meer op de oude locatie werken. Voer een laatste synchronisatie uit.

9. Valideer

Controleer de doelomgeving voordat je de oude server uitschakelt.

Controleer daarbij minimaal de aanwezigheid van bestanden, de folderstructuur, toegang tot de data en de werking voor de eindgebruikers.

10. Schakel de oude omgeving pas daarna uit

De oude fileserver blijft beschikbaar totdat je voldoende zekerheid hebt dat de migratie correct is uitgevoerd.

Cloudmigratie begint vóór de cloud

De interessantste les uit mijn eigen migratie was uiteindelijk niet welke tool ik moest gebruiken.

Het was het besef dat de migratie al begint voordat er één bestand wordt gekopieerd.

Een bedrijf dat 200 GB data naar SharePoint wil verplaatsen, heeft in werkelijkheid een informatieomgeving die gedurende jaren is gegroeid. Die omgeving moet eerst worden begrepen.

Daarna komen naamgeving, structuur, rechten, migratietooling, synchronisatie, gebruikers en validatie.

Microsoft beschrijft voor file share-migraties dezelfde hoofdlijn: voorbereiding en analyse, migratie en controle.

Dat is voor mij de kern van een goede cloudmigratie.

Je migreert geen bestanden. Je migreert een bedrijfsproces dat afhankelijk is van die bestanden.

Voor een KMO kan een cloudmigratie daardoor een technisch project lijken, terwijl belangrijke beslissingen gaan over bedrijfscontinuïteit, toegang tot informatie, beveiliging, beheer en toekomstige groei.

Een goede voorbereiding maakt het verschil tussen een kopieeractie en een gecontroleerde migratie.