Tool voor e-mailmigratie: IMAP-taken veilig hervatten

Je tool voor e-mailmigratie is het belangrijkst wanneer de taak om 2 uur 's nachts vastloopt. Dat is de echte test, niet de demonstratie waarin alles goed gaat of de commerciële schermafbeelding. Als je e-mail vanuit Gmail, Microsoft 365 of een oude cPanel-server verplaatst, zijn fouten normaal. De vraag is eenvoudig: hervat de tool de taak netjes of maakt hij duplicaten, slaat hij mappen over en laat hij jou de rommel aan gebruikers uitleggen? Als je de bredere overstap plant, begin dan bij zakelijke e-mail, zodat de migratie past bij het systeem dat je werkelijk bouwt.

Dit is het korte antwoord. Een veilige tool heeft vier zaken nodig: detectie van duplicaten, logica voor nieuwe pogingen, maptoewijzing en logboeken per item. Ontbreekt er één, dan verandert een storing halverwege in een project om mailboxen op te schonen.

Je wordt wakker, bekijkt het dashboard en ziet dat 68% klaar is. Eén mailbox heeft de status mislukt. De gebruiker meldt zich aan en de helft van de verzonden e-mail ontbreekt. Dat is geen pech, maar een probleem met de tool.

Daarom kijken goede beheerders minder naar een voortgangsbalk en meer naar statusregistratie. Als de tool niet kan aantonen wat hij heeft gekopieerd, wat hij heeft overgeslagen en waar hij stopte, heb je geen migratie maar een gok.

Wil je de achtergrond van het protocol begrijpen, dan legt het overzicht van IMAP-migratie van TrekMail uit wat IMAP-imports wel en niet verplaatsen. Werk je rechtstreeks vanaf de opdrachtregel in plaats van via een gehost proces, lees dan ook deze gids over imapsync voordat je de productieomgeving aanraakt.

Wat een migratietool moet doen als een taak mislukt

Een tool voor e-mailmigratie moet na een netwerkstoring, snelheidsbeperking of beschadigd bericht kunnen hervatten zonder e-mail te dupliceren of mappen over te slaan. De belangrijkste eis is idempotentie: voer dezelfde taak opnieuw uit en de bestemming blijft correct. Al het andere is ondergeschikt.

Veel tools verkopen snelheid. Snelheid is prettig. Veilig kunnen hervatten redt je project.

Wanneer een taak mislukt, moet de tool standaard al het volgende doen:

1. Opnieuw verbinding maken zonder vanaf nul te beginnen.
2. Berichten overslaan die al op de bestemming bestaan.
3. Het exacte item of de exacte map met de fout registreren.
4. Pauzeren en opnieuw proberen wanneer de bronserver vraagt om te vertragen.
5. De mapstructuur intact houden bij verschillende stijlen van IMAP-naamruimten.

Kan het product deze vijf taken niet uitvoeren, vertrouw het dan geen echte omschakeling toe.

De fouten die bijna elke grote migratie stoppen

De meeste migratiefouten zijn normaal gedrag van IMAP onder belasting. Providers beperken clients, tokens verlopen, servers verbreken verbindingen en onjuist gevormde berichten laten parsers vastlopen. Een goede tool behandelt dit als verwachte bedrijfsomstandigheden, niet als zeldzame uitzonderingen.

Laten we concreet worden.

Snelheidsbeperking komt eerst. Gmail, Microsoft 365 en oudere servers voor gedeelde hosting beschermen zichzelf allemaal. Belast je ze te zwaar, dan vertragen ze de verbinding of sluiten ze je af. Een zwakke tool blijft de server bestoken en maakt de blokkade erger.

Beschadigde items volgen daarna. Eén onjuist gevormde MIME-header of te grote bijlage kan een gebrekkige importer steeds opnieuw op hetzelfde bericht laten vastlopen. Als de tool dat item niet kan isoleren en verdergaan, komt de volledige taak tot stilstand.

Verlopen authenticatie is een andere veelvoorkomende oorzaak. Microsoft heeft basisauthenticatie in Exchange Online-omgevingen uitgeschakeld, terwijl moderne authenticatieprocessen tijdens langdurige taken nog steeds tokens moeten vernieuwen. Als de migratie-engine die vernieuwing niet goed afhandelt, stopt de taak halverwege.

