E-Mail sicher migrieren: Plan ohne Datenverlust

E-Mail ohne Datenverlust oder Ausfall migrieren

Bei einem Anbieterwechsel kopieren Sie keine statischen Dateien, sondern synchronisieren ein aktives System. Währenddessen kommen Nachrichten an, Nutzer ändern Daten und Metadaten verschieben sich. Fehler können geteiltes Routing und verlorene Mail verursachen.

Dieser Leitfaden bietet einen phasenweisen Plan für kleine Unternehmen mit DNS-Vorbereitung, IMAP-Synchronisation, Umschaltung und Prüfung danach. Vollständigkeit und Ausfallfreiheit sind dennoch nicht garantiert.

Warum E-Mail-Migrationen scheitern

Drei Versäumnisse verursachen viele Probleme. Wer sie früh kennt, kann Risiken reduzieren.

DNS-Cache: Ohne vorher reduzierte TTL können alte und neue Server bis zu 24 Stunden Mail erhalten.
Drosselung: Anbieter wie Google begrenzen IMAP laut beschriebenem Beispiel auf etwa 2,500 MB/day. Dann pausiert die Synchronisation.
Falscher Umfang: IMAP bewegt nur E-Mail. Kalender und Kontakte nutzen CalDAV/CardDAV oder proprietäre Formate und müssen separat migriert werden.

Phase 1: Bestandsaufnahme (T-Minus 7 Days)

Erstellen Sie vor dem Umzug ein technisches Inventar und verlassen Sie sich nicht auf Erinnerung.

Verborgene Identitäten erfassen

Eine Benutzerliste reicht nicht. Dokumentieren Sie alle Eingangspunkte:

• Aliasse: Empfängt john@ auch für sales@? Ein fehlender Alias kann Bounces verursachen.
• Verteiler: Sind team@ und info@ gemeinsame Postfächer oder Weiterleitungsgruppen?
• Weiterleitungen: Prüfen Sie serverseitige Regeln, besonders private externe Ziele, und erstellen Sie nur notwendige, zulässige Regeln neu.

Große Postfächer erkennen

Markieren Sie Postfächer über 10 GB. Ein 50 GB-Postfach braucht über IMAP Zeit. Microsoft 365 drosselt im beschriebenen Beispiel nach ungefähr 20 GB/day. Beginnen Sie bei diesen Nutzern mindestens 5 days vor der Umschaltung. Aktuelle Grenzen stehen im Google-Workspace-Migrationsleitfaden.

IMAP überträgt nur E-Mail

Werkzeuge wie imapsync und die TrekMail-Engine nutzen das IMAP-Protokoll (RFC 3501). IMAP überträgt nur E-Mail.

Kalender und Kontakte liegen in Exchange, CalDAV oder anderen Formaten. Exportieren Sie Kalender als .ics und Kontakte als .vcf oder .csv und prüfen Sie sie vor Kündigung des alten Kontos.

Phase 2: Infrastruktur vorbereiten (T-Minus 48 Hours)

Bereiten Sie zuerst das Ziel und die Leitungswege vor.

Die 300-Sekunden-Regel für DNS TTL

TTL bestimmt die Cachezeit. Bei 86,400 seconds (24 hours) können Resolver nach der Umstellung noch lange das alte Ziel verwenden.

Setzen Sie beim DNS-Anbieter, etwa Cloudflare, GoDaddy oder Route53, die MX-TTL auf 300 seconds, möglichst mindestens 24 hours vorher. Nicht alle Resolver halten sich exakt daran.

Ziel bereitstellen

Legen Sie Zielpostfächer an. TrekMail-Nutzer richten Domains und Nutzer im Dashboard ein. Konfigurieren Sie im Nano-Tarif gegebenenfalls BYO-SMTP für SES/Mailgun und testen Sie den Versand.

Stellen Sie autorisierte Quellzugänge bereit, etwa App-Passwörter oder Admin-Migrationszugänge, und behandeln Sie sie sicher.

Phase 3: Vorab-Synchronisation

Vermeiden Sie einen einzigen Komplettumzug. Etappen reduzieren das Risiko.

Schritt 1: Historischer Lauf (T-Minus 3 Days)

Synchronisieren Sie zunächst Mail älter als 7 days. Das kann ungefähr 95% des Volumens vorab bewegen. Ein fehlerhafter 2 GB-Anhang lässt sich dann früher untersuchen; Zielgrenzen können ihn weiterhin verhindern.

