Een migratie zonder onderbreking betekent dat elk bericht dat naar uw domein wordt gestuurd in een mailbox aankomt, en dat elke medewerker op de dag van de overstap zijn contacten kan mailen. Het betekent niet dat de historiek, de mobiele toestellen en de gewoonten veranderen zonder dat iemand iets hoeft te doen.
Twee platforms draaien parallel.
Het klassieke gat ontstaat door een MX-record dat wordt omgezet terwijl een kopie nog onvolledig is, of door een kopieerapparaat, een website of een CRM dat nog met de oude inloggegevens verzendt.
Het MX-record is een DNS-record: het vertelt verzendende servers waar de post voor uw domein moet worden afgeleverd. Van e-maildienst wisselen betekent in de eerste plaats dit afleveradres wijzigen. De rest (accounts, historiek, toestellen) wordt daaromheen voorbereid.
Het SMTP-protocol kan goed overweg met korte storingen. Een verzendende server die een tijdelijke fout ontvangt, houdt het bericht in de wachtrij en probeert het later opnieuw. Een server die even onbereikbaar is, leidt dus niet tot verlies van post. Een definitieve fout (onbekende mailbox, geweigerd bericht) stuurt het bericht daarentegen terug naar de afzender, en dat bericht komt nooit vanzelf alsnog aan. Het grootste risico van een overstap is niet een storing, maar een nieuw platform dat een ontvanger weigert omdat een alias of een lijst niet opnieuw is aangemaakt.
De TTL (time to live) bepaalt hoe lang een DNS-resolver een antwoord in het geheugen mag bewaren. Gedurende die periode levert een deel van de afzenders nog af bij het oude platform. Dat is normaal, en daarom moet het oude platform tijdens de overgang post kunnen blijven ontvangen.
Twee weken vooraf. Inventaris van mailboxen, aliassen, lijsten, gedeelde mailboxen en alle applicaties die e-mail verzenden. Verlaging van de DNS-TTL van het MX-record naar een korte waarde (vaak 300 seconden), zodat de wijziging op de dag D snel doorwerkt. Aanmaak van de doelaccounts. Eerste kopie van de historiek.
De TTL wordt vroeg verlaagd, omdat een resolver die de oude waarde heeft gelezen die bewaart tot ze verloopt: de korte TTL werkt pas zodra de oude cache is verlopen. De eerste kopie duurt het langst; door ze vroeg te starten is er tijd om de mailboxen te ontdekken die problemen geven.
Enkele dagen vooraf. Controle van een steekproef: aantal berichten, mappen of labels, afspraken, contactpersonen. Bijsturing van de methode als de steekproef faalt. Voorbereiding van de handleidingen voor mobiele toestellen en Outlook. Verzendtest vanaf het doelplatform naar Gmail en Outlook.com, met SPF, DKIM en DMARC al geldig op het nieuwe platform. Deze records kunnen vóór het MX-record worden gepubliceerd.
Concreet: één enkel SPF-record dat tijdens de overgang beide platforms toestaat (twee afzonderlijke SPF-records doen de controle mislukken), een DKIM-sleutel van het nieuwe platform onder een eigen selector gepubliceerd, naast de oude, en een nagelezen DMARC-beleid. DMARC vereist dat het bericht via SPF of DKIM is geauthenticeerd namens het domein van de afzender; is uw beleid strikt en is het doelplatform nog niet toegestaan, dan weigeren uw contacten uw berichten.
De dag ervoor. Tweede ronde: alleen kopiëren wat sinds de eerste kopie is binnengekomen. Wijzigingen aan aliassen en lijsten bevriezen.
De dag D. Omzetting van het MX-record. Onmiddellijke externe controle: een e-mail die vanaf een externe privémailbox wordt verstuurd, moet binnen de TTL op het nieuwe platform aankomen. Bewaking van de wachtrij. Herconfiguratie van de applicaties die e-mail verzenden. Een aangewezen interne hotline, met het recht om het MX-record terug te zetten als een kritieke berichtenstroom faalt.
Wijzig tegelijk het autodiscover-record als dat bestaat: dat raadpleegt Outlook om zijn server te vinden. Verwijder ook secundaire MX-records die nog naar het oude platform zouden verwijzen: een afzender die het primaire MX-record niet bereikt, probeert de volgende.
De dagen erna. Het oude platform alleen-lezen. Melding van afwijkingen (een ontbrekende map, een gedeelde mailbox). Zo nodig een gerichte derde ronde. Daarna het verzenden via het oude platform afsluiten, zodat een medewerker niet langer vanaf twee plaatsen antwoordt.
Dat laatste punt heeft een technische reden. Het oude platform beschouwt zich nog altijd als verantwoordelijk voor uw domein: een bericht dat het naar een collega verstuurt, wordt daar lokaal afgeleverd, zonder het MX-record te raadplegen. De collega ziet het nooit in zijn nieuwe mailbox.
| Risico | Wat er gebeurt | Remedie |
|---|---|---|
| MX-record te vroeg omgezet | Nieuwe post komt aan, de historiek ontbreekt | Pas omzetten na controle van de steekproef en de tweede ronde |
| Vergeten alias of lijst | Het doelplatform weigert deze berichten definitief | Inventaris, aliassen de dag ervoor bevriezen, collectieve adressen testen |
| Onvolledig SPF, DKIM of DMARC | Uw berichten worden bij contacten geweigerd of als ongewenst gemarkeerd | Vóór de dag D publiceren, controleren met een echt bericht |
| Applicatie die met het oude account verzendt | Facturen, meldingen of scans worden niet meer verstuurd | Lijst van applicaties, nieuwe SMTP-server ingesteld op de dag D |
| Verzenden op het oude platform blijft open | Interne berichten blijven in het oude systeem achter | Verzenden afsluiten zodra de steekproef is gevalideerd |
| Terugdraaien niet voorbereid | Het MX-record wordt teruggezet, maar de intussen ontvangen berichten blijven op het doelplatform | Schriftelijk plan, inclusief het overnemen van deze berichten |
Neem ter illustratie een kantoor van 40 personen. Het kiest ervoor om op een donderdag aan het einde van de dag over te stappen in plaats van op een vrijdag: de volgende dag is het team aanwezig om afwijkingen op te lossen, en de interne hotline heeft een volle werkdag voor zich. Het kopieerapparaat aan de receptie, dat naar e-mail scant, wordt dezelfde avond opnieuw ingesteld. Als twee gedeelde mailboxen een ontbrekende map melden, vult een gerichte ronde die aan. In dit scenario gaat geen enkel bericht verloren, maar moeten verschillende medewerkers hun account op hun telefoon opnieuw instellen: dat is het zichtbare deel dat u moet aankondigen.
Zij wijzigen de server in Outlook of op hun mobiele toestel. Het eerste laden van een grote mailbox kost tijd. Berichten die al in de cache van de telefoon staan, kunnen dubbel verschijnen als het profiel niet netjes opnieuw wordt aangemaakt. Voorzie de procedure “account verwijderen en opnieuw aanmaken” in plaats van een geïmproviseerde serverwijziging.
Voor Outlook geldt dezelfde reden: het profiel bewaart een lokale cache die aan de oude server is gekoppeld. Een nieuw profiel begint met een schone lei; een aangepast oud profiel vermengt beide werelden. Op mobiele toestellen verandert het gebruikte protocol (Exchange ActiveSync of IMAP, afhankelijk van het doelplatform) soms met het platform, wat nog een reden is om het account opnieuw aan te maken.
Regels aan serverzijde, centrale handtekeningen en delegatierechten moeten opnieuw worden ingesteld. Kondig dat aan. Het is geen onderbreking van de post. Het is beheerwerk.
Die doorsturing vergt een expliciete instelling: het oude platform, dat nog denkt de mailboxen te hosten, moet worden geconfigureerd om naar het nieuwe door te sturen in plaats van zelf af te leveren. Lukt dat niet, dan doet een gerichte inhaalronde hetzelfde werk.
De bijzonderheden van elk vertrekpunt staan beschreven in migreren van Microsoft 365 en migreren van Google Workspace.
Zo lang als nodig is om na te gaan dat geen enkele berichtenstroom het oude platform nog gebruikt, en dat de gemelde afwijkingen zijn opgelost. Dat hangt af van het aantal mailboxen, van de applicaties die verzenden en van het tempo waarin de werkplekken opnieuw worden ingesteld. Te vroeg afsluiten maakt correcties onmogelijk; te laat afsluiten laat medewerkers in twee systemen werken.
Nee, als die is voorbereid. Gedurende de TTL levert een deel van de afzenders nog af bij het oude platform, de rest bij het nieuwe. Beide ontvangen, en de volgende ronde brengt alles samen. Post gaat alleen verloren als ze wordt geweigerd, vandaar het belang van aliassen en lijsten.
Doorgaans niet: de adressen veranderen niet. Verwittig wel de partners die uw berichten strikt filteren of die een specifieke regel voor u hebben ingesteld, en degenen die versleutelde e-mail met u uitwisselen, als de sleutels veranderen.
Ja, door het oude MX-record terug te zetten, op voorwaarde dat het oude platform nog actief is. De berichten die het nieuwe platform intussen heeft ontvangen, moeten dan worden teruggekopieerd of raadpleegbaar blijven. Het plan voor terugdraaien legt vast wie beslist, binnen welke termijn, en hoe deze berichten worden overgenomen.
Vraag de beheerder wat hij garandeert: de aankomst van berichten, de overname van de historiek, of beide. Dat zijn verschillende verbintenissen. Vraag ook het schriftelijke plan voor terugdraaien, met de persoon die het mag activeren.
Een garantie op de aankomst van berichten heeft betrekking op de dag D en de dagen erna. Een garantie op de historiek heeft betrekking op de kopie en de controle ervan. Een dienstverlener kan de ene nakomen zonder de andere; de offerte moet vermelden welke hij voor zijn rekening neemt en hoe die wordt gecontroleerd.
Bij Klytic zijn advies en suggesties voor de voorbereiding van de e-mailmigratie gratis, en gaat er geen enkele e-mail verloren. De migratie die Klytic uitvoert, gebeurt op offerte. De abonnementen staan op de pagina Tarieven en worden afzonderlijk gefactureerd. De kostenposten staan in detail in wat kost een migratie van Microsoft 365, en de controlelijst in de checklist. Om doelplatforms te vergelijken, zie een Europese e-maildienst kiezen.
Deze pagina beschrijft een methode. Het werkelijke verloop hangt af van uw berichtenstromen, uw volumes en het platform dat u verlaat.
Geraadpleegd in oktober 2026.
Gratis advies, geen enkele e-mail verloren. Een migratie door Klytic gebeurt op offerte, na een inventarisatie.
Welkomstaanbod
Proefaanbod zonder verplichtingen. Een adviseur belt u terug om uw behoeften te begrijpen en uw Klytic-omgeving voor te bereiden.