Microsoft beschrijft de uitschakeling van basisauthenticatie voor Exchange Online in de officiële richtlijnen over de uitfasering van basisauthenticatie. Voor IMAP definieert RFC 3501 mailbox-UID's en UIDVALIDITY in de basisspecificatie van IMAP4rev1. Deze twee bronnen verklaren waarom oude aannames in 2025-2026 niet meer werken.

Veilig hervatten hangt af van idempotentie, niet van hoop

Idempotentie betekent dat de tool opnieuw voor dezelfde mailbox kan worden uitgevoerd en nog altijd één juiste kopie van elk bericht oplevert. Zonder die eigenschap brengt elke nieuwe poging het risico op duplicaten, ontbrekende e-mail of allebei met zich mee. Dit is de belangrijkste ontwerpeigenschap van elke migratie-engine.

Hier vallen goedkope tools door de mand.

Een eenvoudige tool registreert alleen de laatst waargenomen UID en neemt aan dat de bronmailbox nooit verandert. Echte servers gedragen zich niet zo netjes. Mailboxen worden gecomprimeerd, gerepareerd en hersteld. UIDVALIDITY verandert. Dan moet de tool overschakelen van snel hervatten op basis van UID naar een langzamere controle op duplicaten, bijvoorbeeld door Message-ID's te vergelijken.

Dat is het verschil tussen vertraging en een ramp.

imapsync \
  --host1 imap.oldhost.com --user1 alice@example.com --password1 'source-pass' \
  --host2 imap.trekmail.net --user2 alice@example.com --password2 'dest-pass' \
  --ssl1 --ssl2 \
  --syncinternaldates \
  --useheader 'Message-Id' \
  --skipsize \
  --skipcrossduplicates \
  --errorsmax 50

Zo'n aanpak die veilig met verschillen omgaat, is de reden dat beheerders een tweede ronde in het draaiboek opnemen. De eerste brengt het grootste deel van de e-mail over. De tweede haalt later aangekomen items op en controleert of duplicaten zich niet opstapelen.

Migreer je specifiek vanuit Gmail, dan behandelt de Gmail-migratiegids van TrekMail de inloggegevens, waaronder de noodzaak van een app-wachtwoord wanneer Google het gewone accountwachtwoord voor IMAP-toegang weigert.

Stil gegevensverlies verschuilt zich in maptoewijzing

Maptoewijzing vertelt de migratietool hoe namen van bronmappen op de bestemming moeten terechtkomen. Zonder toewijzing kan de e-mail met succes worden geïmporteerd, maar op de verkeerde plek belanden. Dat is een stille fout: de gegevens bestaan, maar de gebruiker denkt dat ze verdwenen zijn.

Dit probleem komt voortdurend voor.

De ene server gebruikt punten, de andere schuine strepen. De ene noemt verzonden e-mail Sent Messages, de andere verwacht Sent Items. Een zwakke tool kopieert de mapnamen letterlijk en noemt de taak voltooid. De gebruiker meldt zich aan en ziet op hoofdniveau een ongeordende hoop mappen.

Deze toewijzingen zijn het belangrijkst:

^Sent Messages$  -> Sent Items
^Deleted Messages$ -> Trash
^Draft Messages$ -> Drafts
INBOX\.(.+) -> INBOX/$1

De laatste regel is de valkuil van de naamruimte. Hij zet mapstructuren met punten, gebruikelijk in Dovecot- of cPanel-configuraties, om in structuren met schuine strepen die IMAP-clients en gehoste platforms vaak verwachten.

Maptoewijzing telt ook wanneer je mailboxconfiguratie over veel domeinen opschaalt. Het is hetzelfde operationele probleem als provisioning: consistentie voorkomt opruimwerk. Daarom worden grote aantallen e-mailaccounts aanmaken en e-mailhosting voor meerdere domeinen belangrijk zodra je meer dan enkele gebruikers migreert.

Logboeken bepalen of je de laatste 2% kunt oplossen

Een bruikbare migratietool moet logboeken per item produceren, niet alleen een groen vinkje of een rode X. Je moet weten welk bericht mislukte, in welke map het stond en waarom. Anders kun je niet bepalen of je de taak moet herhalen, het item moet negeren of het probleem moet escaleren.

“Voltooid met fouten” vertelt niets bruikbaars. Je hebt een lijst nodig.

De minimale logboekuitvoer bevat het onderwerp, de bronmap, de berichtdatum, de grootte van het item en de reden van de fout. Nog beter is een export naar CSV. Daarmee kun je filteren op foutsoort en elke categorie op de juiste manier afhandelen.

