Heb je een controlelijst voor e-mailmigratie nodig, begin dan met deze regel: e-mail verhuizen is geen kwestie van mappen slepen. Het is een actief systeem met veranderende berichtstatussen, aliassen, doorstuuradressen, snelheidsbeperkingen, defecte clients en gebruikers die tijdens je werk blijven mailen. Daarom mislukken slordige omschakelingen. Bepaal je nog waar de e-mail na de verhuizing moet staan, lees dan eerst zakelijke e-mail voor kleine bedrijven. Weet je al dat migratie nodig is, gebruik dan dit draaiboek en houd de verhuizing voorspelbaar.
Het probleem is eenvoudig. De meeste teams kopiëren e-mail, wijzigen MX en hopen op een goede afloop. Maandag blijken er items te ontbreken: het archief van de oprichter, het doorstuuradres voor facturen en de gedeelde mailbox waarop eigenlijk vijf mensen met één account inlogden. Deze controlelijst voorkomt dat door inventarisatie, voorbereiding, controle, nieuwe pogingen en terugdraaien in één operationeel document vast te leggen.
| Aanpak | Oude methode | Nieuwe methode |
|---|---|---|
| Planning | Alles in één weekend kopiëren | Inventariseren, voorbereiden, omschakelen, controleren en de bron vergrendelen |
| Succescriterium | De mailboxgrootte lijkt ongeveer gelijk | Aantallen items, foutlogboeken en testberichten komen overeen |
| Foutafhandeling | Opnieuw proberen totdat iemand klaagt | Wachttijd, eigenaar en terugvaltrigger per fout vastleggen |
| Nazorg | Oude e-mail dagenlang actief laten | Zombietoegang blokkeren en defecte clients snel opnieuw instellen |
Controlelijst voordat je één bericht kopieert
Een controlelijst voor e-mailmigratie begint met inzicht. Voordat je één byte verplaatst, heb je een programmatisch overzicht nodig van mailboxen, aliassen, doorstuurregels, mailboxgroottes en beperkingen aan de bronkant. Is de inventarisatie zwak, dan wordt elke latere stap trager, riskanter en duurder.
Vertrouw niet op exports van personeelszaken of het werkblad dat de klant vorige maand stuurde. Haal gegevens uit het bronplatform en bouw een inventaris die vijf vragen beantwoordt:
- Welke mailboxen bestaan en welke ontvangen nog e-mail?
- Welke aliassen en functionele accounts horen bij die mailboxen?
- Welke gebruikers wijken sterk af in opslaggebruik?
- Welke doorstuurregels voor inbox, transport of mailbox zijn actief?
- Welke accounts zijn eigenlijk gedeelde operationele adressen en geen persoonlijke mailboxen?
Dat laatste punt is belangrijker dan vaak wordt toegegeven. invoices@, support@ en hello@ lijken tot de omschakeling vaak gewone mailboxen. Dan weet niemand wie verantwoordelijk is, welk apparaat nog ingelogd staat of waar antwoorden zijn gebleven.
Voer ook een controle op vervuilde gegevens uit. Zoek naar ongeldige MIME, te grote bijlagen en onzinnige mappenstructuren. IMAP kan veel verplaatsen, maar zet beschadigde brongegevens niet om in schone doelgegevens. Houd ook rekening met wat IMAP slecht of helemaal niet verplaatst. Het migratieproces van TrekMail behandelt uitsluitend e-mail, dus agenda's en contacten vereisen een afzonderlijk plan. Het overzicht van IMAP-migratie van TrekMail is daar duidelijk over.
Voorbeeld: een mailbox heeft 14,200 items bij de bron, maar twee berichten zijn beschadigd en één bijlage van 80 MB overschrijdt het beleid van de bestemming. Zegt je draaiboek alleen dat de grootte goed lijkt, dan mis je dit. Vereist het aantallen plus beoordeling van het foutenlogboek, dan vind je het voordat gebruikers dat doen.
Controlelijst voor het ontwerp van de omschakeling
Je controlelijst moet de migratiearchitectuur kiezen voordat iemand een weekend plant. Kleine mailboxen kunnen alles in één keer verhuizen. Echte bedrijven kunnen dat meestal niet. Zet historische e-mail vooraf klaar, laat recente wijzigingen over voor de laatste verschilronde en wijzig DNS pas wanneer de traagste mailboxen grotendeels gereed zijn.
Er zijn drie gebruikelijke patronen:
| Patroon | Geschikt voor | Belangrijkste risico |
|---|---|---|
| Alles tegelijk | Zeer kleine teams met lichte mailboxen | Geen buffer als snelheidsbeperking of beschadiging op de omschakelavond optreedt |
| Voorbereiden plus verschil | De meeste migraties voor mkb en MSP | Vereist gedisciplineerde logboeken en een tweede ronde |
| Hybride | Grote Exchange-omgevingen | Complexiteit die de meeste kleine teams niet nodig hebben |
Voor de meeste lezers is voorbereiden plus een verschilronde de juiste keuze. Een praktische tijdlijn ziet er zo uit:
- T-minus 14 days: verplaats oude e-mail eerst en identificeer trage mailboxen.
- T-minus 7 days: controleer aliassen, doorstuurregels en de toewijzing van doelmailboxen.
- T-minus 2 days: verlaag de DNS-TTL, test verificatie en beoordeel foutlogboeken.
- T-zero: wijzig MX, werk SPF en DKIM bij, voer de verschilronde uit en herstel clients.
- T-plus 1 day: controleer aantallen, test inkomende en uitgaande e-mail en schakel oude toegang uit.
Een fout in DNS onderbreekt de mailstroom. Verlaag de TTL minstens 48 uur vooraf en vergelijk de doelrecords met de vereiste DNS-records van TrekMail.
example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
# DKIM value is generated per domain in the TrekMail dashboard.Gedurende de eerste 24 tot 48 uur na de MX-wijziging kan een tijdelijk DMARC-beleid met p=none voorkomen dat je eigen omschakeling berichten afwijst terwijl caches worden bijgewerkt. Zodra de verhuizing stabiel is, schakel je handhaving weer in. Dat is nog belangrijker als je veel e-mail naar Gmail stuurt. De richtlijnen van Google voor afzenders verplichten bulkafzenders tegenwoordig tot SPF, DKIM, uitlijning, TLS en DMARC.
Controlelijst voor voorbereiding en verschilsynchronisatie
Het midden van een controlelijst draait om fysieke beperkingen en niet om optimisme. IMAP kopieert berichten map voor map, terwijl grote providers bandbreedte en snelheid beperken. Je moet oudere e-mail vroeg verplaatsen, nieuwe pogingen beheersen en de laatste verschilronde klein genoeg maken om binnen het omschakelvenster te voltooien.
Hier lopen veel migraties vast. IMAP vertrouwt op berichtidentificatoren en mailboxstatus. RFC-gedrag rond UID's en UIDVALIDITY in RFC 3501 verklaart waarom opnieuw geïndexeerde of beschadigde mappen problematische synchronisatie kunnen uitlokken. Ondersteunt je tool het overslaan van duplicaten of vergelijking op inhoud, gebruik die opties dan. De importwizard van TrekMail bevat een optie om duplicaten over te slaan. De actuele stappen staan in Een migratie starten in het dashboard.
Voor beheerders die vóór productie met opdrachtregeltools testen, is deze aanvullende gids over imapsync handig.
imapsync \
--host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--syncinternaldates \
--exclude 'Calendar|Contacts' \
--skipsize
Bereken de bandbreedte voordat je belooft in een weekend klaar te zijn. Google publiceert IMAP-bandbreedtelimieten voor Gmail, waaronder een dagelijkse IMAP-downloadlimiet van 2,500 MB per account. Microsoft werkt anders, maar is niet vriendelijker. Volgens Microsoft varieert de migratiesnelheid en wordt deze beïnvloed door dienstbeperkingen. Daarom kan één reusachtige mailbox je planning verwoesten als je haar te laat ontdekt.
Houd de bestemming ook realistisch. TrekMail is uitsluitend IMAP en geen volledig kantoorpakket. Dat is tijdens een mailmigratie een voordeel, omdat de reikwijdte helder blijft: verplaats de e-mail, controleer de e-mail en behandel agenda's en contacten apart, zodat foutgebieden niet door elkaar lopen.
Controlelijst voor verificatie na de DNS-wijziging
Een solide controlelijst behandelt verificatie als afzonderlijke fase en niet als een korte blik op de mailboxgrootte. Grootte misleidt. Codering verandert, platforms behandelen bijlagen anders en opslagberekeningen aan de serverkant verschillen. Aantallen, steekproeven, testberichten en beoordeling van fouten laten zien of de e-mail werkelijk is overgekomen.
Gebruik een eenvoudige controlematrix voor elke mailboxcategorie: leidinggevenden, gedeelde accounts, gewone gebruikers en gebruikers met grote mailboxen.
| Controle | Wat je vergelijkt | Voorwaarde voor slagen |
|---|---|---|
| Aantal items | Maptotalen bij bron en bestemming | Exact gelijk of verschillen verklaard in foutlogboeken |
| Mailstroom | Extern inkomend, extern uitgaand en intern verkeer | Alle drie werken en komen in de verwachte mailbox aan |
| Aliassen | Antwoord- en ontvangsttests voor elke alias | Geen bounce en bezorging in de juiste mailbox |
| Doorsturen | Bekende bedrijfskritieke doorstuurregels | Regels opnieuw gemaakt en gedocumenteerd |
| Clienttoegang | Outlook, Apple Mail en mobiele clients | Nieuw profiel of opnieuw toevoegen werkt zonder oude bronverificatie |
De controlelijst moet ook een stap voor zombiemailboxen bevatten. Nadat de verschilronde is voltooid, sluit je gebruikerstoegang tot het oude platform af. Anders kan een verouderde telefoon of een oud Outlook-profiel nog via de bron verzenden en ontvangen, waarna berichten daar achterblijven.
De clientinstellingen van TrekMail zijn duidelijk: IMAP-host imap.trekmail.net, poort 993 en het volledige e-mailadres als gebruikersnaam. POP3 wordt niet ondersteund. De exacte waarden staan in de gids voor IMAP- en SMTP-instellingen van TrekMail. Blijft Outlook vasthouden aan de oude server, stop dan met repareren en maak een nieuw profiel.
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
Controlelijst voor nieuwe pogingen, logboeken en terugdraaien
Het laatste derde deel van de controlelijst bepaalt wat er gebeurt als het plan fout loopt. Je hebt regels voor nieuwe pogingen, logboekvelden, verantwoordelijken voor escalatie en een drempel voor terugdraaien nodig voordat de eerste mailbox start. Bedenk je deze onder druk, dan neem je slechte beslissingen.
Het logboek moet mailbox, map, tijdstempel, bronserver, doelserver, geprobeerd aantal items, gekopieerd aantal items, gekopieerde bytes, aantal pogingen, eindstatus en een leesbare fout bevatten. Deel fouten daarna snel in:
| Fout | Betekenis | Actie van de beheerder |
|---|---|---|
| Verificatiefout | Verkeerd wachtwoord, app-wachtwoord ontbreekt of bronlogin geblokkeerd | Inloggegevens herstellen, één mailbox testen en batch hervatten |
| Verbinding geweigerd | Verkeerde poort, SSL-verschil, firewallblokkade of probleem met bronhost | Host en poort 993 controleren en handmatig testen vóór een nieuwe poging |
| Snelheidsbeperking of wachttijd in 429-stijl | De provider beperkt de aanvragen | Gelijktijdigheid verlagen, 5 tot 10 minuten wachten en langzaam hervatten |
| Stroom duplicaten | Map opnieuw geïndexeerd of migratiestatus verschoven | Batch stoppen, duplicaten overslaan en alleen getroffen mappen opnieuw uitvoeren |
| Recente e-mail ontbreekt | Verschilronde was onvolledig of oude clients bleven naar de bron schrijven | Laatste verschilronde herhalen en toegang tot de bron direct uitschakelen |
Terugdraaien betekent niet dat je alles terugzet omdat één gebruiker klaagt. Een serieuze controlelijst bepaalt vooraf de triggers. Goede triggers zijn brede storingen in inkomende e-mail na de MX-wijziging, grote onverklaarde verschillen in kritieke mailboxen of een verificatiefout op de bestemming die de hele omgeving blokkeert. Slechte triggers zijn één verouderd mobiel apparaat of een gebruiker die het wachtwoord nooit heeft bijgewerkt.
Als terugdraaien nodig is, houd het dan beperkt. Herstel eerst de mailstroom, communiceer één statusbericht en bewaar alle logboeken. Herstart niet tegelijk drie tools en maak de situatie niet erger dan de oorspronkelijke storing.
Waarom deze controlelijst beter werkt met TrekMail
Deze controlelijst wordt eenvoudiger wanneer het doelplatform voor e-mail is gebouwd en niet voor gebundelde prijzen per gebruiker. De oude aanpak is per gebruiker betalen voor een pakket dat je nauwelijks gebruikt en migratie als bijzaak behandelen. De nieuwe aanpak is verhuizen naar een platform dat e-mail centraal stelt, met voorspelbare opslag, helder DNS en een passende IMAP-route.
TrekMail past goed bij dit model. Het ondersteunt eigen domeinen, IMAP-mailboxen, catch-all, doorsturen van mailboxen, migratie aan de serverkant, een wizard voor SPF/DKIM/DMARC, eigen of inbegrepen SMTP en een API. Betaalde pakketten beginnen op Starter bij $3.50 per maand en bevatten de ingebouwde migratietool. Voor het testen van betaalde functies bestaat een gratis proefperiode van 14-day waarvoor een creditcard nodig is. Wil je zonder kaart beginnen, dan blijft Nano gratis.
De operationele winst bestaat uit gedeelde opslag en multidomainbeheer voor een vast tarief. Eén buitensporige mailbox dwingt niet het hele bedrijf tot licentiekosten per gebruiker. Dat is belangrijk voor bureaus, MSP's en iedereen die functionele accounts op veel domeinen beheert. Past dat bij je omgeving, lees dan de visie van TrekMail op e-mailhosting voor meerdere domeinen. Bekijk voor prijzen en geschikte pakketten direct de prijzen van TrekMail.
Ook de uitvoering is overzichtelijker. Je voegt het domein toe, maakt de doelmailbox, voert de IMAP-migratie aan de serverkant uit, controleert DNS en schakelt de clients om. Geen omwegen via POP3 en geen ondoorzichtige eigen connector. Alleen standaard IMAP en SMTP met expliciete instellingen.
Conclusie: houd de controlelijst saai
De beste controlelijst voor e-mailmigratie is de lijst die niemand zich een maand later herinnert. Inventariseer de bron, bereid oude e-mail voor, wijzig DNS bewust, voer de verschilronde uit, controleer aantallen, sluit zombietoegang af en houd terugdraaien beperkt. Dan verandert migratie van een gok in normale bedrijfsvoering, precies zoals productie-e-mail hoort te werken.
