GSMMO Migration Broke Your Email Dates? Fix It

GSMMO and the Date Problem Nobody Warns You About

Google Workspace Migration for Microsoft Outlook (GSMMO) is the desktop tool Google provides to migrate PST files, Outlook profiles, and local email archives into Gmail. It's free, it's officially supported, and it's the migration path Google recommends when you're moving a small team or a few individual mailboxes from Outlook to Google Workspace.

The tool works. Emails arrive in Gmail, folder structure maps to labels, contacts come through. But open Gmail afterward and sort by date. Every email shows today's date. That proposal you sent in January 2021? April 2026. The invoice from your accountant in March 2023? Also April 2026.

GSMMO doesn't warn you this will happen. The migration log shows success for every message. Google's own documentation doesn't mention it as a known limitation. You only discover it when someone searches for an old email by date range and gets zero results.

How GSMMO Actually Uploads Your Email

GSMMO reads messages from the PST file (or directly from the Outlook profile) and uploads them to Gmail through Google's IMAP gateway. This is where the date problem originates, and it's worth understanding the mechanics because it explains why the fix isn't as simple as "just re-import."

When GSMMO uploads a message, Gmail's IMAP gateway treats it like a newly arriving email. Gmail stamps the message with a fresh Received: header containing the current timestamp. The INTERNALDATE, which is the timestamp Gmail uses internally for sorting and display, gets set to the moment of upload rather than the original send date.

Here's what the header chain looks like after a GSMMO migration:

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

See that original Date: header from September 2019? It's still there, untouched. GSMMO doesn't modify the message body or original headers. But Gmail ignores it for display purposes and uses the INTERNALDATE instead, which now says April 2026.

GSMMO vs. Admin-Side Migration Tools

This is where confusion often starts. Google has multiple migration tools, and they don't all behave the same way.

GSMMO (the desktop app) runs on the user's machine. It reads from Outlook or a PST file and pushes emails through Google's IMAP interface. The user needs a Google Workspace account and the GSMMO plugin installed in Outlook. It's a client-side tool, which means Google's servers see incoming messages, not migrated messages.

Google Workspace Migration Service (the admin console tool) is server-side. An admin configures it in the Google Admin Console, points it at an Exchange server or another Google Workspace tenant, and the migration runs in Google's infrastructure. This tool has slightly better date handling in some configurations because it can set the INTERNALDATE based on the source metadata. But "slightly better" doesn't mean "reliable," and many admins report the same date issue with this tool too.

The key difference? With GSMMO, there's no server-side intelligence making decisions about date preservation. The IMAP gateway treats every uploaded message identically, whether it's a fresh email or a 10-year-old archived message. It stamps the current date. Period.

Why GSMMO's Date Preservation Doesn't Work

If you've looked at GSMMO's settings, you might have noticed there isn't actually a "preserve dates" option. That's not an oversight. GSMMO relies on Gmail's IMAP gateway behavior for date handling, and it can't override it.

Here's the technical chain of events:

1. GSMMO reads the message from the PST file, including its original timestamps
2. GSMMO connects to Gmail via IMAP and issues an APPEND command with the message data
3. Gmail's IMAP gateway receives the APPEND and processes it through its internal transport pipeline
4. The transport pipeline stamps a new Received: header with the current date
5. Gmail sets the INTERNALDATE to the upload timestamp
6. The message lands in Gmail with today's date

Step 3 is the critical one. Even though the IMAP APPEND protocol technically supports setting a custom INTERNALDATE, Gmail's implementation doesn't always honor it, especially through the GSMMO pathway. The result is that all your historical emails look like they arrived today.

Some admins have tried running GSMMO with specific Google Workspace settings enabled (like "Allow less secure apps" back when that was an option) or adjusting the GSMMO profile settings. None of these affect the date behavior. The date gets stamped server-side, and no client-side configuration changes that.

