Warum eine Migrationscheckliste unverzichtbar ist
E-Mail-Migration ist einer der riskantesten IT-Vorgänge, die eine Organisation durchführen kann. Man verschiebt Jahre professioneller Kommunikation zwischen Plattformen, und ein einziges Versäumnis kann die Metadaten aller Postfächer beschädigen. Das häufigste Opfer? Die E-Mail-Daten. Nach der Migration riskiert jede E-Mail, das Migrationsdatum statt des ursprünglichen Sende- oder Empfangsdatums anzuzeigen.
Diese Checkliste deckt jede Phase des Migrationsprozesses ab. Befolgen Sie diese Schritte, um das Risiko von Datumsverfälschungen und anderen Metadatenproblemen zu minimieren. Und wenn die Migration bereits abgeschlossen ist und Datumsprobleme aufgetreten sind - lesen Sie weiter.
Phase 1: Planung vor der Migration
Postfächer inventarisieren
Bevor Sie ein Migrationswerkzeug anfassen, dokumentieren Sie jedes zu migrierende Postfach. Erfassen Sie die Gesamtzahl der Postfächer, die ungefähre E-Mail-Anzahl pro Postfach, den Datumsbereich der ältesten E-Mails und geteilte Postfächer oder Verteilergruppen. Dieses Inventar bestimmt, welches Migrationswerkzeug verwendet wird, wie lange die Migration dauert und welcher Tarif für eventuelle Korrekturen nach der Migration gilt.
Das richtige Migrationswerkzeug wählen
Nicht alle Migrationswerkzeuge behandeln Daten gleich. Informieren Sie sich, wie jedes Werkzeug die IMAP-INTERNALDATE-Erhaltung handhabt und ob es während des APPEND-Prozesses "Received"-Header hinzufügt. Gängige Werkzeuge sind BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO und der native Import des Exchange Admin Centers. Jedes dieser Werkzeuge kann Datumsprobleme verursachen, da das IMAP-Protokoll selbst verlangt, dass der Zielserver beim Einfügen einen "Received"-Header hinzufügt. Aber einige Werkzeuge bewahren das INTERNALDATE besser als andere. Für ein besseres Verständnis der INTERNALDATE-Funktionsweise siehe IMAP INTERNALDATE: Warum Daten kaputtgehen.
Alles sichern
Erstellen Sie eine vollständige Sicherung jedes Postfachs vor der Migration. Diese Sicherung dient sowohl als Sicherheitsnetz als auch als Referenzpunkt zur späteren Datumsüberprüfung. Für Google Workspace nutzen Sie Google Takeout oder ein Drittanbieter-Sicherungswerkzeug. Für Microsoft 365 nutzen Sie Exchange Online Backup oder PST-Export. Für IMAP-Server nutzen Sie imapsync für eine lokale Kopie.
Speichern Sie die Sicherungen an einem vollständig separaten Ort von den Quell- und Zielservern.
Originaldaten dokumentieren
Wählen Sie 10 bis 20 E-Mails pro Postfach über verschiedene Datumsbereiche verteilt (die ältesten, neuesten und mehrere dazwischen). Notieren Sie das "Empfangsdatum", "Sendedatum" und die Roh-Header jeder E-Mail. Diese Referenz-E-Mails werden zu Ihrer Verifizierungsbasis nach der Migration. Machen Sie einen Screenshot des nach Datum sortierten Postfachs, um die ursprüngliche chronologische Ordnung visuell zu dokumentieren.
Phase 2: Testmigration
Zuerst ein Testpostfach migrieren
Starten Sie niemals eine vollständige Migration ohne vorherigen Test.
Erstellen Sie ein Testpostfach mit einer repräsentativen E-Mail-Stichprobe (mindestens 100, über mehrere Jahre verteilt). Führen Sie die Migration nur für dieses Postfach durch und untersuchen Sie die Ergebnisse gründlich, bevor Sie fortfahren. Dieser Test deckt Datumsprobleme, Encoding-Fehler, Anhang-Verarbeitungsfehler und Ordnerstrukturabweichungen auf, bevor sie die Produktionspostfächer betreffen.
Daten im Testpostfach überprüfen
Überprüfen Sie nach der Migration des Testpostfachs sofort die Daten. Öffnen Sie das Postfach im E-Mail-Client, den die Endbenutzer tatsächlich verwenden werden (Outlook, Apple Mail, Thunderbird oder Webmail-Oberfläche). Vergleichen Sie die angezeigten Daten mit den in Phase 1 dokumentierten Referenz-E-Mails. Überprüfen Sie sowohl "Empfangs-" als auch "Sendedaten". Öffnen Sie die Roh-Header mehrerer E-Mails und suchen Sie nach neu hinzugefügten "Received"-Headern mit dem Migrationszeitstempel.
Wenn die Daten im Testpostfach falsch sind, werden sie in allen Postfächern falsch sein. Stoppen Sie alles und lösen Sie das Problem, bevor Sie mit der vollständigen Migration fortfahren.
Mit mehreren E-Mail-Clients testen
Verschiedene E-Mail-Clients zeigen Daten unterschiedlich an. Die Gmail-Weboberfläche kann korrekte Daten zeigen (sie verwendet den "Date"-Header), während Outlook das Migrationsdatum zeigt (es bevorzugt den "Received"-Header). Testen Sie mit jedem Client, den die Benutzer der Organisation verwenden, insbesondere Outlook Desktop, Outlook im Web, Apple Mail, Thunderbird und allen mobilen E-Mail-Apps.
Phase 3: Migrationsausführung
Konfiguration des Migrationswerkzeugs
Konfigurieren Sie das Migrationswerkzeug so, dass das INTERNALDATE bestmöglich erhalten bleibt. Verwenden Sie in imapsync die entsprechenden Flags zur INTERNALDATE-Setzung auf dem Ziel. Überprüfen Sie in BitTitan MigrationWiz die erweiterten Einstellungen für Datumsbehandlungsoptionen. Diese Einstellungen verhindern nicht vollständig die "Received"-Header-Probleme, reduzieren aber die Schwere der Datumsprobleme in einigen Clients. Dokumentieren Sie jede verwendete Konfigurationseinstellung, um die Migration bei Bedarf reproduzieren zu können.
In Chargen migrieren
Migrieren Sie nicht alle Postfächer gleichzeitig. Migrieren Sie in Chargen von 10 bis 20 Postfächern und überprüfen Sie die Daten nach jeder Charge. Wenn eine Charge Datumsprobleme zeigt, erkennen Sie das, bevor die gesamte Organisation betroffen ist. Übrigens reduziert die Migration in Chargen auch die Last auf Quell- und Zielservern und verringert das Risiko von Timeouts oder Verbindungsfehlern, die zu unvollständigen Migrationen führen können.
Fortschritt überwachen
Verfolgen Sie den Migrationsfortschritt für jedes Postfach. Erfassen Sie Startzeit, Endzeit, Anzahl migrierter E-Mails und etwaige Fehler. Migrationswerkzeuge stellen in der Regel Protokolle bereit - bewahren Sie sie für jedes Postfach auf. Wenn Datumsprobleme später entdeckt werden, helfen die Protokolle, genau zu identifizieren, welche Migrationscharge und welche Einstellungen verwendet wurden.
Phase 4: Überprüfung nach der Migration
Daten sofort überprüfen
Überprüfen Sie die E-Mail-Daten innerhalb von 24 Stunden nach der Migration. Öffnen Sie für jede Charge 5 bis 10 Postfächer und vergleichen Sie die Daten mit den Referenzen vor der Migration. Wenn die Daten falsch sind, dokumentieren Sie das Ausmaß des Problems (wie viele Postfächer betroffen, wie viele E-Mails pro Postfach), solange die Informationen frisch sind.
Alle Ordnertypen prüfen
Datumsprobleme können verschiedene Ordner unterschiedlich betreffen. Überprüfen Sie die Daten in Posteingang, Gesendete Elemente, Entwürfe und allen benutzerdefinierten Ordnern oder Labels. Einige Migrationswerkzeuge verarbeiten Ordner sequentiell, und Fehler in einem Ordner bedeuten nicht zwangsläufig Fehler in den anderen.
Suche und Sortierung überprüfen
Öffnen Sie ein migriertes Postfach, sortieren Sie nach Datum und bestätigen Sie, dass die chronologische Ordnung dem Original entspricht. Suchen Sie E-Mails nach Datumsbereich und prüfen Sie, ob die Ergebnisse korrekt sind. Testen Sie alle automatisierten Regeln oder Filter, die von Empfangsdaten abhängen. Wenn die Organisation Compliance- oder eDiscovery-Werkzeuge nutzt, überprüfen Sie, ob datumsbasierte Abfragen korrekte Ergebnisse liefern.
Häufige Fehler, die Datumsprobleme verursachen
Die Testmigration überspringen
Der häufigste Fehler ist, alle Postfächer ohne vorherigen Test zu migrieren. Wenn Datumsprobleme entdeckt werden, sind alle Postfächer betroffen und der Quellserver wurde möglicherweise bereits abgeschaltet. Eine 30-minütige Testmigration kann Wochen an Nacharbeit ersparen. Warum darauf verzichten?
Hinzugefügte "Received"-Header ignorieren
Administratoren konzentrieren sich oft auf die INTERNALDATE-Erhaltung und vernachlässigen das "Received"-Header-Problem. Selbst wenn das INTERNALDATE korrekt gesetzt ist, sorgt der Migrations-"Received"-Header dafür, dass Outlook und andere Clients das falsche Datum anzeigen. Das ist die häufigste Quelle von Beschwerden nach der Migration. Lesen Sie Warum E-Mails nach der Migration falsche Daten zeigen für eine vollständige technische Erklärung.
Den Quellserver zu früh abschalten
Wenn Datumsprobleme nach dem Abschalten des Quellservers entdeckt werden, ist die Option einer erneuten Migration dahin. Halten Sie den Quellserver mindestens 30 Tage nach der Migration erreichbar (auch nur lesend). Das bietet eine Rückfalloption, falls später schwerwiegende Probleme auftreten.
Was tun, wenn die Daten bereits falsch sind
Wenn die Migration bereits durchgeführt wurde und die Daten falsch sind, ist das Problem reparabel. Der ursprüngliche "Date"-Header bleibt in jeder E-Mail erhalten, was bedeutet, dass die korrekte Datumsinformation weiterhin existiert. E-Mail-Daten können nach der Migration korrigiert werden, selbst Monate oder Jahre später.
Die proprietäre Korrektur-Engine von Redate.io verbindet sich mit dem Postfach und sucht nach E-Mails mit beschädigten Datumsmetadaten. Die mehrstufige Analyse-Pipeline identifiziert Migrationssignaturen, wendet gezielte Korrekturen an, während die Nachrichtenintegrität gewahrt wird (einschließlich S/MIME-Signaturen, Multipart-Strukturen und Nicht-ASCII-Header), und führt eine Integritätsprüfung bei jeder korrigierten E-Mail durch. Die Analyse ist kostenlos und zeigt genau, wie viele E-Mails betroffen sind. Die Originale werden 30 Tage in einem sichtbaren Sicherungsordner aufbewahrt.
Das manuell oder mit einem eigenen Skript zu versuchen ist verlockend, aber riskant. Sonderfälle wie PGP-verschlüsselte Nachrichten, beschädigte MIME-Grenzen, verschachtelte Multipart-Strukturen und Content-Transfer-Encoding-Abweichungen können E-Mails stillschweigend beschädigen, ohne dass man es bemerkt, bis es zu spät ist. Und wie verifiziert man, dass 10.000 korrigierte E-Mails alle intakt sind?
Bereit zu prüfen, ob Ihr Postfach Datumsprobleme hat? Starten Sie eine kostenlose Analyse mit Redate.io - keine Zahlung nötig, um zu sehen, wie viele E-Mails betroffen sind.