Mailbox migreren zonder downtime: wat is realistisch?

# Is mailbox-migratie zonder downtime mogelijk?

Nee, niet in absolute zin: zolang DNS-propagatie bestaat, is er altijd een kort venster waarin een deel van de wereld nog naar het oude adres verwijst. In de praktijk is dat venster te beperken tot een paar minuten tot enkele uren, wat voor de meeste mkb-bedrijven neerkomt op nul gemiste e-mails en geen merkbare downtime.

Het onderscheid dat vaak over het hoofd wordt gezien: downtime bij een mailbox-migratie gaat zelden over het kopiëren van de mail zelf, maar over het moment waarop je omschakelt naar de nieuwe server. Bij kopieer-modus blijft de bron-mailbox gewoon actief en bereikbaar terwijl er via IMAP wordt gekopieerd; er wordt niets verwijderd en er wordt niets omgezet totdat de kopie compleet en gecontroleerd is. Het enige overgebleven risico zit in de MX-record-omzetting die daarna volgt, en dat risico is met een lage TTL en een overlapperiode goed te beheersen.

Bij mailmigreren.nl gebruiken we standaard kopieer-modus: de bron blijft onaangeroerd staan tijdens de migratie van 30-90 minuten per mailbox van 5GB, dus je bepaalt zelf wanneer je de MX-records omzet, in plaats van dat de migratietool die beslissing voor je maakt.

# Wat veroorzaakt downtime bij een e-mailmigratie?

Downtime ontstaat vrijwel altijd door drie factoren: het verplaatsen in plaats van kopiëren van mail waardoor de bron leeg raakt voordat de nieuwe mailbox klaar is, een te hoge TTL-waarde op de MX-records waardoor de omzetting te lang duurt, en het te vroeg uitschakelen van de oude mailbox.

Bij verplaats-migraties wordt mail bij de bron verwijderd zodra die is overgezet. Raakt de verbinding halverwege onderbroken, dan mis je mail aan beide kanten: het is nog niet volledig aangekomen op de nieuwe server en al niet meer beschikbaar op de oude. Dat risico speelt niet bij kopiëren, omdat de bron pas na jouw eigen controle uit gebruik wordt genomen.

Een MX-record met een TTL van 24 of 48 uur, wat bij veel providers de standaardinstelling is, betekent dat sommige DNS-resolvers na de omzetting nog tot 48 uur naar het oude adres blijven verwijzen. Verlaag je de TTL niet vooraf, dan loop je dat risico automatisch mee bij elke migratie, ongeacht welke migratietool je gebruikt.

Het derde risico is menselijk: de oude mailbox binnen een uur na de MX-omzetting al opzeggen of leegmaken. Dat is precies het moment waarop er door propagatie-vertraging nog mail op de oude server kan binnenkomen, dus vroegtijdig opzeggen is de meest voorkomende oorzaak van daadwerkelijk mailverlies bij een migratie.

• Verplaatsen in plaats van kopiëren: bron raakt leeg voor de kopie compleet is
• Hoge TTL op de MX-records: omzetting duurt tot 48 uur bij sommige resolvers
• Oude mailbox te vroeg uitschakelen: mail tijdens propagatie gaat verloren

# Wat is dual-delivery en MX-overlap?

Dual-delivery betekent dat je gedurende de DNS-propagatieperiode bewust mail op zowel de oude als de nieuwe mailserver laat binnenkomen, zodat je na de overstap niets kwijtraakt, ongeacht welke server een verzendende partij op dat moment nog gebruikt.

Echte dual-delivery via een secundaire MX-record met lagere prioriteit vraagt mailserver-configuratie die de meeste mkb-hostingpanelen niet standaard aanbieden. Het realistische alternatief voor de meeste bedrijven is functioneel gelijk: laat de oude mailbox tijdens en na de MX-omzetting nog gewoon bereikbaar en ingelogd staan, en haal na het overlapvenster met een korte delta-sync alsnog binnen wat daar is binnengekomen.

Een praktisch tijdschema ziet er zo uit: dag 0 verlaag je de TTL naar 300 seconden, dag 2 draai je de migratie en zet je de MX-records om, dag 2 tot en met 5 blijft de oude mailbox als vangnet bereikbaar, en op dag 5 doe je de laatste delta-sync voordat je de oude mailbox definitief sluit.

Het effect van deze aanpak is dat de propagatieperiode geen risicovol gat meer is, maar een gecontroleerd overlapvenster waarin je weet waar eventuele late mail terechtkomt en hoe je die alsnog ophaalt.

# Kopieer-modus versus verplaatsen: het verschil in downtime-risico

