Fix CloudM Migration Dates in Gmail

CloudM Migrate (formerly Cloud Migrator) uploads emails to Google Workspace using the Gmail API. During the upload, Gmail records the insertion timestamp as the message's INTERNALDATE. The original Date header inside the email body survives the migration. But the INTERNALDATE - the field that IMAP clients read to determine when a message was received - gets permanently overwritten with the migration date.

What makes CloudM migrations particularly confusing is the split behavior in Gmail. The Gmail web interface reads the Date header for display, so emails look perfectly fine in the browser. Open the same mailbox in Outlook via IMAP, and every email shows the migration date. Apple Mail, Thunderbird, mobile IMAP clients - same story. The problem is invisible to anyone who only uses Gmail on the web, which makes it harder to diagnose and easier to dismiss.

"The migration went fine, dates look correct." That is what the CloudM console tells you. That is what Gmail tells you. But 60% of your users connect through Outlook, and for them, 14 months of email history just collapsed into a single day.

The CloudM admin console in the Google Admin panel (Admin > Apps > Google Workspace Marketplace apps > CloudM Migrate) does not flag this as an issue. There is no error, no warning, no post-migration report that mentions INTERNALDATE corruption. It is a silent data quality problem that only surfaces when users complain.

The impact depends entirely on how users access their mailbox. Gmail web? Looks normal. Outlook, Apple Mail, Thunderbird via IMAP? Every email displays the migration date in the received column. This inconsistency generates confused support tickets and makes the problem difficult to explain to non-technical users.

Beyond display issues, the INTERNALDATE corruption reaches into compliance and backup infrastructure. Google Vault references the INTERNALDATE for certain retention and legal hold operations, which can compromise the accuracy of date-based eDiscovery searches. Third-party backup tools that connect via IMAP (Veeam, Spanning, Backupify) archive the migration date as the message date, creating permanent inaccuracies in backup records that may not be discovered until a restore is needed.

Redate.io corrects this through header chain analysis and date metadata reconstruction, targeting only CloudM-injected migration artifacts. The Gmail web experience (which already displayed correctly) stays unchanged. IMAP clients, Google Vault, and backup tools all start reading the original date. Each message is verified individually before and after correction to ensure zero data loss.