Bij een IMAP-migratie kunnen e-mailprojecten snel uit de hand lopen. Een verkeerde maptoewijzing, een verouderde DNS-cache of een onvoorziene Gmail-instelling kan een weekendstoring veroorzaken. Bereid je een verhuizing voor, lees dan eerst dit artikel en houd deze imapsync-gids voor beheerders bij de hand. Het doel: e-mail verplaatsen met minder risico op duplicaten en ongemerkt verlies, zonder onnodige gebruikerslicenties tijdens de voorbereiding.
Dat klinkt vanzelfsprekend, maar is het niet. E-mail is geen zipbestand. Het is een actief systeem met berichtstatus, clients, DNS, snelheidsbeperkingen en gebruikers die berichten blijven versturen terwijl je alles probeert te verhuizen. Daarom begint een serieuze IMAP-migratie bij de beperkingen van het protocol en niet bij beloften van leveranciers.
Koppel de kopieersnelheid los van de druk rond de omschakeling. Oude aanpak: vroeg licenties kopen, de verhuizing overhaasten en hopen dat het weekend voldoende is. Nieuwe aanpak: eerst de bestemming voorbereiden, in meerdere rondes migreren en gedeelde opslag inzetten voor grote mailboxen. TrekMail biedt multidomainhosting voor een vast tarief, gedeelde opslag en ingebouwde server-side import; controleer de beschikbare functies, quota en voorwaarden van je pakket voordat je de bestemming inricht.
Waarom een IMAP-migratie in de praktijk mislukt
Een IMAP-migratie kan mislopen doordat servers mappen, identificatoren en labels anders beschrijven. Het protocol kan e-mail verplaatsen, maar is niet ontworpen als een perfect systeem voor grootschalige replicatie. Op schaal leiden verschillen tot duplicaten, verlies van de mappenhiërarchie, snelheidsbeperkingen en nieuwe e-mail die op de oude server achterblijft.
De eerste valkuil is de UID-logica. IMAP identificeert berichten binnen een map met hun UID samen met UIDVALIDITY. Verandert UIDVALIDITY, dan mag een client de eerdere UID's niet meer als dezelfde generatie identificatoren gebruiken. Dit staat in RFC 9051. Het opnieuw opbouwen of herstellen van een mailbox kan zo'n wijziging veroorzaken; alleen hernoemen doet dat niet noodzakelijk. Een migratietool moet de wijziging herkennen om niet haar voortgang kwijt te raken en gegevens opnieuw te kopiëren.
De tweede valkuil is een verschil in naamruimte voor mappen. De ene host behandelt `INBOX.Sent` als een geneste map, terwijl een andere `INBOX/Sent` verwacht. Gmail voegt nog een laag toe door labels via IMAP als mappen te tonen. Zonder voorafgaand onderzoek kunnen gebruikers denken dat een deel van het bedrijfsarchief verdwenen is.
De derde valkuil is het labelmodel van Gmail. Eén bericht kan onder meerdere labels verschijnen, terwijl een gewone IMAP-bestemming mappen bewaart. Dat kan meerdere opgeslagen kopieën opleveren. Sluit All Mail echter niet standaard uit: daar kunnen gearchiveerde berichten staan die geen ander label hebben. Inventariseer de zichtbare mappen, test de toewijzing en controleer of alle te bewaren berichten worden meegenomen.
Voorbereiding: onderzoek de omgeving voordat je verhuist
Een veilige IMAP-migratie begint met een inventaris en niet met inloggegevens. Je hebt aantallen en grootten van mailboxen, afwijkende serviceaccounts, oude doorstuurregels en een korte lijst van gebruikers met verhoogd risico nodig. Door dit onderzoek over te slaan bespaar je geen tijd. Je verplaatst de onzekerheid alleen naar de dag van de omschakeling.
Begin bij de grootste mailboxen: oprichters die nooit iets verwijderen, financiële mailboxen met jaren aan pdf-bestanden en supportinboxen die archieven zijn geworden. Ze bepalen je planning en maken de beperkingen van prijzen per gebruiker zichtbaar. Eén mailbox van 60 GB kan op traditionele platforms een duurder pakket vereisen. Bij TrekMail kan zo'n mailbox meer gezamenlijke opslag gebruiken, mits je pakket en de beschikbare capaciteit dat toelaten. Controleer ook eventuele quota per mailbox.
Zoek daarna de verborgen accounts: gedeelde adressen, scanners, inboxen voor waarschuwingen en oude vervangers van distributielijsten die eigenlijk gewone accounts zijn. Vergeet je er een, dan kan belangrijke e-mail ongemerkt niet meer op de juiste plek aankomen.
Bepaal vóór de eerste synchronisatie hoe je beschadigde items behandelt. Beschadigde MIME-onderdelen, ongeldige headers en te grote bijlagen komen voor in oude mailopslag. Stopt de tool bij het eerste defecte object, dan kan de migratie blijven hangen op een bericht uit 2009. Laat een ronde alleen doorgaan met overslaan volgens vooraf goedgekeurd beleid. Registreer elk overgeslagen item en beoordeel herstel, een nieuwe poging of een expliciet geaccepteerde uitzondering.
| Te onderzoeken item | Waarom dit belangrijk is | Wat je vastlegt |
|---|---|---|
| Mailboxgrootte | Bepaalt de planning en volgorde van voorbereiding | Totaal aantal GB en items |
| Grote mailboxen | Tonen risico op quota en snelheidsbeperkingen | Alles boven 15-20 GB |
| Serviceaccounts | Kunnen na de omschakeling ongemerkt uitvallen | Eigenaar, toepassing en authenticatiemethode |
| Gedeelde mappen en labels | Kunnen toewijzingsfouten en duplicaten veroorzaken | Mapnamen, scheidingstekens en Gmail-labels |
| Beschadigde items | Kunnen de hele taak stoppen | Aantal, type en beleid voor overslaan |
Alles tegelijk tegenover vooraf voorbereiden
De hoofdstrategieën zijn alles tijdens de omschakeling verplaatsen, of oude e-mail vooraf kopiëren en afsluiten met een deltaronde. Alles tegelijk kan bij kleine omgevingen passen. Bij grotere volumes verlaagt voorbereiding de druk op de omschakeling.
Alles tegelijk klinkt overzichtelijk. Wijzig vrijdag de MX-records, migreer het hele weekend en hoop maandag dat de tellers overeenkomen. Bij kleine teams met weinig gegevens kan dat werken, maar bronlimieten en grote mailboxen kunnen de planning alsnog ondermijnen.
Vooraf kopiëren is gebruikelijk bij grotere projecten. Kopieer bijvoorbeeld e-mail ouder dan 30 dagen terwijl gebruikers op het oude systeem blijven. Verlaag tijdig de DNS-TTL, wijzig de MX-records en synchroniseer recente en nieuw bezorgde e-mail. Kies de leeftijdsgrens voor je project; zo verdeel je één groot risico over drie beheersbare taken.
Hier telt het prijsmodel van TrekMail. Bij Google Workspace of Microsoft 365 kunnen licenties voor doelmailboxen extra kosten opleveren tijdens parallel gebruik. Bij TrekMail kun je de bestemming vroeg inrichten en vooraf importeren binnen de voorwaarden van je pakket. De vermelde prijs vanaf $3.50 per maand is een omgerekend maandbedrag bij jaarlijkse facturering; controleer de actuele prijslijst. Een betaald pakket kun je 14 dagen uitproberen, mits je voldoet aan de actuele voorwaarden en toelatingscriteria. Nano is een afzonderlijk gratis pakket zonder kaart volgens de huidige voorwaarden; voor het versturen van berichten en antwoorden heb je een eigen SMTP-dienst nodig.
| Strategie | Geschikt voor | Belangrijkste risico | Oordeel |
|---|---|---|---|
| Alles tegelijk | Minder dan 10 gebruikers en weinig gegevens | Uitloop van het weekend | Te overwegen voor kleine taken |
| Vooraf voorbereiden | Teams, mkb, bureaus en MSP's | Vereist gedisciplineerde planning | Doorgaans de voorkeur |
Het veilige draaiboek voor IMAP-migratie
Een herhaalbaar draaiboek voor IMAP-migratie bestaat uit vijf delen: maak de bestemming, test de mapstructuur, kopieer oude e-mail, schakel DNS om en voer een deltaronde uit. Elke stap verkleint het mogelijke effect van problemen voordat je verdergaat.
- Maak eerst de doeldomeinen en mailboxen. De TrekMail-documentatie voor een domein toevoegen en IMAP-instellingen bevat waarden die je met het dashboard moet vergelijken. De documentatie toont `mail.trekmail.net` met prioriteit `10`; gebruik de actuele instellingen voor je domein.
- Voer een structuurtest uit. Maak mappen voordat je grote hoeveelheden gegevens kopieert. Verschillen tussen punten en schuine strepen worden dan zichtbaar wanneer een oplossing nog weinig kost.
- Voer de bulkronde voor oude e-mail uit. Beoordeel bij Gmail-bronnen `[Gmail]/All Mail` en Trash aan de hand van de inventaris en bewaareisen. Sluit ze pas uit nadat je hebt gecontroleerd dat alle benodigde berichten elders worden meegenomen, inclusief gearchiveerde berichten zonder andere labels.
- Verlaag bijvoorbeeld de MX-TTL naar 300 seconden, minimaal 24 uur vóór de wijziging. Dit is een planningsvoorbeeld, geen garantie dat caches zijn geleegd. Houd rekening met de eerdere TTL, ook van negatieve antwoorden, en controleer de bezorging op beide systemen.
- Wijzig de MX-records, controleer de DNS-antwoorden en voer een deltaronde uit met het overslaan van duplicaten. De importwerkwijze van TrekMail voorziet in controle op duplicaten bij herhaalde uitvoeringen. Dat vermindert het risico, maar garandeert geen perfecte deduplicatie: controleer de uitkomst.
Gebruik bij de DNS-controle opdrachten en geen aannames:
dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +shortTest bij een handmatige imapsync-migratie eerst de authenticatie en maptoewijzing. Het voorbeeld hieronder gebruikt wachtwoorden en configureert geen OAuth: het is niet klaar voor Exchange Online, en de Gmail-uitsluitingen vereisen controle. Gebruik in productie ondersteunde beveiligde bestanden voor inloggegevens of tokens, zodat geheimen niet in de opdrachtgeschiedenis of proceslijst staan.
imapsync \
--host1 old.mailhost.tld --user1 user@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 user@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--exclude '\[Gmail\]/All Mail|\[Gmail\]/Trash' \
--syncinternaldates \
--useheader 'Message-Id' \
--skipsizeEen voorbeeldrecord voor de DNS-omschakeling:
example.com. 300 IN MX 10 mail.trekmail.net.Gmail, Microsoft 365 en andere bijzondere situaties
Niet elke bron voor een IMAP-migratie gedraagt zich hetzelfde. Gmail brengt duplicatie door labels en bandbreedtelimieten. Microsoft 365 vraagt aandacht voor authenticatie: Exchange Online ondersteunt Basic Auth niet meer voor IMAP. Oudere lokale Exchange-installaties kunnen TLS-problemen hebben. Behandel elk type bron als een afzonderlijk risicoprofiel.
Google publiceert voor Workspace-omgevingen een dagelijkse IMAP-downloadlimiet van 2500 MB per account; controleer de actuele grens vóór de migratie. Plan voor een Gmail-account van 20 GB meerdere rondes met ruimte voor snelheidsbeperkingen en houd rekening met een meerdaagse migratie. De werkelijke duur hangt af van de dienst en de berichten, niet alleen van de omvang.
Microsoft 365 vraagt een andere aanpak. Inloggen op Exchange Online via IMAP met alleen een gebruikersnaam en wachtwoord wordt niet meer ondersteund. Je tool moet OAuth en de vereiste toestemmingen afhandelen. Een algemene instelling voor moderne authenticatie is niet genoeg: test tokens, rechten en verbindingen vooraf en bereid een toegestane alternatieve migratieroute voor.
Conceptueel voorbeeld: een Gmail-mailbox van 12 GB waarin Inbox, Project, Important en All Mail via IMAP zichtbaar zijn, is niet noodzakelijk een verzameling onafhankelijke mappen van 12 GB. Labels kunnen dezelfde berichten meermaals tonen en zo extra opgeslagen kopieën op de bestemming opleveren.
Omvat je project de introductie van veel gebruikers na de verhuizing, stem dit dan vóór de omschakeling af op het maken van mailboxen en toegangsbeheer. TrekMail heeft draaiboeken voor e-mailaccounts in bulk maken en e-mail voor klanten beheren. Ook inrichtingsfouten kunnen de migratie ontregelen.
Controle: tel items en geen gigabytes
Het aantal items per map en mailbox is een nuttige controle, maar bewijst op zichzelf geen volledige migratie. Vergelijk ook maptoewijzing, berichtidentiteit, headers, datums, vlaggen en steekproeven van de inhoud; zoek naar onverwachte duplicaten. Providers berekenen MIME-overhead, compressie en deduplicatie anders. Grootte helpt bij de planning, maar is zwak bewijs van succes.
Vergelijk na elke ronde de aantallen van bron en bestemming. Meldt de bron 14,200 items en de bestemming 14,195, dan kan een rapport met vijf beschadigde berichten het verschil verklaren, maar niet automatisch rechtvaardigen. Beoordeel die berichten, probeer herstel of laat uitzonderingen expliciet goedkeuren en rond de overige controles af voordat je de verhuizing voltooid noemt. Meldt de bestemming 10,000, stop dan en onderzoek het verschil: een vergelijkbare opslaggrafiek is niet voldoende.
Neem minstens 48 uur controle van de oude server na de MX-omschakeling op in je planning. Dat tijdvak bewijst niet dat alle clients en afzenders zijn overgestapt. Apparaten met vaste instellingen, printers, CRM-systemen en oude contactformulieren kunnen de oude server blijven gebruiken. Behoud de benodigde routering en monitoring totdat deze gevallen zijn gecontroleerd, vergelijk nieuw ontvangen berichten en voer aanvullende deltarondes uit totdat alle nieuwe e-mail is gecontroleerd en meegenomen.
Maakt de verhuizing deel uit van een bredere opschoning, denk dan ook na over je toekomstige beheermodel: hoeveel domeinen, mailboxen en clients moet je beheren? TrekMail kan bij multidomainbeheer passen als functies en quota aan je eisen voldoen. Vergelijk het met de grote pakketten op basis van je eigen behoeften. Dat is ook het thema van e-mailhosting voor meerdere domeinen en de kostenafwegingen in zakelijke e-mail.
Conclusie: beheers het risico zonder het project stil te zetten
Een IMAP-migratie vraagt geduld, een goede volgorde en controle. Kopieer niet sneller dan de bron aankan. Verminder onzekerheid vóór de omschakeling, kies uitsluitingen na controle op volledige berichtdekking, houd rekening met DNS-caches en vul aantallen aan met controles van inhoud en metadata.
TrekMail biedt multidomainbeheer, gedeelde opslag, server-side import en standaard IMAP-toegang. Controleer de pakketvoorwaarden en test de werkwijze op een steekproef. Zo kun je oude e-mail vooraf verplaatsen en deltarondes plannen met minder druk op de uiteindelijke omschakeling.
Begin bij de documentatie en bereid de bestemming voor. Zoek je een vast tarief voor deze voorbereiding, bekijk dan de actuele functies en voorwaarden op trekmail.net.