Het downtime-risico van een migratie wordt in de eerste plaats bepaald door de methode: kopiëren laat de bron intact totdat je zelf besluit om te schakelen, verplaatsen verwijdert mail bij de bron zodra die is overgezet en maakt je afhankelijk van een storingsvrij verloop zonder eigen controlemoment.

Hoasted MailSync (15 euro per mailbox) en de YourHosting Migratieservice (25 euro per mailbox) werken met vergelijkbare migratieprincipes, maar zijn gekoppeld aan het overstappen naar hun eigen hosting. Mailmigreren.nl is provider-onafhankelijk: de bron blijft staan via IMAP-APPEND streaming, een kopieermethode zoals beschreven in het IMAP4rev1-protocol (RFC 3501), of je nu van Strato naar Hostnet gaat, van Mijndomein naar TransIP, of tussen twee compleet andere providers migreert.

Omdat wachtwoorden alleen in werkgeheugen worden gebruikt en nooit op disk terechtkomen, en een migratie automatisch via iDEAL wordt terugbetaald als die faalt, is het risico op een halverwege vastgelopen migratie, en daarmee gedwongen downtime, structureel lager dan bij tooling zonder dat soort waarborgen.

# Hoe zet je een migratie met minimale downtime op?

Een migratie met minimale downtime volgt een vaste volgorde: eerst voorbereiden door de TTL te verlagen, dan kopiëren terwijl de bron actief blijft, pas daarna de MX-records omzetten, en tot slot een overlapperiode aanhouden voordat je de oude mailbox definitief sluit.

Deze volgorde is bewust zo strak: elke stap overslaan of omdraaien, zoals de MX-records al omzetten vóór de kopie klaar is, haalt het downtime-voordeel van kopieer-modus grotendeels onderuit. Het stappenplan hieronder is te gebruiken voor elke IMAP-provider, van Strato en Hostnet tot Vimexx, Antagonist of Byte.

# Realistische verwachtingen: wat kan er nog misgaan?

Ook met een zorgvuldige aanpak blijven er twee realistische restrisico's over: een enkele DNS-resolver die de oude TTL toch langer vasthoudt dan verwacht, en een verzendende mailserver die zelf traag is met het herkennen van de MX-wijziging, los van jouw eigen instellingen.

Daarnaast is het makkelijk om bij de MX-omzetting per ongeluk ook SPF- of DKIM-records te vergeten aan te passen. Dat veroorzaakt geen downtime in de zin van gemiste mail, maar wel bezorgproblemen: uitgaande mail kan als spam worden gemarkeerd totdat die records kloppen. Neem dit daarom mee in dezelfde DNS-wijziging als de MX-omzetting, niet als aparte actie achteraf.

Het totale risico op daadwerkelijk mailverlies met kopieer-modus plus een overlapvenster van 24-72 uur is met deze voorbereiding minimaal, maar niet wiskundig nul. Reken op vrijwel downtime-vrij, niet op een garantie zonder enige uitzondering.

Als de migratie zelf onverhoopt vastloopt, bijvoorbeeld door een tijdelijk onbereikbare bronserver, wordt het bedrag automatisch via iDEAL teruggestort en blijft de bron-mailbox gewoon intact; je verliest in dat scenario dus geen mail, alleen tijd.

• Een DNS-resolver die de oude TTL langer vasthoudt dan verwacht
• Een verzendende mailserver die traag is met het herkennen van de MX-wijziging
• Vergeten SPF- of DKIM-records aan te passen, met bezorgproblemen als gevolg

# Microsoft 365 en Gmail: bijzonderheden bij de overstap

Bij Microsoft 365 en Gmail verloopt de MX-route anders dan bij standaard IMAP-hosting, omdat je daar meestal in het beheercentrum een domein toevoegt en de MX-records daarnaartoe wijst in plaats van naar een los mailserver-IP.

Mailmigreren.nl ondersteunt Microsoft 365 en Gmail via app-wachtwoorden en basic-auth; OAuth volgt in een volgende versie. Voor het toevoegen van je domein en de bijbehorende DNS-instellingen volg je de officiële Microsoft-documentatie, die per DNS-provider een eigen stappenplan geeft.

Belangrijk om te beseffen: het kopiëren van mail naar de nieuwe M365- of Gmail-mailbox staat volledig los van de MX-omzetting. Je kunt dus eerst alle mail overzetten met een app-wachtwoord en pas daarna de MX-records omzetten zodra je hebt geverifieerd dat alles klopt, precies dezelfde volgorde als bij een reguliere IMAP-migratie.

Hetzelfde principe van een overlapvenster geldt hier onverkort: houd de oude mailbox 24-72 uur na de omzetting bereikbaar en doe daarna een laatste delta-sync, ook als de bestemming Microsoft 365 of Gmail is.