GSMMO endret e-postdatoene dine? Slik fikser du det

GSMMO og datoproblemet ingen advarer deg om

Google Workspace Migration for Microsoft Outlook (GSMMO) er skrivebordsverktøyet Google tilbyr for å migrere PST-filer, Outlook-profiler og lokale e-postarkiver til Gmail. Det er gratis, offisielt støttet, og det er migreringsveien Google anbefaler når du flytter et lite team eller noen få individuelle postbokser fra Outlook til Google Workspace.

Verktøyet virker. E-postene ankommer i Gmail, mappestrukturen kartlegges til etiketter, kontaktene kommer med. Men åpne Gmail etterpå og sorter etter dato. Hver e-post viser dagens dato. Det tilbudet du sendte i januar 2021? April 2026. Fakturaen fra revisoren din fra mars 2023? Også april 2026.

GSMMO advarer deg 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 først når noen søker etter en gammel e-post etter datoperiode og får 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 Gmail API (Googles egne versjonsnotater for verktøyet sier det selv). Det er her datoproblemet oppstår, og det er verdt å forstå mekanismen, fordi det forklarer hvorfor rettingen ikke er så enkel som "bare importer på nytt".

Når GSMMO laster opp en melding via Gmail API, legger Gmail til en ny Received:-header datert opplastingstidspunktet. Og når den opprinnelige datoen ikke følger med meldingen, settes INTERNALDATE, tidsstempelet Gmail bruker internt for sortering og visning, til opplastingstidspunktet i stedet for den opprinnelige sendingsdatoen.

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, uberørt. GSMMO endrer ikke meldingsteksten eller de opprinnelige headerne. Men Gmail ignorerer den ved visning og bruker INTERNALDATE i stedet, som nå sier april 2026.

GSMMO vs. administratorens migreringsverktøy

Her begynner forvirringen ofte. Google har flere migreringsverktøy, og de fungerer ikke likt.

GSMMO (skrivebordsappen) kjører på brukerens maskin. Den leser fra Outlook eller en PST-fil og laster opp e-poster via Gmail API. Brukeren trenger en Google Workspace-konto og GSMMO-tillegget installert i Outlook. Det er et klientside-verktøy.

Google Workspace Migration Service (verktøyet i administrasjonskonsollen) er serverside. En administrator konfigurerer det i Google Admin-konsollen, peker det mot en Exchange-server eller en annen Google Workspace-tenant, og migreringen kjører i Googles infrastruktur. Dette verktøyet håndterer datoer noe bedre i visse konfigurasjoner, fordi det kan sette INTERNALDATE basert på kildemetadata. Men "noe bedre" betyr ikke "pålitelig", og mange administratorer rapporterer samme datoproblem også med dette verktøyet.

Den viktigste forskjellen? Med GSMMO finnes det ingen serverside-intelligens som tar beslutninger om datobevaring. Hver melding det laster opp får samme behandling, uansett om det er en fersk e-post eller en 10 år gammel arkivert melding: en Received:-header datert dagen for opplastingen. Punktum.

Hvorfor GSMMOs datobevaring ikke fungerer

Har du sett på GSMMO-innstillingene, har du kanskje lagt merke til at det egentlig ikke finnes noe alternativ for å "bevare datoer". Det er ikke en forglemmelse. GSMMO er avhengig av hvordan Gmail behandler meldinger som lastes opp via API-en, og det kan ikke overstyre det.

Slik ser den tekniske hendelseskjeden ut:

1. GSMMO leser meldingen fra PST-filen, inkludert de opprinnelige tidsstemplene
2. GSMMO laster opp meldingsdataene via Gmail API
3. Gmail mottar opplastingen og lagrer meldingen i postboksen
4. Gmail legger til en ny Received:-header datert opplastingstidspunktet (linjen med gmailapi.google.com i eksempelet over)
5. Når den opprinnelige datoen ikke følger med, setter Gmail INTERNALDATE til opplastingstidsstempelet
6. Meldingen lander i Gmail med dagens dato

Steg 4 og 5 er de avgjørende. Gmail legger til denne headeren på hver melding som lastes opp via API-en, uansett hva verktøyet sender, og GSMMO har ingen innstilling for å overføre eller bevare den opprinnelige datoen. Resultatet er at alle dine historiske e-poster ser ut som de ankom i dag.

Noen administratorer har prøvd å kjøre GSMMO med spesifikke Google Workspace-innstillinger aktivert eller justert GSMMO-profilinnstillingene. Ingen av disse påvirker datoadferden. Received:-headeren legges til på Googles side, og ingen klientside-konfigurasjon endrer på det.

Spesifikke GSMMO-scenarier som ødelegger datoer

Ikke alle GSMMO-migreringer ender i datokaos, men de fleste gjør det. Her er tilfellene det gjelder:

