Microsoft 365-migratie: zo verloopt de overstap

Overstappen naar Microsoft 365 klinkt als één handeling — je mail gaat naar een andere server — maar dat is het niet. Wat er in werkelijkheid verhuist, is de hele werkafspraak van je bedrijf: wie bij welke mailbox mag, welke aliassen er bestaan, welke systemen namens jouw domein mail versturen, en waar de agenda’s van je team staan.

Dit artikel beschrijft hoe zo’n overstap in de praktijk verloopt: de vijf fasen, wat er misgaat als je er een fase uit haalt, en wat je als ondernemer zelf moet regelen.

Wat er precies verhuist

Bij een migratie gaan meestal vier dingen mee:

1. Mailboxen. Berichten, mappenstructuur en de volledige historie. Dat is qua volume het grootste deel, maar technisch het eenvoudigste.
2. Agenda’s en contacten. Inclusief terugkerende afspraken en gedeelde agenda’s. Hier ontstaan de meeste kleine verrassingen, omdat mensen ze anders gebruiken dan ze denken.
3. Gedeelde mailboxen, aliassen en rechten. info@, administratie@, de mailbox waar drie mensen bij kunnen. Dit is de categorie die bij vrijwel elk bedrijf onvolledig gedocumenteerd is.
4. De mailstroom van je domein. De dns-records die bepalen waar binnenkomende mail heen gaat en wie namens jouw domein mag versturen: MX, Autodiscover, SPF, DKIM en DMARC.

Bestanden zijn een aparte beslissing. Staan ze nu op een netwerkschijf of in Dropbox, dan is de vraag of ze mee moeten naar SharePoint en OneDrive — en dat is vaker een organisatievraag dan een technische.

De vijf fasen

1. Inventarisatie

Alles wat straks moet werken, moet eerst bekend zijn: mailboxgroottes, aliassen, gedeelde mailboxen, wie waarbij mag, en welke systemen mail versturen namens je domein. Dat laatste wordt het vaakst vergeten: je boekhoudpakket, je webshop en het contactformulier op je website sturen allemaal mail met jouw domeinnaam erin.

Een inventarisatie die niet klopt, kom je pas tegen op het moment dat je hem het minst kunt gebruiken.

2. Pilot

Een kleine groep gaat eerst over — bij voorkeur mensen die verschillend werken: iemand met een enorme mailbox, iemand met veel gedeelde agenda’s, iemand die veel op de telefoon doet. Pas als die groep een paar dagen vlekkeloos draait, volgt de rest.

Een pilot kost een week extra en voorkomt dat je een probleem bij honderd mensen tegelijk ontdekt.

3. Initiële synchronisatie

Het kopiëren van de data gebeurt op de achtergrond, terwijl iedereen gewoon in de oude omgeving doorwerkt. Dit is het deel dat lang duurt en waar niemand iets van merkt.

4. Delta en cutover

Tijdens het kopiëren komt er nieuwe mail binnen. Een delta-synchronisatie haalt precies dat verschil op, vlak voor de overstap. Daarna gaat de mailstroom om: de MX-records wijzen naar de nieuwe omgeving.

Dit is het enige moment waarop het spannend is, en het duurt kort — juist omdat het zware werk al gedaan is. SPF, DKIM en DMARC horen vóór dat moment gecontroleerd te zijn, niet erna: een domein dat na de cutover niet meer door de spamfilters van anderen komt, is een groter probleem dan een trage migratie. Lees ook waarom die records ertoe doen.

5. Nazorg

De eerste dagen na een cutover komen de laatste dingen boven: een telefoon die opnieuw ingesteld moet worden, een gedeelde agenda die iemand nog mist, een verzendend systeem dat over het hoofd is gezien. Daar hoort begeleiding bij, geen ticketnummer.

Waar een migratie in de praktijk op vastloopt

Vier dingen zien we het vaakst:

• Onbekende verzenders. Een systeem dat namens je domein mail verstuurt en dat niemand meer op het netvlies had. Na de cutover komt die mail niet meer aan, of belandt in de spambox van de ontvanger.
• Gedeelde mailboxen zonder eigenaar. Niemand weet precies wie bij info@ hoort te kunnen. De migratie dwingt dat gesprek af — liever vooraf dan halverwege.
• Te grote mailboxen die niemand had gemeten. Een mailbox van tientallen gigabytes kopieert niet binnen een avond.
• Een te korte TTL-planning op dns. Wie de wachttijd van zijn dns-records niet vooraf verlaagt, zit na de cutover uren te wachten tot de wereld de nieuwe MX-records ziet.

Alle vier zijn te voorkomen in fase 1. Geen van de vier is nog te repareren tijdens fase 4.

Wat je zelf moet regelen

Een migratie is geen dienst die je volledig kunt uitbesteden zonder er zelf iets voor te doen. Wat wij nodig hebben:

• Toegang tot je huidige omgeving en tot het dns-beheer van je domein. Zonder dat laatste kan de mailstroom niet om.
• Een besluit over wie welke mailbox krijgt. Dat is een organisatievraag, geen technische.
• Een moment waarop de cutover mag. Meestal buiten kantooruren, soms in een rustige week.
• Ruimte voor je mensen om te wennen. Een dag waarop iedereen zijn telefoon opnieuw instelt, is geen dag waarop iedereen op volle snelheid werkt.

Welke licentie je daarna nodig hebt

Een migratie is eenmalig projectwerk; wat er daarna staat, is een omgeving die beheerd moet worden. Welke licentie daarbij hoort, hangt af van hoe zwaar je op beveiliging wilt inzetten — dat verschil leggen we uit in Business Standard of Premium. Wil je weten waarom meervoudige verificatie daarbij niet optioneel is, lees dan MFA en Conditional Access voor het mkb.

Hoe SEBA Connect hierbij helpt

Wij voeren de migratie uit in precies deze vijf fasen, met de inventarisatie als eerste stap en een migratierapport als laatste. Per batch en per gebruiker is de status zichtbaar in het klantportal; afronding gebeurt op basis van acceptatie, niet op “het zal wel goed zijn”. Details staan op onze pagina over Microsoft 365-migratie, en het beheer daarna op Microsoft 365-beheer.

Wil je weten wat een overstap in jouw situatie betekent, plan dan een adviesgesprek. We kijken eerst naar wat er nu staat.