What Is GSMMO?
GSMMO stands for Google Workspace Migration for Microsoft Outlook. It's a free migration tool provided by Google that allows organizations to move email, calendar, and contact data from Microsoft Outlook (and by extension, Microsoft Exchange) to Google Workspace. GSMMO runs as a desktop application on Windows and reads data directly from the user's Outlook profile or from PST backup files.
Google designed GSMMO as the official migration path for organizations switching from Microsoft's email ecosystem to Google Workspace. IT administrators use it when the migration involves individual workstations (as opposed to server-to-server tools like CloudM or BitTitan). It's particularly common in small to mid-size organizations where installing a desktop tool on each machine is more practical than configuring server-level migration.
For other migration tools to Google Workspace (BitTitan, CloudM, imapsync), see the general Google Workspace guide.
When GSMMO Is Used
Exchange to Google Workspace
The primary use case for GSMMO is migrating from an on-premises Microsoft Exchange server to Google Workspace. The administrator installs GSMMO on each user's workstation, and the tool reads emails from the locally connected Outlook profile (which syncs with Exchange). Emails are uploaded directly to the user's Google Workspace mailbox.
PST File Import
GSMMO can also import PST files - Outlook's local archive format. Organizations that have archived emails in PST files use GSMMO to upload those archives into Google Workspace. This is common during migrations where the original Exchange server has already been decommissioned and only PST backups remain.
Outlook.com / Hotmail to Google Workspace
Less commonly, GSMMO is used to migrate personal Outlook.com or Hotmail accounts into a Google Workspace organization. The tool connects to the Outlook profile configured for these accounts and transfers the data to Google Workspace.
How GSMMO Causes the Date Issue
The Upload Process
When GSMMO uploads emails to Google Workspace, it uses the Gmail API to insert each message. During this insertion, Google's mail servers process the message and add metadata including a "Received" header with the current timestamp. This header records when the message was inserted into Google's infrastructure, which is the migration date.
Why IMAP Clients Show the Wrong Date
Here's where it gets confusing. The Gmail web interface typically displays dates based on the "Date" header of the email, so messages often appear with the correct date in Gmail's web UI. But when users access the same Google Workspace mailbox through an IMAP client (Outlook, Apple Mail, Thunderbird), the client reads the topmost "Received" header to determine the received date. Since the GSMMO migration added a new "Received" header with the migration timestamp, every email shows the migration date in these clients.
So you get this maddening situation: the same email shows the correct date in Gmail's web interface but the wrong date in Outlook connected to the same account. Users and administrators often waste hours troubleshooting Outlook settings when the issue is actually in the email headers on the server. For more details on this mechanism, see why emails show wrong dates after IMAP migration.
INTERNALDATE Handling
GSMMO attempts to set the INTERNALDATE correctly during the upload. In many cases, the INTERNALDATE on the Google Workspace server does reflect the original email date. But email clients that prioritize "Received" headers over the INTERNALDATE still display the wrong date. Outlook is the most notable example, it uses the "Received" header timestamp for the "Received" column, which is the default sort and display field.
Diagnosing the GSMMO Date Issue
Step 1: Check Gmail Web vs. IMAP Client
Open the same email in Gmail's web interface and in Outlook (or another IMAP client). If the Gmail web interface shows the correct original date but Outlook shows the migration date, the issue is caused by a "Received" header added during GSMMO migration.
Step 2: View Raw Headers
In Gmail, open the affected email, click the three dots, and select "Show original." Examine the "Received" headers at the top of the message. Look for a header with a timestamp matching the migration date. GSMMO insertions typically produce a "Received" header referencing Google's internal mail infrastructure (such as "mx.google.com" or a Google IP address) with the migration timestamp.
Step 3: Confirm the Pattern
Check multiple emails from different dates. If all of them have a topmost "Received" header with the same migration-date timestamp (or timestamps within the same migration window), the GSMMO date issue is confirmed.
Why Google Support Can't Help
Google Workspace support doesn't offer a post-migration date correction tool. When administrators report the wrong date issue after a GSMMO migration, Google support typically suggests sorting by "Sent" date in Outlook or using the Gmail web interface instead of an IMAP client. Neither suggestion addresses the root cause. Google's documentation for GSMMO doesn't even mention the date issue as a known limitation, and there's no GSMMO configuration option that prevents the "Received" header from being added during upload. It's a dead end.
Fixing GSMMO Dates with Redate.io
How Redate.io Works with Google Workspace
Redate.io connects to Google Workspace using domain-wide delegation via a Service Account, the same approach used by GSMMO and other Google-approved migration tools. The administrator creates a Service Account in the Google Cloud Console, grants the necessary Gmail API scopes, and provides the credentials to Redate.io. This allows Redate.io to access all mailboxes in the organization without requiring individual user passwords.
Scanning for Affected Emails
After connecting, Redate.io scans each mailbox and runs every email through its multi-stage analysis pipeline. The proprietary correction engine distinguishes between legitimate "Received" headers (from the original email delivery) and migration headers (added during the GSMMO upload) using pattern matching across hundreds of known migration signatures. The free scan report shows exactly how many emails are affected in each mailbox.
What the Fix Delivers
After Redate.io processes the mailbox, emails display the correct date in every client: Gmail web, Outlook, Apple Mail, Thunderbird. The mailbox's chronological order is restored. Sorting, searching, and filtering by date work correctly across all platforms. Every fix goes through integrity verification before it's finalized, and originals are preserved in a visible "Redate.io - Originals" label for 30 days.
And because GSMMO migrations involve particularly tricky edge cases (PST files can contain emails with corrupted MIME boundaries, missing headers, or legacy encoding formats that don't conform to modern standards), Redate.io's correction engine handles all of these variations. This is not a simple header edit, it's a complete analysis of each message's structure before any modification is made.
Platform-Specific GSMMO Fix Guides
Frequently Asked Questions
Can Redate.io fix dates from a GSMMO PST import?
Yes. Whether GSMMO uploaded emails from a live Outlook profile or from a PST file, Redate.io identifies and corrects the migration header no matter the source format.
What if GSMMO was used years ago?
The fix works no matter when the GSMMO migration was performed. The original "Date" header is preserved inside each email indefinitely. Redate.io can fix dates months or years after the migration was completed.
Does the fix affect Gmail labels and filters?
No. Redate.io preserves all Gmail labels, stars, read/unread status, and other metadata. The only change is the correction of the date-related data that was corrupted by the migration.
GSMMO migration broke email dates? Start a free scan with Redate.io to identify affected emails and restore correct dates across every mailbox in the Google Workspace organization.