Fix CloudM Migration Dates in Google Workspace

CloudM Migrate is one of the most popular tools for moving mailboxes into Google Workspace, especially from Exchange environments. During migration, CloudM uploads each message through the Gmail API. The problem? Google's mail infrastructure adds its own Received header to every uploaded message, stamped with the exact moment the migration occurred - not the date the email was originally sent or received.

Here is where it gets strange. Gmail's web interface reads the original Date header for display purposes, so emails look perfectly fine in the browser. But every IMAP client - Outlook, Apple Mail, Thunderbird - reads the INTERNALDATE value instead. That value reflects the migration timestamp. So you end up with a split reality: half your users report no problems at all, while the other half insist every email shows the same date.

Think about what that does to an IT helpdesk ticket. The admin opens Gmail in a browser, sees correct dates, and closes the ticket as "cannot reproduce." Meanwhile, the Outlook user is staring at 47,000 emails all dated March 15th. This discrepancy between Gmail web and IMAP clients makes CloudM-to-Google-Workspace migrations particularly tricky to diagnose, often delaying resolution by weeks.

The damage goes beyond confused users. Google Workspace administrative tools reference the INTERNALDATE for policy enforcement. Retention policies configured in the Google Admin Console, Google Vault legal holds, and third-party DLP solutions that connect via IMAP - all of them operate on the migration timestamp instead of the real date. An email from 2019 that should have been purged under your 3-year retention policy? Google Workspace thinks it arrived last month.

For organizations in regulated industries (healthcare, finance, legal), this is not just an inconvenience. Compliance audits that depend on accurate email date ranges produce unreliable results. And the issue persists indefinitely - there is no automatic correction, no expiration, no self-healing. Every IMAP client connected to every affected Google Workspace mailbox will continue showing wrong dates until the underlying metadata is corrected at the server level.