• PST-fil til Gmail: Datoene ødelegges. Dette er det vanligste GSMMO-bruksscenariet, og det mest rammede.
• Outlook-profil til Gmail: Datoene ødelegges. Samme Gmail API-opplasting som PST-importen.
• Exchange Online (Microsoft 365) til Gmail via GSMMO: Datoene ødelegges. GSMMO leser fra Exchange-serveren og laster opp via Gmail API.
• Lokal Exchange til Gmail via GSMMO: Datoene ødelegges. Samme mekanisme.
• Gmail til Gmail (reimport av PST-eksport): Datoene ødelegges. Selv om de opprinnelige e-postene hadde riktige datoer i PST-filen, stemples de på nytt ved reimport.

Mønsteret er tydelig. Hver melding som lastes opp via Gmail API, får en Received:-header datert dagen for opplastingen. GSMMO bruker alltid denne veien.

Det som gjør dette særlig frustrerende, er at GSMMO-migreringsrapporten viser alt som vellykket. Ingen advarsler om datoer, ingen feil, ingen flagg. Man må manuelt sammenligne tidsstempler før og etter migreringen for å oppdage det, og de fleste administratorer gjør ikke det før en bruker klager.

Konsekvensene går langt utover sortering

Feil datoer etter en GSMMO-migrering skaper reelle problemer som går utover en rotete innboks.

Se deg selv som en regnskapsfører som nettopp har flyttet til Google Workspace. Du må finne all klientkorrespondanse fra Q3 2024 til en skattemelding. Du søker i Gmail etter datoperiode: juli til september 2024. Null resultater. Hver e-post fra den perioden viser nå migreringsdatoen, så Gmails datofilter finner dem ikke. Du sitter fast med å bla gjennom tusenvis av meldinger eller søke på nøkkelord og håpe du husker de riktige ordene.

For regulerte bransjer er dette verre enn upraktisk. E-posttidsstempler fungerer som juridisk bevis. En finansrådgiver som må bevise at en opplysning ble sendt før en transaksjonsdato, kan ikke gjøre det når e-posten viser april 2026 i stedet for februar 2023. Etterlevelsesrevisjoner under SOX eller HIPAA er avhengige av nøyaktige kommunikasjonstidsstempler, og feil datoer betyr mislykkede revisjoner.

Og så er det trådproblemet. Gmail grupperer samtaler etter dato og emne. Når hver melding i en tråd viser samme dato, blir samtalevisningen rotete. Svar vises før den opprinnelige meldingen. Hele trådstrukturen kollapser til en haug med e-poster som har identisk dato.

Retting av GSMMO-datoer med Redate.io

Den gode nyheten: den opprinnelige Date:-headeren er fortsatt intakt i hver migrerte e-post. GSMMO endrer ikke meldingsinnholdet. Den riktige datoen er der, den blir bare ignorert av Gmails visningslogikk fordi INTERNALDATE og den øverste Received-headeren peker på migreringsdatoen.

Redate.io kobler seg til Google Workspace-postboksen, skanner etter e-poster påvirket av GSMMO-migreringen, og retter datometadataene ved hjelp av en egenutviklet motor for headerkjedeanalyse og datorekonstruksjon. Redate trenger ikke å vite hvilket verktøy som utførte migreringen: det finner e-postene der den viste datoen ikke stemmer med den opprinnelige datoen, og retter dem uten å endre meldingsinnhold, vedlegg eller tråding.

Hver rettet e-post går gjennom individuell verifisering: meldingsintegritet, bevaring av vedlegg, etikettkartlegging og trådkonsistens. Originalene forblir i en synlig sikkerhetskopimappe Redate.io - Originals i din egen postboks til du selv sletter dem.

Kunne du rettet dette selv med et skript? Å forstå problemet er en ting. Å rette 12 000 e-poster uten å bryte S/MIME-signaturer, ødelegge nestede MIME-deler eller forvrenge RFC 2047-kodede headere i en produksjonspostboks er noe helt annet. Hvordan håndterer du e-posten med et 38 MB vedlegg og en skadet MIME-grense som GSMMO importerte, men som knapt holdt seg sammen? Hvordan verifiserer du at hver enkelt melding kom gjennom intakt? Et skript som fungerer på 20 testmeldinger i et laboratorium, overlever ikke en ekte postboks med 8 års korrespondanse.

Plattformspesifikke veiledninger for GSMMO

Siden GSMMO migrerer spesifikt til Google Workspace, skjer rettingen på Gmail-nivå. Men de påvirkede e-postene er synlige i hver klient koblet til den kontoen:

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

Migrerte du for måneder siden? Den opprinnelige Date-headeren forringes ikke over tid. Redate.io kan rette GSMMO-påvirkede e-poster, uansett om migreringen skjedde forrige uke eller tre år siden.

Har GSMMO-migreringen etterlatt e-postene dine med feil datoer? Kjør en gratis skanning av postboksen din for å se det eksakte antallet påvirkede e-poster og kostnaden for å rette dem, før du forplikter deg til noe.