GSMMO endret e-postdatoene dine? Slik fikser du det

GSMMO og datoproblemet ingen advarer om

Google Workspace Migration for Microsoft Outlook (GSMMO) er skrivebordsverktoeyet Google tilbyr for aa migrere PST-filer, Outlook-profiler og lokale e-postarkiver til Gmail. Det er gratis, offisielt stoettet, og migreringsveien Google anbefaler naar du flytter et lite team eller noen faa individuelle postkasser fra Outlook til Google Workspace.

Verktoeyet virker. E-poster ankommer i Gmail, mappestrukturen konverteres til etiketter, kontakter overfoeres. Men aapne Gmail etterpaa og sorter etter dato. Hver eneste e-post viser dagens dato. Det tilbudet du sendte i januar 2021? April 2026. Fakturaen fra revisoren din fra mars 2023? Ogsaa april 2026.

GSMMO advarer ikke om at dette vil skje. Migreringsloggen viser suksess for hver melding. Googles egen dokumentasjon nevner det ikke som en kjent begrensning. Du oppdager det foerst naar noen soeker etter en gammel e-post etter datoperiode og faar null resultater.

Hvordan GSMMO faktisk laster opp e-postene dine

GSMMO leser meldinger fra PST-filen (eller direkte fra Outlook-profilen) og laster dem opp til Gmail via Googles IMAP-gateway. Det er her datoproblemet oppstaar, og det er verdt aa forstaa mekanikken fordi det forklarer hvorfor loesningen ikke er saa enkel som "importer paa nytt".

Naar GSMMO laster opp en melding, behandler Gmails IMAP-gateway den som en helt ny e-post. Gmail stempler meldingen med en ny Received:-header som inneholder gjeldende tidsstempel. INTERNALDATE, tidsstempelet Gmail bruker internt for sortering og visning, settes til opplastingstidspunktet i stedet for den opprinnelige sendedatoen.

Slik ser headerkjeden ut etter en GSMMO-migrering:

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

Ser du den opprinnelige Date:-headeren fra september 2019? Den er fortsatt der, uroert. GSMMO endrer verken meldingsinnholdet eller de opprinnelige headerne. Men Gmail ignorerer den for visning og bruker INTERNALDATE i stedet, som naa sier april 2026.

GSMMO vs. administratorens migreringsverktoy

Her begynner forvirringen ofte. Google har flere migreringsverktoy, og de oppfoerer seg ikke likt.

GSMMO (skrivebordsappen) kjoerer paa brukerens maskin. Den leser fra Outlook eller en PST-fil og sender e-post via Googles IMAP-grensesnitt. Brukeren trenger en Google Workspace-konto og GSMMO-tillegget installert i Outlook. Det er et klientside-verktoy, noe som betyr at Googles servere ser innkommende meldinger, ikke migrerte meldinger.

Google Workspace Migration Service (administrasjonskonsolverktoeyet) er serverside. En administrator konfigurerer det i Google Admin-konsollen, peker det mot en Exchange-server eller en annen Google Workspace-tenant, og migreringen kjoerer i Googles infrastruktur. Dette verktoeyet haandterer datoer noe bedre i visse konfigurasjoner fordi det kan sette INTERNALDATE basert paa kildemetadata. Men "noe bedre" betyr ikke "paalitelig", og mange administratorer rapporterer det samme datoproblemet ogsaa med dette verktoeyet.

Den viktigste forskjellen? Med GSMMO er det ingen serversideintelligens for datobevaring. IMAP-gatewayen behandler hver opplastet melding identisk, enten det er en fersk e-post eller en 10 aar gammel arkivert melding. Den stempler dagens dato. Punktum.

Hvorfor GSMMO-datobevaring ikke fungerer

Har du sett paa GSMMO-innstillingene, har du kanskje lagt merke til at det ikke finnes noe "bevar datoer"-alternativ. Det er ikke en forglemmelse. GSMMO er avhengig av Gmails IMAP-gatewayadferd for datohaandtering og kan ikke overstyre den.

Den tekniske hendelseskjeden:

1. GSMMO leser meldingen fra PST-filen, inkludert de opprinnelige tidsstemplene
2. GSMMO kobler til Gmail via IMAP og sender en APPEND-kommando med meldingsdata
3. Gmails IMAP-gateway mottar APPEND og behandler den gjennom den interne transportpipelinen
4. Transportpipelinen legger til en ny Received:-header med gjeldende dato
5. Gmail setter INTERNALDATE til opplastingstidsstempelet
6. Meldingen lander i Gmail med dagens dato

Steg 3 er det avgjorende. Selv om IMAP APPEND-protokollen teknisk stoetter innstilling av en egendefinert INTERNALDATE, respekterer Gmails implementering det ikke alltid, saerlig via GSMMO-stien. Resultatet: alle dine historiske e-poster ser ut til aa ha ankommet i dag.

Noen administratorer har proevd aa kjoere GSMMO med spesifikke Google Workspace-innstillinger eller justerte GSMMO-profilparametre. Ingenting av det paavirker datoadferden. Datoen stemples serverside, og ingen klientside-konfigurasjon endrer det.

GSMMO-scenarier som oedelegger datoer

Ikke alle GSMMO-migreringer ender i datokaos, men de fleste gjoer det. Her er de rammede tilfellene:

