Stappen voor e-mailmigratie: planning van T-7 tot T+1

Stappen voor e-mailmigratie: een planning per dag zonder onnodige uitval

Deze migratie is geen gewone bestandskopie. Je beheert een statusovergang tussen twee actieve databases terwijl gebruikers gegevens wijzigen. Als de gegevenslaag (IMAP) en routeringslaag (DNS) uit de pas lopen, ontstaat gesplitste routering: een deel van de organisatie ontvangt mail op de oude server en een ander deel op de nieuwe.

Dit draaiboek geeft de uitvoeringsvolgorde per dag, van T-minus 7 tot T-plus 1. Voor de technische achtergrond lees je de volledige handleiding voor e-mailconfiguratie.

De drie lagen die je beheert

Elke e-mailmigratie omvat drie lagen. Een fout in één ervan kan uitval veroorzaken.

1. Gegevenslaag: historische e-mail (IMAP)
2. Routeringslaag: DNS-records (MX) die bepalen waar nieuwe mail aankomt
3. Identiteitslaag: de clientconfiguratie in Outlook en mobiele apps waarmee mail wordt geopend

T-7 dagen: inventarisatie en opschoning

Je kunt niet migreren wat je niet kent. Een gebruikerslijst is geen volledige inventaris. Deze eerste stappen brengen alles in beeld.

Inventariseer alles

• Breng alle objecttypen in kaart: postvakken, aliassen, distributielijsten en openbare mappen.
• Vind de grootste postvakken: zoek postvakken groter dan 20 GB. Google beperkt IMAP-downloads tot ongeveer 2,500 MB/day. Een postvak van 50 GB kost weken, geen uren. De Google Workspace-gids voor gegevensmigratie beschrijft deze limieten.
• Ruim donkere gegevens op: voormalige medewerkers hebben geen actief postvak nodig. Exporteer hun mail naar lokale archieven.

Gebruik bij Exchange PowerShell om het werkelijke aantal items op te vragen. Grootte in GB is door compressie geen betrouwbare vergelijking:

T-2 dagen: vooraf synchroniseren

Wacht niet tot vrijdagavond. Verplaats 90% van de historische gegevens terwijl gebruikers nog werken. Dat verlaagt het risico tijdens de overstap aanzienlijk.

Start de synchronisatie

Stel je migratietool, of imapsync, in voor mail ouder dan 30 dagen. Let op HTTP 429 (Too Many Requests) en Google-fouten 11001.

Belangrijke snelheidslimieten

Waarschuwing voor Gmail: migreer de map All Mail niet naast elk label als afzonderlijke map. Gmail-labels verwijzen naar dezelfde berichten en een verkeerde mapkoppeling kan daardoor duplicaten maken. Koppel labels zorgvuldig en sluit Gmail/All Mail in dit scenario uit.

T-1 dag: TTL verlagen, de 300-secondenregel

DNS-records worden vaak 24 uur gecachet (TTL 86,400). TTL verlagen wordt vaak overgeslagen en later betreurd. Zonder voorafgaande verlaging kunnen resolvers na de MX-wijziging nog een dag naar de oude server routeren.

1. Log in bij je DNS-provider, zoals Cloudflare of Route53.
2. Zoek de MX-records.
3. Wijzig de TTL naar 300 seconden (5 minuten).
4. Verwijder de oude records niet; werk alleen de TTL bij.

Controleer dit met dig:

T-0, vrijdagavond: de overstap

De gebruikers zijn gestopt met werken. Voer nu de meest kritieke migratiestappen uit.

Stap 1: wijzigingen bevriezen

Vraag gebruikers geen mail meer te verzenden. Vergrendel waar mogelijk de bronaccounts om verweesde berichten te voorkomen.

Stap 2: deltasynchronisatie

Start de migratietool opnieuw. Deze ronde pakt de laatste 30 dagen en nieuwe items. Omdat de bulk al is verplaatst, hoort dit aanzienlijk korter te duren, maar de werkelijke tijd hangt van volume en providerlimieten af.

