Microsoft 365-migratie zonder downtime

De situatie

Microsoft 365 was er al sinds 2018 voor de Office-applicaties, maar mail draaide nog on-premise, "voor nu", zes jaar lang. De koppelingen waren ingewikkeld: scanners die rechtstreeks naar het oude systeem mailden, een telefoonsysteem dat met Exchange praatte, distribution lists die niemand kon herleiden, en honderd kleine handtekening-templates die ergens in een share waren ingebakken.

De angst zat niet in de migratie zelf. Die zat in mail-verlies, in een downtime-moment dat klanten zouden voelen, en in de honderd kleine integraties die niemand meer compleet wist.

Wat we deden

We werken migraties altijd in fases met een echte staging-fase:

1. Inventarisatie: wat moet mee, wat blijft, wat hoeft niet (oude shared mailboxes die niemand al twee jaar gelezen had). 2. Pilot met 8 mensen, twee weken, in productie. Hier sneuvelden de scanner-koppelingen, daar hadden we tijd voor. 3. Cohort-migratie van de rest in vier nachtelijke waves van 15 mensen, met fallback en checks. 4. Oude omgeving 30 dagen warm gehouden voordat we de stekker eruit haalden.

Geen weekend-cowboy-migratie. Geen "het zou moeten werken op maandag".

Wat het opleverde

Na de migratie:

- Nul mail-verlies, gemeten over alle mailboxen voor en na. - Per gebruiker tussen 0 en 25 minuten effectieve downtime, gepland in nachtelijke uren. - 92% van de eerstelijns-issues opgelost door de helpdesk in de eerste week, niet doorgegeven aan de gebruikers. - Eén document met de post-migratie-staat, en waar de oude omgeving stond.

De partner die het bedrijf draait verklaarde dat hij wist dat het moest gebeuren, maar niet hoe rustig het verlopen kon.

Wat dit niet was

Geen lift-and-shift met de hoop dat het werkt. Geen losse Exchange-licentie die "ergens nog ergens stond" actief laten. Geen migratie-tool kopen omdat het kan; we gebruikten Microsoft's eigen tools waar die volstonden, en deden de complexe stukken handmatig met scripts die we publiceerden in het runbook.