• PST-fil til Gmail: Datoer oedelegges. Dette er det vanligste GSMMO-bruksscenariet og det mest rammede.
• Outlook-profil til Gmail: Datoer oedelegges. Samme IMAP-gatewayadferd som PST-import.
• Exchange Online (Microsoft 365) til Gmail via GSMMO: Datoer oedelegges. GSMMO leser fra Exchange-serveren og laster opp via Gmails IMAP-gateway.
• Lokal Exchange til Gmail via GSMMO: Datoer oedelegges. Samme mekanisme.
• Gmail til Gmail (reimport av PST-eksport): Datoer oedelegges. Selv om de opprinnelige e-postene hadde korrekte datoer i PST-filen, stemples de paa nytt ved reimport.

Moensteret er tydelig. Enhver sti som gaar via Gmails IMAP-gateway under opplasting overskriver datoene. GSMMO bruker alltid denne stien.

Det som gjoer det saerlig frustrerende er at GSMMO-migreringsrapporten viser alt som vellykket. Ingen advarsler om datoer, ingen feil, ingen flagg. Man maatte manuelt sammenligne tidsstempler foer og etter migreringen for aa oppdage det, og de fleste administratorer gjoer ikke det foer en bruker klager.

Konsekvensene strekker seg langt utover sortering

Feil datoer etter en GSMMO-migrering skaper reelle problemer som gaar utover en rotete innboks.

Tenk deg at du er revisor og nettopp har migrert til Google Workspace. Du maa finne all klientkorrespondanse fra Q3 2024 for en skattemelding. Du soeker i Gmail etter datoperiode: juli til september 2024. Null resultater. Hver e-post fra den perioden viser naa migreringsdatoen, saa Gmails datofilter kan ikke finne dem. Du sitter fast med aa scrolle gjennom tusenvis av meldinger eller soeke paa noekkelord og haape paa aa huske de riktige termene.

For regulerte bransjer er dette verre enn irriterende. E-posttidsstempler fungerer som juridisk bevis. En finansiell raadgiver som maa bevise aa ha sendt en opplysning foer en transaksjonsdato, kan ikke gjoere det naar e-posten viser april 2026 i stedet for februar 2023. Compliance-revisjoner under personvernforordningen (GDPR) stoetter seg paa noyaktige kommunikasjonstidsstempler, og feil datoer betyr mislykkede revisjoner.

Og saa er det threadingproblemet. Gmail grupperer samtaler etter dato og emne. Naar hver melding i en traad viser samme dato, blir samtalevisningen kaotisk. Svar vises foer den opprinnelige meldingen. Hele traadstrukturen kollapser til en haug med identisk daterte e-poster.

Fiks GSMMO-datoer med Redate.io

Den gode nyheten: den opprinnelige Date:-headeren er fortsatt intakt i hver migrert e-post. GSMMO endrer ikke meldingsinnholdet. Den korrekte datoen er der, den ignoreres bare av Gmails visningslogikk fordi INTERNALDATE og den oeverste Received-headeren peker paa migreringsdatoen.

Redate.io kobler til Google Workspace-postkassen, skanner etter e-poster rammet av GSMMO-migreringen og korrigerer datometadata via en proprietaer motor for headerkjedeanalyse og datorekonstruksjon. Korreksjonen identifiserer GSMMO-spesifikke moenstre i Received-headerkjeden (signaturen gmailapi.google.com og lokale IMAP-gatewayidentifikatorer) og utfoerer maalrettet metadatakorrigering uten aa endre meldingsinnhold, vedlegg eller threading.

Hver korrigert e-post gjennomgaar individuell verifisering: meldingsintegritet, bevaring av vedlegg, etikettilknytning og traadkonsistens. Originaler forblir i en synlig mappe Redate.io - Originals i 30 dager.

Kunne du fikset det selv med et skript? Rett og slett, aa forstaa problemet er en ting. Aa rette 12 000 e-poster uten aa bryte S/MIME-signaturer, oedelegge nestede MIME-deler eller oedelegge RFC 2047-kodede headere i en produksjonspostkasse er noe helt annet. Hvordan haandterer du e-posten med et 38 MB vedlegg og en skadet MIME-grense som GSMMO importerte men knapt holdt sammen? Et skript som virker paa 20 testmeldinger i et lab overlever ikke en ekte postkasse med 8 aars korrespondanse.

Plattformspesifikke veiledninger for GSMMO

Siden GSMMO migrerer spesifikt til Google Workspace, skjer korreksjonen paa Gmail-nivaa. Men de rammede e-postene er synlige i enhver klient koblet til den Gmail-kontoen:

• Rett GSMMO-migreringsdatoer i Gmail
• Rett GSMMO-migreringsdatoer i Outlook (koblet til Google Workspace)
• Rett GSMMO-migreringsdatoer i Apple Mail

Migrerte for maaneder siden? Den opprinnelige Date-headeren forringes ikke over tid. Redate.io kan rette GSMMO-rammede e-poster uansett om migreringen skjedde forrige uke eller for tre aar siden.

GSMMO-migrering etterlot e-postene dine med feil datoer? Kjoer en gratis skanning for aa se det eksakte antallet rammede e-poster og kostnaden for korrigering, foer du forplikter deg.