Van fileserver naar SharePoint: 10 architecturale lessen uit een migratie
Een fileserver vervangen door Microsoft SharePoint lijkt op papier eenvoudig.
Je hebt een lokale server met folders en bestanden. Je richt SharePoint in, kopieert de data en schakelt de server uit.
In de praktijk begint de echte migratie vaak pas nadat je de eerste bestanden probeert over te zetten.
Ik heb dat zelf ervaren bij een migratie van een lokale Mac Mini naar Microsoft SharePoint. Het ging om ongeveer 200 GB aan gegevens. De bestaande folderstructuur moest behouden blijven, medewerkers moesten tijdens de migratie kunnen blijven werken en de oude server moest na afloop verdwijnen.
Die ervaring leverde mij een aantal architecturale lessen op die breder toepasbaar zijn dan deze ene migratie.
1. Een fileserver migreren is geen kopieeropdracht
De eerste fout die je gemakkelijk maakt, is de migratie bekijken als een datatransfer.
Bron:
\\server\gegevens
Doel:
SharePoint > Documenten
Kopiëren en klaar.
Zo werkt het zelden.
Microsoft beschrijft een fileshare-migratie vandaag als een proces met verschillende fasen: planning, assessment en remediation, voorbereiding van de doelomgeving, migratie en onboarding van gebruikers.
Dat sluit ook aan bij mijn eigen ervaring.
De data zelf was maar één onderdeel van het probleem. De bestaande naamgeving, folderstructuur, wijzigingen tijdens de migratie en de manier waarop gebruikers toegang zouden krijgen, waren minstens even belangrijk.
Een goede migratie begint daarom met een architectuurvraag:
Waarom bestaat deze fileserverstructuur zoals ze vandaag bestaat, en moet die structuur in SharePoint blijven bestaan?
Dat is een veel interessantere vraag dan: “Hoe krijgen we 200 GB naar SharePoint?”
2. De bestaande folderstructuur is vaak onderdeel van het probleem
Een lokale fileserver kan jarenlang meegroeien.
Een medewerker maakt een folder. Een andere medewerker maakt daar een subfolder in. Daarna ontstaat ergens een nieuwe folder met een vergelijkbare naam.
Na enkele jaren krijg je bijvoorbeeld:
Administratie > Klanten > 2024 > Projecten > Lopende projecten > Klant X > Documentatie
Op een klassieke fileserver kan dat jarenlang blijven functioneren.
Bij een migratie naar SharePoint wordt de structuur opnieuw zichtbaar als architectuurkeuze.
SharePoint Online heeft een limiet van 400 tekens voor het volledige gedecodeerde bestandspad, inclusief folders en bestandsnaam.
Een diepe folderstructuur kan daardoor rechtstreeks migratieproblemen veroorzaken.
Mijn les hieruit:
Gebruik een migratie als gelegenheid om de informatiestructuur opnieuw te bekijken.
Niet ieder bestaand folderniveau heeft nog een functionele reden.
3. Bestandsnamen zijn technische afhankelijkheden
Dit was één van de meest concrete problemen tijdens mijn migratie.
De bestaande omgeving bevatte bestanden en folders die in de loop der jaren waren ontstaan met naamgeving die niet compatibel was met Microsoft-opslag.
Er kwamen onder andere verboden tekens voor, maar ook situaties waarbij een punt of spatie op een problematische positie in een naam stond.
Dat lijkt een detail.
Totdat je duizenden bestanden probeert te migreren.
Microsoft documenteert specifieke beperkingen voor bestandsnamen en paden in SharePoint en OneDrive. De huidige migratietools kunnen bepaalde ongeldige tekens vervangen of bestanden met dergelijke namen overslaan.
Daarom hoort data remediation vóór de eigenlijke migratie te gebeuren.
Niet tijdens.
Niet nadat de gebruikers problemen melden.
Voor mij betekent dat concreet:
- Inventariseer bestanden en folders.
- Detecteer ongeldige namen.
- Detecteer te lange paden.
- Bepaal welke namen moeten veranderen.
- Controleer de gevolgen voor gebruikers en applicaties.
- Pas daarna start de eigenlijke migratie.
Tijdens mijn eigen voorbereiding gebruikte ik daarvoor onder andere een hulpmiddel om bestandsnamen automatisch volgens Windows-compatibiliteitsregels aan te passen.
Het belangrijkste inzicht is echter niet de tool.
Het is het principe:
Bestandsnaamgeving is onderdeel van je infrastructuurarchitectuur.
4. Migreren terwijl gebruikers blijven werken vraagt om synchronisatie
Een migratie van 200 GB gebeurt zelden in één beweging.
Terwijl de data naar SharePoint wordt gekopieerd, blijven gebruikers werken op de oorspronkelijke fileserver.
Bestanden veranderen.
Nieuwe bestanden worden aangemaakt.
Bestaande bestanden worden verwijderd.
Daarom heb je een mechanisme nodig om de wijzigingen tussen bron en doel bij te houden.
Dat was ook een expliciete vereiste in mijn eigen migratie: medewerkers moesten tijdens het proces toegang blijven houden tot de lokale data.
Een eerste kopie is dus slechts een baseline.
Daarna volgt een incrementele synchronisatie en uiteindelijk een gecontroleerde cut-over.
Microsoft ondersteunt dit principe in zijn migratietools. Bij een incrementele controle worden onder andere gewijzigde bronbestanden opnieuw beoordeeld.
Dat leidt tot een belangrijk architecturaal principe:
Plan de migratie als een proces met meerdere synchronisatiemomenten, niet als één grote kopieeractie.
5. De keuze van de migratietool wordt bepaald door de bron
In mijn oorspronkelijke omgeving zat een extra probleem.
De fileserver draaide op een oude versie van macOS. De beschikbare Microsoft-tooling sloot daar niet rechtstreeks op aan.
Ik probeerde daarom een tussenoplossing waarbij een andere Mac via SMB toegang kreeg tot de brondata en een synchronisatietool gebruikte.
Dat werkte gedeeltelijk, maar introduceerde nieuwe risico’s.
Een onderbreking door energiebesparing of een update kon het proces verstoren. Bij een hervatting ontstond zelfs een situatie waarbij bestanden werden overgenomen zonder de volledige folderstructuur correct mee te nemen.
Dat was voor mij een duidelijke architectuurles:
Kies de migratietool op basis van bron, doel, platform en migratiegedrag.
Microsoft biedt vandaag de SharePoint Migration Tool voor onder andere fileshares. De tool ondersteunt scan, assessment, migratietaken en rapportering.
Voor grotere of meer gecentraliseerde fileshare-migraties biedt Microsoft daarnaast Migration Manager.
Een tool die technisch bestanden kan kopiëren, is daarmee nog niet automatisch de juiste migratieoplossing.
6. Een tussenserver kan soms een architecturale keuze zijn
Bij een heterogene omgeving kan een tijdelijke Windows-machine een praktische rol spelen.
Dat klinkt misschien vreemd wanneer het doel juist is om een lokale fileserver uit te faseren.
Toch kan een tijdelijke migratieomgeving nuttig zijn wanneer de bronomgeving verouderd is of wanneer de beschikbare migratietooling bepaalde platformen niet ondersteunt.
Microsofts huidige SharePoint Migration Tool ondersteunt fileshares als bron en is bedoeld om bestanden naar SharePoint, OneDrive of Teams te migreren.
De tijdelijke machine wordt dan geen onderdeel van de eindarchitectuur.
Ze is een migratiecomponent.
Dat onderscheid vind ik belangrijk.
Niet elke server die je tijdens een migratie gebruikt, hoort uiteindelijk in de productieomgeving thuis.
7. De bestemming moet vóór de data worden ontworpen
Een andere belangrijke les is dat je eerst de SharePoint-doelomgeving moet ontwerpen.
Waar komt de data terecht?
Welke SharePoint-site?
Welke documentbibliotheek?
Welke gebruikers krijgen toegang?
Welke groepen krijgen welke rechten?
Welke data hoort bij welke afdeling of bedrijfsfunctie?
Hoe worden externe gebruikers behandeld?
Welke gegevens moeten eventueel apart worden beheerd?
Dat zijn architectuurvragen.
Een fileserver gebruikt vaak folders en NTFS-rechten als primair organisatiemodel. SharePoint biedt daarnaast sites, documentbibliotheken, metadata, groepen, deelmogelijkheden en andere samenwerkingsfuncties.
Een 1-op-1-kopie van een fileserverstructuur naar SharePoint kan technisch werken en toch een slechte eindarchitectuur opleveren.
De migratie is daarom een geschikt moment om opnieuw naar informatie, eigenaarschap en toegang te kijken.
8. De cut-over is een bedrijfsbeslissing
Technisch gezien kan de migratie klaar zijn terwijl het bedrijf nog niet klaar is om over te schakelen.
Dat verschil wordt vaak onderschat.
Voor de cut-over wil ik minimaal weten:
- Is alle data gemigreerd?
- Zijn de migratierapporten gecontroleerd?
- Zijn fouten onderzocht?
- Zijn de belangrijkste bestanden steekproefsgewijs gevalideerd?
- Werken de gebruikersrechten?
- Kunnen gebruikers hun documenten terugvinden?
- Werken Office-bestanden correct?
- Zijn eventuele koppelingen naar oude UNC-paden aangepast?
- Is duidelijk wanneer de oude server alleen nog als fallback beschikbaar is?
- Is er een afgesproken moment waarop de oude omgeving definitief wordt uitgefaseerd?
De brondata moet bovendien niet zomaar worden aangepast tijdens een lopende incrementele migratie. Microsoft waarschuwt bijvoorbeeld dat het hernoemen of verplaatsen van gemigreerde bestanden vóór de finale migratie kan leiden tot overschrijvingen.
De cut-over is dus geen technische knop.
Het is een bedrijfsbeslissing met een technisch uitvoeringsplan.
9. De grootste architecturale fout is migreren zonder op te ruimen
Een migratie biedt een unieke kans.
Je moet immers toch door de data heen.
Dat maakt het interessant om vooraf vragen te stellen zoals:
Welke data wordt nog gebruikt?
Welke data is verouderd?
Welke folders hebben geen duidelijke eigenaar?
Welke documenten zijn duplicaten?
Welke structuur is ontstaan door historische omstandigheden?
Welke data hoort eigenlijk helemaal niet in dezelfde bibliotheek?
Ik zou daarom een migratie nooit uitsluitend beoordelen op het aantal gigabytes dat succesvol werd overgezet.
Een succesvolle migratie betekent dat de organisatie na de migratie beter met haar informatie kan werken.
Dat is een veel relevanter criterium.
10. De rol van de Infrastructure Architect verandert tijdens een migratie
Dit soort projecten toont ook waarom infrastructuurarchitectuur verder gaat dan technische kennis.
Een goede Infrastructure Architect moet begrijpen hoe systemen, bedrijfsprocessen, documentatie, gebruikers en technologie samenhangen.
Bij een fileservermigratie betekent dat bijvoorbeeld dat je tegelijk moet nadenken over:
- technische compatibiliteit;
- datakwaliteit;
- security;
- toegangsbeheer;
- bedrijfscontinuïteit;
- gebruikersgedrag;
- migratietooling;
- kosten;
- toekomstige beheerlast.
Automatisering speelt daarin een belangrijke rol. Mijn eigen ervaring met het opschonen van bestandsnamen bevestigde dat handmatig duizenden bestanden en folders controleren geen realistische strategie is.
Een architectuur die afhankelijk is van duizenden handmatige controles is meestal een architectuur die nog onvoldoende is voorbereid.
Mijn belangrijkste lessen
Een fileserver naar SharePoint migreren heeft mij vooral geleerd dat de moeilijkste problemen zelden bij de cloud zelf zitten.
Ze zitten in de bestaande omgeving.
In oude naamgevingsconventies.
In te diepe folderstructuren.
In data waarvan niemand meer weet waarom ze bestaat.
In gebruikers die tijdens de migratie blijven werken.
In tooling die niet past bij de bronomgeving.
En vooral in het ontbreken van een duidelijk ontwerp voor de omgeving ná de migratie.
Microsoft beschrijft planning, assessment, remediation, migratie en onboarding vandaag ook als afzonderlijke onderdelen van een geslaagde fileshare-migratie.
Dat bevestigt wat ik uit de praktijk heb geleerd:
Een cloudmigratie is in de eerste plaats een architectuurproject. De datatransfer is slechts één onderdeel ervan.
Wie alleen vraagt hoe hij 200 GB naar SharePoint krijgt, stelt eigenlijk de laatste vraag eerst.
De eerste vraag is:
Hoe moet onze informatieomgeving eruitzien wanneer de fileserver verdwenen is?
Ik ben een Systems Integrator en Infrastructure Architect met meer dan 28 jaar professionele ervaring. Mijn mening is mijn eigen mening en de visie van Peritus Consult, niet de mening van mijn werkgever Lab9 Pro.
