BitTitan MigrationWiz: Falsche E-Mail-Datumsangaben korrigieren

Was BitTitan MigrationWiz mit E-Mail-Datumsangaben macht

Die Migration wurde letzten Freitag abgeschlossen. 47 Postfächer von On-Prem Exchange nach Microsoft 365 verschoben, alles grün im MigrationWiz-Dashboard. Dann kommt der Montagmorgen und das erste Ticket: "Alle meine E-Mails zeigen den 28. März 2026."

Jede einzelne Nachricht. Jahre an Korrespondenz, Kundenangebote aus 2019, Rechnungen aus 2021, alles mit dem Migrationsdatum gestempelt. Das MigrationWiz-Protokoll zeigt, dass alles erfolgreich übertragen wurde (und technisch gesehen stimmt das auch). Aber die Daten sind weg.

BitTitan MigrationWiz gehört zu den am häufigsten genutzten Werkzeugen für Cloud-to-Cloud-E-Mail-Migrationen. Es übernimmt Exchange zu Microsoft 365, Google Workspace zu Exchange, Cross-Tenant-Umzüge und vieles mehr. Das Werkzeug selbst funktioniert gut für seinen Zweck. Das Datumsproblem ist kein Fehler in MigrationWiz. Es kommt auf eine Sache an: das Datum, das jede Kopie trägt, wenn sie in das neue Postfach geschrieben wird.

Wo das falsche Datum wirklich liegt

Wenn MigrationWiz eine E-Mail von der Quelle zum Ziel überträgt, verwendet es das IMAP-Protokoll (oder Exchange Web Services, je nach Endpoint-Typ). Das Zielsystem behält das Datum, das es erhält: Microsoft 365, Outlook.com und Gmail bewahren das Originaldatum, wenn die Kopie es mitträgt. Zeigen also alle E-Mails das Migrationsdatum, liegt es an dem Datum, das MigrationWiz übergeben hat oder nicht übergeben hat.

So sehen die Header einer dieser E-Mails nach einer MigrationWiz-Migration noch aus:

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

Der ursprüngliche Date:-Header von 2019 ist noch vorhanden, ebenso die ursprüngliche Received:-Kette. Und in Microsoft 365 zeigt Outlook als Empfangsdatum den eigenen Eintrag des Postfachs für den Eingang jeder E-Mail an: Hat MigrationWiz das Originaldatum nicht übergeben, steht dort der 28. März 2026.

Der INTERNALDATE-Wert (der Zeitstempel, den der IMAP-Server zum Sortieren verwendet) ist das Datum, das die Kopie erhalten hat. MigrationWiz versucht zwar, Datumsangaben zu erhalten, und Microsoft 365 behält das Datum, das es übergeben bekommt: Kommen die Datumsangaben trotzdem falsch heraus, war das für jede E-Mail übergebene Datum nicht das Originaldatum.

Warum das "Date Mapping" von MigrationWiz nicht ausreicht

BitTitan bietet eine "Date Mapping"-Funktion in den erweiterten Optionen von MigrationWiz an. Auf dem Papier klingt das nach der Lösung. Tatsächlich steuert es jedoch, welcher Datumsbereich der Nachrichten migriert wird - nicht wie die Daten am Ziel erhalten bleiben.

Die Verwirrung ist nachvollziehbar. Die Einstellung trägt das Wort "Date" im Namen. Was sie aber wirklich tut, ist die Quellnachrichten nach Datumsbereich zu filtern, bevor die Migration beginnt. Eine Nachricht aus 2018 kommt trotzdem mit dem Migrationszeitstempel am Ziel an.

Hinzu kommt die Frage der IMAP- versus Exchange-Endpoints. Wenn MigrationWiz zwischen zwei Exchange-Servern über EWS (Exchange Web Services) migriert, funktioniert die Datumserhaltung besser, weil EWS mehr Kontrolle über die Nachrichtenmetadaten bietet. Auch über IMAP behält das Ziel das Datum, das es erhält: Entscheidend ist, ob das Originaldatum übergeben wird.

Manche Administratoren haben versucht, die Migration mit anderen Endpoint-Konfigurationen erneut durchzuführen, in der Hoffnung, dass der Wechsel von IMAP zu EWS die Datumsangaben rückwirkend korrigieren würde. Das funktioniert nicht. Die Nachrichten befinden sich bereits am Ziel mit falschen Datumsangaben. MigrationWiz erneut auszuführen würde nur Duplikate erzeugen.

MigrationWiz-Szenarien, die Daten zerstören

Nicht jede MigrationWiz-Migration verursacht Datumsprobleme. Das Problem hängt von der Endpoint-Kombination ab:

• Exchange (On-Prem) zu Microsoft 365 über IMAP: Daten gehen kaputt. Jede E-Mail erhält das Datum der Kopie.
• Google Workspace zu Microsoft 365: Daten gehen kaputt. MigrationWiz liest per IMAP von Google und schreibt ohne das Originaldatum nach M365.
• Exchange zu Exchange (EWS zu EWS): Datumsangaben bleiben in der Regel erhalten. Über EWS reist das Originaldatum mit der Nachricht mit.
• Beliebige Quelle zu Google Workspace über IMAP: Über IMAP behält Gmail das vom Werkzeug übergebene Datum und fügt nichts hinzu. Daten gehen nur kaputt, wenn dieses Datum nicht das Originaldatum ist, oder wenn die Kopie über Gmails Import-API läuft, die eine Received-Zeile mit dem Datum der Kopie hinzufügt.
• Cross-Tenant Microsoft 365: Hängt ganz von dem Datum ab, das die Methode übergibt.

