The Google Workspace Migration Date Problem
Organizations migrating to Google Workspace frequently discover something unpleasant: every email in every mailbox shows the wrong date. Instead of displaying the original sent or received date, each message shows the date the migration was performed. It doesn't matter whether the organization migrated from Microsoft Exchange, Office 365, Zimbra, Lotus Notes, or another IMAP server. Thousands of emails, all stamped with a single migration date.
And this isn't specific to any one migration tool. It happens with BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync, and every other tool that inserts emails into Google Workspace via IMAP or the Gmail API. The cause is a fundamental aspect of how email servers handle message insertion, and it affects every migration into Google Workspace.
For a guide specific to the GSMMO tool (Google Workspace Migration for Microsoft Outlook), see the dedicated GSMMO article.
Common Migration Paths to Google Workspace
From Microsoft Exchange (On-Premises)
Organizations running on-premises Exchange servers (2010, 2013, 2016, or 2019) migrate to Google Workspace to reduce infrastructure costs and move to a cloud-first model. These migrations typically use CloudM, BitTitan MigrationWiz, or GSMMO. The migration tool connects to Exchange, downloads each email, and uploads it to the user's Google Workspace mailbox. Every uploaded email receives a new "Received" header with the migration timestamp.
From Microsoft 365 (Office 365)
Migrations from Microsoft 365 to Google Workspace are common when organizations switch ecosystems. BitTitan MigrationWiz and CloudM are the most popular tools for this path. The migration process extracts emails from Exchange Online and inserts them into Google Workspace. The same "Received" header issue applies - every migrated email shows the migration date.
From Other IMAP Servers
Migrations from Zimbra, Zoho, cPanel-hosted email, Dovecot, Courier, and other IMAP servers to Google Workspace use tools like imapsync, CloudM, or custom scripts. The destination (Google Workspace) adds a "Received" header during the insertion operation no matter what the source platform is. Even migrations from another Google Workspace tenant produce the same issue.
Why Dates Break in Google Workspace
The Gmail Web Interface vs. IMAP Clients
Google Workspace presents a unique situation. The Gmail web interface typically uses the email's "Date" header to display the message date, which means emails often appear with the correct date when viewed through Gmail's web UI. However, when the same mailbox is accessed through an IMAP client (Outlook, Apple Mail, Thunderbird), the client reads the topmost "Received" header and displays the migration date.
This discrepancy causes significant confusion. An administrator testing the migration in the Gmail web interface sees correct dates and assumes the migration was successful. But when users connect Outlook to their Google Workspace account, they report that every email has the wrong date. The problem exists on the server (the email headers contain the migration timestamp) but it only becomes visible in certain clients. How many IT admins have closed a migration project thinking everything was fine, only to get flooded with tickets the next Monday?
The IMAP INTERNALDATE Factor
Google Workspace stores an INTERNALDATE for each email, which is set during the insertion process. Some migration tools correctly set this to the original date, while others leave it as the migration date. But even when the INTERNALDATE is correct, IMAP clients that prioritize "Received" headers (like Outlook) still display the wrong date. The complete fix requires both removing the migration "Received" header and ensuring the INTERNALDATE is set correctly. For a detailed technical explanation, see why emails show wrong dates after IMAP migration.
Google Workspace Admin Options (That Don't Work)
Google Admin Console
The Google Admin Console provides extensive controls for Google Workspace management, but it doesn't include any feature for correcting email dates after migration. No bulk header editing tool. No date correction utility. No way to modify the INTERNALDATE of existing emails through the admin interface.
Google Apps Script
Google Apps Script can automate many Gmail operations, but it can't modify raw email headers. The GmailApp and Gmail API services exposed through Apps Script allow reading messages, changing labels, and modifying metadata, but they don't support replacing the raw RFC 2822 content of a message. The fix requires working at a much deeper level than what Apps Script exposes.
Google Data Migration Service
Google's own Data Migration Service (available in the Admin Console) is designed for migrating emails into Google Workspace, not for fixing headers after migration. Running a second migration with this tool would add yet another "Received" header, making the problem worse.
Fixing Google Workspace Dates with Redate.io
How Admin Delegation Works
Redate.io uses Google Workspace's domain-wide delegation feature to access mailboxes. The administrator creates a Service Account in the Google Cloud Console, grants it the necessary Gmail API scopes, and enables domain-wide delegation. This allows Redate.io to process any mailbox in the organization without requiring individual user credentials.
The delegation setup takes about 10 minutes and follows the same process used by other Google Workspace migration and management tools. Once configured, the administrator can scan and fix any number of mailboxes from the Redate.io dashboard.
Getting Started
Create a Service Account. In the Google Cloud Console, create a new project (or use an existing one), enable the Gmail API, and create a Service Account with domain-wide delegation enabled.
Grant API Scopes. In the Google Workspace Admin Console, navigate to Security, then API controls, then Domain-wide delegation. Add the Service Account's client ID and grant the Gmail API scopes required by Redate.io.
Connect in Redate.io. Log in to Redate.io, select "Google Workspace" as the platform, and upload the Service Account JSON key file. Redate.io validates the connection and lists available mailboxes.
Scan Mailboxes. Select the mailboxes to scan (or scan all). The free scan identifies how many emails in each mailbox have wrong dates. No payment is required for scanning.
Fix. Review the scan results, select a plan, and start the fix. Redate.io's proprietary correction engine processes each mailbox, running every email through a multi-stage analysis pipeline that handles encoding issues, multipart message structures, digital signatures, and dozens of edge cases that would cause a DIY script to corrupt data. Progress is visible in real time. Original messages are preserved in a "Redate.io - Originals" label for 30 days.
After the Fix
Once Redate.io completes the fix, emails display the correct date in every client: Gmail web, Outlook, Apple Mail, Thunderbird, and any other IMAP-connected application. The fix is permanent. No ongoing maintenance or subscription is required. Users can sort by date, search by date range, and use compliance tools with confidence that the timestamps are accurate. The mailbox works the way it should have worked from day one.
Tool-Specific Guides for Google Workspace
For detailed instructions based on the specific migration tool used, see these platform-specific guides:
Migrated to Google Workspace and every email shows the wrong date? Start a free scan with Redate.io to see how many emails are affected across all mailboxes and restore correct dates.