Let op UIDVALIDITY: als de bronserver mappen opnieuw heeft geïndexeerd, kan de tool duplicaten opnieuw downloaden. Voer eerst een proefrun uit. IMAP RFC 3501 legt UIDVALIDITY uit.

Stap 3: MX-records wijzigen

Werk de MX-records bij voor de nieuwe provider. Voor TrekMail:

Met een TTL van 300 seconden kunnen caches die deze waarde respecteren na ongeveer 5 minuten verversen, maar caches en resolvers bepalen de feitelijke duur.

Stap 4: SPF en DKIM bijwerken

Publiceer en controleer de machtiging voor de nieuwe verzendende IP-adressen in SPF voordat de nieuwe provider gaat verzenden. Houd oude afzenders toegestaan zolang ze nog mail versturen. Lees onze gids over e-mailauthenticatie op je domein instellen.

T+1, maandagochtend: controle

De laatste stappen draaien om controle. Ga niet uit van succes, maar verifieer het.

Aantallen items vergelijken

Vergelijk het aantal items bij bron en bestemming. Een afwijking onder 1% kan verklaarbaar zijn, vaak door beschadigde MIME-items. Meer dan 5% wijst mogelijk op een structureel probleem, zoals mapdiepte of een verkeerd filter.

Clients opnieuw configureren

Mailclients moeten naar het nieuwe account worden omgezet. Soms kan een bestaand profiel veilig worden aangepast; in andere gevallen is verwijderen en opnieuw toevoegen betrouwbaarder.

Agenda's en contacten

TrekMail biedt professionele e-mailhosting voor bedrijven en host agenda's via CalDAV en contacten via CardDAV. De IMAP-migratie verplaatst deze echter niet, maar alleen ondersteunde mail en mappen. Exporteer agenda's als .ics en contacten als .vcf bij de oude provider en importeer ze in TrekMail. Controleer daarna de synchronisatie op elk apparaat.

Go/no-go-controlepunten

Het terugvalplan

Als het nieuwe systeem mail weigert of kritieke gegevens ontbreken:

1. MX terugzetten: wijs MX terug naar de oude provider. Met een TTL van 300s kan dit snel zichtbaar worden, maar 5 minuten is geen garantie.
2. Het gat exporteren: houd de nieuwe provider bereikbaar en herhaal de controle; exporteer mail die daar aankomt totdat DNS-caches zijn verlopen als EML/MBOX en importeer die op de oude server.
3. Diagnose stellen: controleer vóór een nieuwe poging op 550 5.7.1 (Relay Access Denied) en firewallblokkades.

TrekMail automatiseert deze migratiestappen

Handmatige migratie brengt risico met zich mee. TrekMail automatiseert delen van de infrastructuur, zodat je je op klanten kunt richten.

Voor kleine bedrijven

De ingebouwde migratietool beheert de IMAP-handshake, nieuwe pogingen en snelheidslimieten voor ondersteunde mail en mappen. Voer de inloggegevens in, laat de mail overzetten en vergelijk daarna de aantallen met de bron.

Voor bureaus en MSP's

Bulkconfiguratie voor 100+ domeinen. Gedeelde opslag voor alle klanten in plaats van limieten per gebruiker. Managed SMTP zonder eigen IP-opwarmtraject.

Alle betaalde abonnementen hebben een gratis proefperiode van 14 dagen, waarvoor een kaart vereist is. Voor Nano is geen kaart nodig.

Conclusie

Deze planning heeft een vaste volgorde omdat elke fase op de vorige steunt. Sla je de TTL-verlaging over, dan kan gesplitste routering tot 24 uur aanhouden. Zonder voorstaging kan de overstap op vrijdag tot zaterdag doorlopen.

Volg de planning, controleer aantallen items en houd een terugvalplan gereed. Dat is de kern.

Klaar om te beginnen? Maak een gratis TrekMail-account en gebruik de ingebouwde migratie-engine voor het zware werk.