BitTitan MigrationWiz: Falsche E-Mail-Daten korrigieren

Was BitTitan MigrationWiz mit E-Mail-Daten 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 ist eine Folge davon, wie das IMAP-Protokoll auf Transportebene funktioniert, und MigrationWiz löst es auf eine bestimmte Weise aus.

Wie MigrationWiz mit Received-Headern umgeht

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). Während dieses Prozesses versieht der Ziel-Mailserver die Nachricht mit einem neuen Received:-Header, der den aktuellen Zeitstempel enthält - genau so, wie er jede eingehende E-Mail stempeln würde.

So sieht eine typische Received-Header-Kette nach einer MigrationWiz-Migration aus:

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

Der ursprüngliche Received:-Header von 2019 ist noch vorhanden. Ebenso der ursprüngliche Date:-Header. Aber E-Mail-Clients wie Outlook verwenden diese nicht. Outlook liest den neuesten Received:-Header, um zu bestimmen, wann die Nachricht angezeigt werden soll, und dieser Header sagt jetzt 28. März 2026.

Der INTERNALDATE-Wert (der Zeitstempel, den IMAP-Server zum Sortieren verwenden) wird während der Übertragung ebenfalls überschrieben. MigrationWiz versucht zwar, Daten zu erhalten, wenn das Ziel dies unterstützt, aber das Ergebnis hängt stark vom Verhalten des Zielservers ab. Die Transport-Pipeline von Microsoft 365 überschreibt beispielsweise das INTERNALDATE mit ihrem eigenen Zustellungszeitstempel, unabhängig davon, was MigrationWiz anfordert.

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. Sobald jedoch IMAP auf einer der beiden Seiten beteiligt ist, übernimmt die IMAP-APPEND-Operation und der Zielserver entscheidet, welchen Zeitstempel er verwendet.

Manche Administratoren haben versucht, die Migration mit anderen Endpoint-Konfigurationen erneut durchzuführen, in der Hoffnung, dass der Wechsel von IMAP zu EWS die Daten rückwirkend korrigieren würde. Das funktioniert nicht. Die Nachrichten befinden sich bereits am Ziel mit falschen Daten. 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. Die M365-Transport-Pipeline stempelt neue Received-Header und überschreibt INTERNALDATE.
• Google Workspace zu Microsoft 365: Daten gehen kaputt. MigrationWiz liest per IMAP von Google und schreibt nach M365, das seine Transport-Header hinzufügt.
• Exchange zu Exchange (EWS zu EWS): Daten bleiben in der Regel erhalten. EWS umgeht die Transport-Pipeline auf beiden Seiten.
• Beliebige Quelle zu Google Workspace über IMAP: Daten gehen kaputt. Googles IMAP-Implementierung fügt einen Received-Header mit dem Einfügezeitstempel hinzu.
• Cross-Tenant Microsoft 365: Abhängig von der Methode. Der IMAP-Weg zerstört Daten. Direktes EWS kann sie erhalten.

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-Daten 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. Es sind der zusätzliche Received:-Header und das überschriebene INTERNALDATE, die das Anzeigeproblem verursachen.

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, mit Pattern-Matching gegen bekannte MigrationWiz-Header-Signaturen einschließlich der charakteristischen Kennungen mx.migrationwiz.com und bittitan.com in der Received-Kette.

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 für 30 Tage aufbewahrt, falls ein Rollback erforderlich ist.

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.