Das MigrationWiz-Dashboard markiert keine Datumsprobleme. Alles wird als "Completed" angezeigt, weil die Nachrichten tatsächlich erfolgreich übertragen wurden. Der Inhalt ist intakt, Anhänge sind in Ordnung, die Ordnerstruktur ist erhalten. Nur die Daten haben sich geändert, und MigrationWiz erfasst das nicht als Migrationsfehler.

Die tatsächlichen Kosten falscher Daten nach MigrationWiz

Falsche E-Mail-Datumsangaben sind nicht nur ärgerlich. Für Organisationen, die mit BitTitan migriert haben, gehen die Konsequenzen über ein unordentliches Postfach hinaus.

Rechtsteams können E-Mails nicht als Beweise verwenden, wenn jede Nachricht das Migrationsdatum statt des tatsächlichen Sendedatums zeigt. Steuerprüfungen erfordern chronologische Nachweise der Kommunikation. Compliance-Rahmenwerke wie die DSGVO und GoBD verlangen eine genaue Aufbewahrung von Geschäftsunterlagen, und E-Mails mit verfälschten Zeitstempeln erfüllen diese Anforderung nicht.

Und dann gibt es die praktische Seite. Versuchen Sie mal, die Vertragsdiskussion vom November 2022 zu finden, wenn Ihr gesamtes Postfach März 2026 anzeigt. Nach Datum sortieren? Nutzlos. Nach Datumsbereich suchen? Liefert alles oder nichts.

Für MSPs, die MigrationWiz in Kundenumgebungen eingesetzt haben, entsteht ein Haftungsproblem. Der Kunde hat für eine Migration bezahlt. Er hat eine bekommen, aber sein E-Mail-Archiv ist für datumsbasierte Arbeitsabläufe effektiv kaputt.

Übrigens - ein MSP, von dem man gehört hat, hatte etwa 380 Postfächer für eine Anwaltskanzlei migriert. Drei Monate später entdeckte das Prozessteam der Kanzlei das Datumsproblem während der Beweisfindung. Jede E-Mail, die sie als Beweis vorlegen mussten, zeigte das Migrationsdatum. Der MSP musste erklären, warum 6 Jahre an zeitgestempelter Korrespondenz alle Juni 2025 anzeigten.

BitTitan MigrationWiz-Daten korrigieren

Der ursprüngliche Date:-Header befindet sich noch in jeder E-Mail. MigrationWiz berührt weder den Nachrichteninhalt noch die Original-Header. Ursache für das Anzeigeproblem ist das für jede Kopie vom Postfach erfasste Datum.

Redate.io verbindet sich mit dem Postfach (Google Workspace, Microsoft 365 oder IMAP), scannt nach E-Mails, die von der MigrationWiz-Migration betroffen sind, und korrigiert die Datumsmetadaten durch eine proprietäre mehrstufige Analyse-Pipeline. Die Korrektur zielt speziell auf die Metadaten-Ebene, wobei sie nicht wissen muss, welches Werkzeug die Migration durchgeführt hat: Sie findet die E-Mails, deren angezeigtes Datum nicht mit ihrem Originaldatum übereinstimmt.

Jede korrigierte E-Mail wird einzeln gegen das Original verifiziert. Die Prüfung kontrolliert Nachrichtenintegrität, Anhangerhaltung, Ordnerzuordnung und Threading. Original-E-Mails werden in einem sichtbaren Ordner Redate.io - Originals aufbewahrt, bis Sie sie selbst löschen.

Das Problem zu verstehen, ist eine Sache. 15.000 E-Mails zu korrigieren, ohne einen einzigen Anhang zu verlieren, S/MIME-Signaturen zu beschädigen oder multipart MIME-Grenzen zu korrumpieren, ist eine andere. Ein Skript, das bei 10 Testnachrichten im Labor funktioniert, wird die Randfälle eines Produktionspostfachs mit 7 Jahren Korrespondenz, PGP-verschlüsselten Nachrichten und RFC 2047 Non-ASCII-Headern nicht bewältigen.

Wie stellt man sicher, dass jede korrigierte Nachricht intakt ist? Dass das Threading noch funktioniert, dass Kalendereinladungen sich noch auflösen, dass der 47 MB große Anhang an dieser E-Mail von 2020 nicht beschädigt wurde? Redate.io macht das automatisch, für jede einzelne Nachricht. Und wenn etwas nicht stimmt, liegt das Original im Datensicherungs-Ordner bereit.

Der kostenlose Scan dauert etwa zwei Minuten. Er verbindet sich mit dem Postfach, identifiziert jede E-Mail, die mit dem MigrationWiz-Migrationsdatum gestempelt ist, und zeigt die genaue Anzahl und die Kosten an, bevor Sie irgendetwas bezahlen. Keine Kreditkarte, keine Verpflichtung.

Plattformspezifische Korrekturanleitungen für BitTitan

Der Korrekturprozess variiert je nachdem, wohin MigrationWiz Ihre E-Mails verschoben hat. Redate.io behandelt die Besonderheiten jeder Plattform automatisch, aber wenn Sie Details zu Ihrer spezifischen Konfiguration möchten:

• BitTitan-Daten in Outlook korrigieren
• BitTitan-Daten in Microsoft 365 korrigieren
• BitTitan-Daten in Google Workspace korrigieren
• BitTitan-Daten in Exchange Online korrigieren

Redate.io funktioniert auch bei Migrationen, die Monate oder Jahre zurückliegen. Der ursprüngliche Date-Header verfällt nicht.

Mit BitTitan MigrationWiz migriert und mit falschen Daten konfrontiert? Starten Sie einen kostenlosen Scan, um genau zu sehen, wie viele E-Mails betroffen sind, bevor Sie sich festlegen.