Achten Sie auf HTTP 429 und Drosselungsfehler. Verarbeiten Sie bei Bedarf nur 5 users gleichzeitig statt 50 und beachten Sie Anbieterlimits.

Schritt 2: Sperrphase (T-Zero, Friday Evening)

Informieren Sie Nutzer über den Zeitraum. Ein schreibgeschütztes Quellsystem kann verwaiste Änderungen reduzieren. Passwortänderungen sind nur mit Genehmigung und klarer Rückgabeplanung sinnvoll.

Schritt 3: Delta-Synchronisation

Starten Sie erneut, um die letzten 7 days und unterstützte Änderungen zu übernehmen. Auch wenn bereits 95% vorhanden sind, hängt die Dauer von Drosselung, Volumen und Fehlern ab. Löschungen sollten nicht ungeprüft gespiegelt werden.

Phase 4: Umschaltung

MX-Einträge wechseln

Aktualisieren Sie die MX-Einträge. Für TrekMail werden hier genannt:

Bei 300-second TTL kann Verkehr schnell wechseln, doch DNS-Caches und Warteschlangen verhindern eine Garantie für sofortige Umschaltung.

SPF- und DKIM-Authentifizierung

Aktualisieren Sie Authentifizierungsdaten beim Hostwechsel. Fehlende oder falsche Werte erhöhen das Spamrisiko, ohne dass korrekte Werte den Posteingang garantieren.

• SPF: Aktualisieren Sie TXT, zum Beispiel v=spf1 include:spf.trekmail.net -all.
• DKIM: Erzeugen Sie Schlüssel beim neuen Anbieter und veröffentlichen Sie die verlangten CNAME/TXT-Einträge.

Details finden Sie unter E-Mail auf eigener Domain einrichten.

Zombie-Prüfung

Bleibt Google Workspace für Drive/Docs bestehen, kann interne Mail weiter in Gmail landen. Deaktivieren Sie Gmail für betroffene Nutzer oder konfigurieren Sie nach Prüfung Split Delivery.

Phase 5: Prüfung

Verlassen Sie sich nicht nur auf Nutzerfeedback. Prüfen Sie messbar und dokumentiert.

Elementanzahl statt Größe

Kompression unterscheidet sich. Vergleichen Sie Elementzahlen je Ordner:

Unter 1% kann durch beschädigte Elemente entstehen, sollte aber dokumentiert werden. Über 5% erfordert Untersuchung; auch kleinere Abweichungen können bei wichtigen Nachrichten relevant sein.

Ordnerhierarchie

Prüfen Sie tiefe Pfade wie Clients/2024/Project A/Invoices/Paid und Namensräume wie INBOX.Sent gegenüber Sent.

Häufige Fehler beheben

Integrierte TrekMail-Migration

TrekMail kann unterstützte IMAP-Läufe, Wiederholungen, Drosselung und DNS-Abläufe vereinfachen, beseitigt aber Providerlimits und Prüfpflichten nicht.

Für kleine Unternehmen (1 bis 50 Users)

Die integrierte Engine verbindet unterstützte Anbieter wie Gmail, Outlook oder cPanel. Sie verarbeitet Wiederholungen, Limits und Deduplizierung nach aktueller Funktionalität. Prüfen Sie Ergebnisse und nicht unterstützte Daten separat.

Für Agenturen (100+ Domains)

Für mehrere Kunden gibt es Sammeloperationen, gemeinsamen Speicher über Domains und Flatrates gemäß aktuellem Tarif.

Laut beschriebener Preisstruktur bieten Bezahltarife eine 14-day Testphase mit Karte; Nano benötigt keine Karte. Prüfen Sie aktuelle Bedingungen.

Fazit: E-Mail richtig migrieren

Bereiten Sie Daten vor, reduzieren Sie TTL auf 300 seconds, führen Sie Delta-Läufe aus und vergleichen Sie Elementzahlen. Gleichen Sie beide Seiten ab und behandeln Sie geschäftliche E-Mail-Anforderungen, Kalender und Kontakte separat.

Ein kostenloses TrekMail-Konto starten ermöglicht nach aktuellen Bedingungen den Zugriff auf das integrierte Werkzeug. Prüfen Sie Eignung, Grenzen und Resultate.