GSMMO und das Datumsproblem, vor dem niemand warnt
Google Workspace Migration for Microsoft Outlook (GSMMO) ist das Desktop-Tool, das Google bereitstellt, um PST-Dateien, Outlook-Profile und lokale E-Mail-Archive nach Gmail zu migrieren. Es ist kostenlos, offiziell unterstuetzt und der Migrationsweg, den Google empfiehlt, wenn ein kleines Team oder einzelne Postfaecher von Outlook zu Google Workspace umziehen.
Das Tool funktioniert. E-Mails kommen in Gmail an, die Ordnerstruktur wird auf Labels abgebildet, Kontakte werden uebertragen. Aber oeffnen Sie Gmail danach und sortieren Sie nach Datum. Jede E-Mail zeigt das heutige Datum. Das Angebot, das Sie im Januar 2021 verschickt haben? April 2026. Die Rechnung Ihres Steuerberaters von Maerz 2023? Auch April 2026.
GSMMO warnt nicht, dass das passieren wird. Das Migrationsprotokoll zeigt fuer jede Nachricht Erfolg an. Googles eigene Dokumentation erwaehnt es nicht als bekannte Einschraenkung. Man entdeckt es erst, wenn jemand eine alte E-Mail nach Datumsbereich sucht und null Ergebnisse bekommt.
Wie GSMMO Ihre E-Mails tatsaechlich hochlaedt
GSMMO liest Nachrichten aus der PST-Datei (oder direkt aus dem Outlook-Profil) und laedt sie ueber Googles IMAP-Gateway nach Gmail hoch. Hier liegt der Ursprung des Datumsproblems, und es lohnt sich, die Mechanik zu verstehen, weil sie erklaert, warum die Loesung nicht so einfach ist wie "nochmal importieren".
Wenn GSMMO eine Nachricht hochlaedt, behandelt Gmails IMAP-Gateway sie wie eine frisch eingehende E-Mail. Gmail versieht die Nachricht mit einem neuen Received:-Header, der den aktuellen Zeitstempel enthaelt. Das INTERNALDATE, der Zeitstempel, den Gmail intern fuer Sortierung und Anzeige verwendet, wird auf den Moment des Uploads gesetzt, nicht auf das urspruengliche Sendedatum.
So sieht die Header-Kette nach einer GSMMO-Migration aus:
Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200
Sehen Sie den originalen Date:-Header von September 2019? Er ist noch da, unveraendert. GSMMO modifiziert weder den Nachrichtentext noch die Original-Header. Aber Gmail ignoriert ihn fuer die Anzeige und nutzt stattdessen das INTERNALDATE, das jetzt April 2026 sagt.
GSMMO vs. Admin-Migrationstools
Hier beginnt oft die Verwirrung. Google hat mehrere Migrationstools, und die verhalten sich nicht alle gleich.
GSMMO (die Desktop-App) laeuft auf dem Rechner des Benutzers. Es liest aus Outlook oder einer PST-Datei und schiebt E-Mails ueber Googles IMAP-Schnittstelle. Der Benutzer braucht ein Google-Workspace-Konto und das GSMMO-Plugin in Outlook. Es ist ein clientseitiges Tool, was bedeutet, dass Googles Server eingehende Nachrichten sehen, keine migrierten Nachrichten.
Google Workspace Migration Service (das Admin-Konsolen-Tool) arbeitet serverseitig. Ein Administrator konfiguriert es in der Google Admin-Konsole, verweist es auf einen Exchange-Server oder einen anderen Google-Workspace-Tenant, und die Migration laeuft in Googles Infrastruktur. Dieses Tool behandelt Daten in manchen Konfigurationen etwas besser, weil es das INTERNALDATE anhand der Quell-Metadaten setzen kann. Aber "etwas besser" heisst nicht "zuverlaessig", und viele Administratoren berichten ueber dasselbe Datumsproblem auch mit diesem Tool.
Der wesentliche Unterschied? Bei GSMMO gibt es keine serverseitige Intelligenz fuer die Datumserhaltung. Das IMAP-Gateway behandelt jede hochgeladene Nachricht identisch, ob frische E-Mail oder 10 Jahre altes Archiv. Es stempelt das aktuelle Datum. Punkt.
Warum die Datumserhaltung bei GSMMO nicht funktioniert
Wenn Sie sich die GSMMO-Einstellungen angesehen haben, ist Ihnen vielleicht aufgefallen, dass es keine Option "Daten erhalten" gibt. Das ist kein Versehen. GSMMO verlaesst sich auf das Verhalten von Gmails IMAP-Gateway fuer die Datumsbehandlung und kann es nicht uebersteuern.
Hier die technische Abfolge:
- GSMMO liest die Nachricht aus der PST-Datei, einschliesslich der originalen Zeitstempel
- GSMMO verbindet sich mit Gmail ueber IMAP und sendet einen APPEND-Befehl mit den Nachrichtendaten
- Gmails IMAP-Gateway empfaengt den APPEND und verarbeitet ihn durch die interne Transport-Pipeline
- Die Transport-Pipeline fuegt einen neuen
Received:-Header mit dem aktuellen Datum hinzu - Gmail setzt das INTERNALDATE auf den Upload-Zeitstempel
- Die Nachricht landet in Gmail mit dem heutigen Datum
Schritt 3 ist der entscheidende. Auch wenn das IMAP-APPEND-Protokoll technisch das Setzen eines benutzerdefinierten INTERNALDATE unterstuetzt, respektiert Gmails Implementierung es nicht immer, besonders ueber den GSMMO-Pfad. Das Ergebnis: Alle Ihre historischen E-Mails sehen aus, als waeren sie heute eingetroffen.
Manche Administratoren haben versucht, GSMMO mit bestimmten Google-Workspace-Einstellungen oder angepassten GSMMO-Profilparametern auszufuehren. Nichts davon beeinflusst das Datumsverhalten. Das Datum wird serverseitig gestempelt, und keine clientseitige Konfiguration aendert das.
GSMMO-Szenarien, die Daten verfaelschen
Nicht jede GSMMO-Migration endet im Datums-Chaos, die meisten aber schon. Hier sind die betroffenen Faelle:
- PST-Datei nach Gmail: Daten werden verfaelscht. Das ist der haeufigste GSMMO-Anwendungsfall und am staerksten betroffen.
- Outlook-Profil nach Gmail: Daten werden verfaelscht. Dasselbe IMAP-Gateway-Verhalten wie beim PST-Import.
- Exchange Online (Microsoft 365) nach Gmail ueber GSMMO: Daten werden verfaelscht. GSMMO liest vom Exchange-Server und laedt ueber Gmails IMAP-Gateway hoch.
- On-Premises Exchange nach Gmail ueber GSMMO: Daten werden verfaelscht. Gleicher Mechanismus.
- Gmail zu Gmail (Re-Import eines PST-Exports): Daten werden verfaelscht. Selbst wenn die Original-E-Mails im PST korrekte Daten hatten, werden sie beim Re-Import neu gestempelt.
Das Muster ist eindeutig. Jeder Weg, der beim Upload durch Gmails IMAP-Gateway fuehrt, ueberschreibt die Daten. GSMMO nutzt immer diesen Weg.
Was das besonders aergerlich macht: Der GSMMO-Migrationsbericht zeigt alles als erfolgreich an. Keine Warnungen zu Daten, keine Fehler, keine Hinweise. Man muesste Zeitstempel vor und nach der Migration manuell vergleichen, und die meisten Administratoren tun das erst, wenn sich ein Benutzer beschwert.
Die Auswirkungen gehen weit ueber die Sortierung hinaus
Falsche Daten nach einer GSMMO-Migration verursachen echte Probleme, die ueber ein unordentliches Postfach hinausgehen.
Stellen Sie sich vor, Sie sind Steuerberater und gerade zu Google Workspace gewechselt. Sie muessen die gesamte Mandantenkorrespondenz aus Q3 2024 fuer eine Steuererklaerung finden. Sie suchen in Gmail nach Datumsbereich: Juli bis September 2024. Null Ergebnisse. Jede E-Mail aus diesem Zeitraum zeigt jetzt das Migrationsdatum, also kann Gmails Datumsfilter sie nicht finden. Sie bleiben beim Durchscrollen Tausender Nachrichten oder bei der Stichwortsuche haengen.
Fuer regulierte Branchen ist das mehr als laestig. E-Mail-Zeitstempel dienen als rechtliche Beweismittel. Ein Finanzberater, der nachweisen muss, dass er eine Offenlegung vor einem Transaktionsdatum gesendet hat, kann das nicht, wenn die E-Mail April 2026 statt Februar 2023 anzeigt. Compliance-Pruefungen nach der DSGVO stuetzen sich auf praezise Kommunikationszeitstempel, und falsche Daten bedeuten gescheiterte Audits.
Und dann gibt es das Threading-Problem. Gmail gruppiert Unterhaltungen nach Datum und Betreff. Wenn jede Nachricht in einem Thread dasselbe Datum zeigt, wird die Konversationsansicht chaotisch. Antworten erscheinen vor der Originalnachricht. Die gesamte Thread-Struktur kollabiert zu einem Haufen gleich datierter E-Mails.
GSMMO-Daten mit Redate.io korrigieren
Die gute Nachricht: Der originale Date:-Header ist in jeder migrierten E-Mail noch intakt. GSMMO veraendert den Nachrichteninhalt nicht. Das korrekte Datum ist vorhanden, wird aber von Gmails Anzeigelogik ignoriert, weil INTERNALDATE und der oberste Received-Header auf das Migrationsdatum zeigen.
Redate.io verbindet sich mit dem Google-Workspace-Postfach, scannt nach E-Mails, die von der GSMMO-Migration betroffen sind, und korrigiert die Datums-Metadaten ueber einen proprietaeren Motor zur Header-Ketten-Analyse und Datumsrekonstruktion. Die Korrektur erkennt GSMMO-spezifische Muster in der Received-Header-Kette (die gmailapi.google.com-Signatur und lokale IMAP-Gateway-Kennungen) und fuehrt eine gezielte Metadaten-Korrektur durch, ohne Nachrichteninhalt, Anhaenge oder Threading zu veraendern.
Jede korrigierte E-Mail durchlaeuft eine individuelle Pruefung: Nachrichtenintegritaet, Anhangssicherung, Label-Zuordnung und Thread-Konsistenz. Originale bleiben 30 Tage lang in einem sichtbaren Ordner Redate.io - Originals.
Koennten Sie das selbst mit einem Skript beheben? Das Problem zu verstehen ist eine Sache. 12.000 E-Mails zu korrigieren, ohne S/MIME-Signaturen zu brechen, verschachtelte MIME-Teile zu beschaedigen oder RFC-2047-kodierte Header in einem Produktionspostfach zu zerstoeren, ist eine voellig andere. Wie gehen Sie mit der E-Mail um, die einen 38-MB-Anhang und eine beschaedigte MIME-Boundary hat, die GSMMO importiert, aber kaum zusammengehalten hat? Ein Skript, das bei 20 Testnachrichten im Labor funktioniert, ueberlebt kein echtes Postfach mit 8 Jahren Korrespondenz.
Plattformspezifische Anleitungen fuer GSMMO
Da GSMMO speziell nach Google Workspace migriert, erfolgt die Korrektur auf Gmail-Ebene. Aber die betroffenen E-Mails sind in jedem Client sichtbar, der mit diesem Gmail-Konto verbunden ist:
- GSMMO-Migrationsdaten in Gmail korrigieren
- GSMMO-Migrationsdaten in Outlook korrigieren (mit Google Workspace verbunden)
- GSMMO-Migrationsdaten in Apple Mail korrigieren
Migration schon Monate her? Der originale Date-Header verliert mit der Zeit nicht an Qualitaet. Redate.io kann GSMMO-betroffene E-Mails korrigieren, egal ob die Migration letzte Woche stattfand oder vor drei Jahren.
GSMMO-Migration hat Ihre E-Mails mit falschen Daten hinterlassen? Starten Sie einen kostenlosen Scan, um die genaue Anzahl betroffener E-Mails und die Korrekturkosten zu sehen, bevor Sie sich festlegen.