Dit is de workflow die in de praktijk werkt:

1. Voer de eerste migratieronde uit.
2. Exporteer of bekijk de logboeken van overgeslagen items.
3. Groepeer fouten op oorzaak: authenticatie, time-out, te groot item, onjuist gevormd item of bestemmingsquotum.
4. Voer de taak opnieuw uit met het overslaan van duplicaten ingeschakeld.
5. Behandel alleen de echte uitzonderingen handmatig.

Die workflow is saai. Mooi. Tijdens een migratie wil je dat het saai is.

Controleer vóór de definitieve omschakeling het bestemmingsdomein en de mailboxconfiguratie. De TrekMail-gids over een domein toevoegen behandelt DNS, zodat je de e-mail niet eerst goed verplaatst en daarna bij de MX-stap de bezorging stukmaakt.

Oude en nieuwe aanpak: scripts, SaaS per gebruiker en TrekMail

De oude aanpak bestaat uit een stapel scripts, migratiekosten per gebruiker en handmatig toezicht. De nieuwe aanpak integreert de migratietool in het mailplatform, bepaalt de prijs per abonnement en neemt nieuwe pogingen en controles op duplicaten standaard in de workflow op.

Oude aanpak: zelf imapsync uitvoeren, app-wachtwoorden beheren, gedrag bij nieuwe pogingen afstellen, mappen handmatig toewijzen, logboeken één voor één bekijken en na de overstap een andere provider per mailbox betalen.

Nieuwe aanpak: de IMAP-migratie aan serverzijde van TrekMail gebruiken binnen hetzelfde platform dat de doelmailboxen host. Je voert de oude IMAP-gegevens in, kiest de TrekMail-mailbox en start de import via het dashboard. De documentatie toont het overslaan van duplicaten als standaardoptie. De taakstatus is zichtbaar als in wachtrij, bezig, voltooid of mislukt.

Dat is belangrijk omdat migratie geen afzonderlijk verdienmodel hoort te worden. Het moet deel uitmaken van onboarding.

TrekMail is opgebouwd rond e-mailhosting voor meerdere domeinen met vaste tarieven. Abonnementen beginnen bij $3.50 per maand. Het product omvat eigen domeinen, IMAP-mailboxen, catch-all-ondersteuning, eigen SMTP of inbegrepen SMTP afhankelijk van het abonnement, doorsturen van mailboxen, een migratietool en API-toegang op hogere niveaus. Er is een Nano-abonnement voor $0 en betaalde abonnementen kunnen met een gratis proefperiode van 14 dagen worden getest. Voor het gratis abonnement is geen betaalkaart nodig. Voor de proefperiode wel.

Voor kleine teams betekent dit dat ze e-mail kunnen verplaatsen zonder eerst een migratie-uitbreiding per gebruiker te kopen. Voor bureaus kan het migratieproces zo passen in hetzelfde beheermodel dat al nodig is voor mailboxeigendom, onboarding van klanten en terugkerende marge.

Als de kosten net zo belangrijk zijn als het gereedschap, vergelijk de abonnementen dan rechtstreeks op TrekMail-prijzen.

Een migratietool kiezen zonder er spijt van te krijgen

Kies een migratietool op basis van herstel na fouten, verwerking van duplicaten, maptoewijzing en logboeken. Negeer puur cosmetische dashboards. Als de tool niet bestand is tegen beperkingen, problematische berichten en nieuwe pogingen, kost hij meer tijd dan hij bespaart.

Gebruik deze checklist voordat je een keuze maakt:

1. Kan de migratietool bij een nieuwe uitvoering duplicaten overslaan?
2. Kan hij doorgaan nadat één beschadigd bericht is mislukt?
3. Kan hij mapnamen en scheidingstekens van naamruimten toewijzen?
4. Kan hij fouten per item tonen in plaats van alleen een samenvatting?
5. Kan hij moderne authenticatie en langdurige sessies verwerken?
6. Kan hij via IMAP migreren zonder na de overstap een afzonderlijk prijsmodel per gebruiker op te leggen?

Is een van de antwoorden nee, zoek dan verder.

De beste migratietool is niet degene met de mooiste interface. Het is de tool die ervan uitgaat dat fouten zullen optreden en die kan herstellen zonder de mailbox te beschadigen. Dat is de norm. Alles daaronder is een storing die nog moet gebeuren.