Specific GSMMO Scenarios That Break Dates

Not every GSMMO migration ends in date chaos, though most do. Here's where it matters:

• PST file to Gmail: Dates break. This is the most common GSMMO use case and the most affected.
• Outlook profile to Gmail: Dates break. Same IMAP gateway behavior as PST import.
• Exchange Online (Microsoft 365) to Gmail via GSMMO: Dates break. GSMMO reads from the Exchange server and uploads to Gmail's IMAP gateway.
• On-premises Exchange to Gmail via GSMMO: Dates break. Same mechanism.
• Gmail to Gmail (re-import of PST export): Dates break. Even if the original emails had correct dates in the PST, the re-import stamps them fresh.

The pattern is clear. Any path that goes through Gmail's IMAP gateway during upload results in date overwriting. GSMMO always uses this path.

What makes this particularly frustrating is that the GSMMO migration report shows everything as successful. No warnings about dates, no errors, no flags. You'd have to manually compare timestamps before and after migration to catch it, and most admins don't do that until a user complains.

The Impact Goes Beyond Sorting

Wrong dates after GSMMO migration create real problems that go beyond a messy inbox.

Imagine you're an accountant who just moved to Google Workspace. You need to find all client correspondence from Q3 2024 for a tax filing. You search Gmail by date range: July to September 2024. Zero results. Every email from that period now shows the migration date, so Gmail's date filter can't find them. You're stuck scrolling through thousands of messages or searching by keyword and hoping you remember the right terms.

For regulated industries, this is worse than inconvenient. Email timestamps serve as legal evidence. A financial advisor who needs to prove they sent a disclosure before a transaction date can't do that when the email shows April 2026 instead of February 2023. Compliance audits under SOX or HIPAA rely on accurate communication timestamps, and wrong dates mean failed audits.

And then there's the threading issue. Gmail groups conversations by date and subject. When every message in a thread shows the same date, the conversation view becomes jumbled. Replies appear before the original message. The entire thread structure collapses into a pile of identically-dated emails.

Fixing GSMMO Dates With Redate.io

The good news: that original Date: header is still intact inside every migrated email. GSMMO doesn't modify message content. The correct date is there, it's just being ignored by Gmail's display logic because the INTERNALDATE and top Received header point to the migration date.

Redate.io connects to the Google Workspace mailbox, scans for emails affected by the GSMMO migration, and corrects the date metadata using a proprietary header chain analysis and date reconstruction engine. The correction identifies GSMMO-specific patterns in the Received header chain (the gmailapi.google.com signature and local IMAP gateway identifiers) and performs targeted metadata correction without altering message content, attachments, or threading.

Each corrected email goes through individual verification: message integrity, attachment preservation, label mapping, and thread consistency. Originals stay in a visible Redate.io - Originals backup folder for 30 days.

Could you fix this yourself with a script? Understanding the problem is one thing. Correcting 12,000 emails without breaking S/MIME signatures, corrupting nested MIME parts, or mangling RFC 2047 encoded headers across a production mailbox is something else entirely. How do you handle the email with a 38 MB attachment and a corrupted MIME boundary that GSMMO imported but barely held together? How do you verify every single message came through intact? A script that works on 20 test messages in a lab won't survive a real mailbox with 8 years of correspondence.

Platform-Specific Guides for GSMMO

Since GSMMO migrates specifically to Google Workspace, the fix happens at the Gmail level. But the affected emails are visible across every client connected to that Gmail account:

• Fix GSMMO migration dates in Gmail
• Fix GSMMO migration dates in Outlook (connected to Google Workspace)
• Fix GSMMO migration dates in Apple Mail

Already migrated months ago? The original Date header doesn't degrade over time. Redate.io can fix GSMMO-affected emails whether the migration happened last week or three years ago.

GSMMO migration left your emails with wrong dates? Run a free scan to see the exact number of affected emails and the cost to fix them, before committing to anything.