CloudM Migrate: How to Fix Wrong Email Dates

The CloudM Migrate Date Problem Nobody Warns You About

CloudM Migrate finished the job. The dashboard says 100% complete, all users migrated, zero errors. You close the project ticket and move on to the next client.

Then a week later, the IT director calls. "Why does every email in my inbox say April 2nd?"

Not some emails. All of them. Five years of client correspondence, legal documents, HR records, purchase orders from 2020, all showing the date CloudM ran the migration. The messages are there, the content is intact, attachments are fine. But the dates are wrong on every single one.

This isn't a CloudM bug. CloudM's own support documentation acknowledges it openly. The problem sits at the intersection of how migration tools transfer messages and how destination mail servers handle incoming email metadata. But knowing that doesn't help your client whose inbox just became unsortable.

How CloudM Actually Transfers Email Messages

CloudM Migrate connects to source and destination platforms through their APIs. For Google Workspace, that means a service account with domain-wide delegation (configured in the Google Admin Console under Security > API Controls). For Microsoft 365, it uses either Exchange Web Services or Microsoft Graph API, depending on the migration path.

When CloudM reads a message from the source, it gets the full RFC 2822 content, including all original headers and the message body. The original Date: header (the one the sender's mail server stamped when the email was first sent) comes along intact. So do all the original Received: headers that trace the message's delivery path.

The problem happens at the destination. When CloudM writes that message into the target mailbox, the destination server treats it like a new delivery. It stamps a fresh Received: header with the current date and time, and sets the INTERNALDATE (the timestamp IMAP uses for sorting) to the moment of insertion.

Here's what the header chain looks like after a CloudM migration to Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

The 2019 header is right there. The original Date: header still says September 23, 2019. But Outlook reads the topmost Received: header to determine display order, and that one says April 2, 2026.

CloudM's "Strip Received Headers" Setting

CloudM does offer a setting to address this. In the destination platform's Advanced Settings, under Message Options, there's a "Strip Received Headers" toggle. When enabled, CloudM removes the received headers before inserting the message and replaces them with a single header matching the email's Date: header.

Sounds like it solves everything, right? Not quite.

First, you have to know about it before running the migration. Most admins discover the date problem after the migration is complete. By then, the messages are already sitting in the destination with wrong dates. Re-running CloudM with the setting enabled just creates duplicates, it doesn't fix what's already there.

Second, this setting has a hard limitation when Google Workspace is the destination. Google's own documentation confirms it: Gmail always rewrites Received: headers on messages inserted via API, stamping them with the insertion timestamp. This is a platform-level restriction that CloudM cannot override. Even with "Strip Received Headers" enabled, Google Workspace adds its own Received: header with the migration date.

For Microsoft 365 destinations, the setting works better in theory, but the M365 transport pipeline has its own behavior. Exchange Online may still set the INTERNALDATE based on its own delivery processing, depending on how the message enters the system.

Which CloudM Migrations Break Dates (and Which Don't)

Not every CloudM migration produces wrong dates. The outcome depends on the source-destination combination and the specific API path CloudM uses:

• Google Workspace to Microsoft 365: Dates break. CloudM reads via Gmail API and writes to Exchange. The M365 transport layer stamps new Received headers.
• Microsoft 365 to Google Workspace: Dates break. Even with Strip Received Headers, Google's API rewrites the Received header with the insertion date. CloudM's support documentation calls this a "strict platform limitation."
• Google Workspace to Google Workspace: Dates break. Domain switches, tenant consolidations, acquisition mergers, the destination Google tenant always stamps the migration date on incoming messages.
• On-premises Exchange to Microsoft 365: Usually breaks via IMAP path. If CloudM uses EWS on both sides, date preservation is more reliable but not guaranteed.
• IMAP source (generic) to any destination: Dates break. When CloudM connects to a generic IMAP server as source, the destination still adds its own delivery headers.

The tricky part? CloudM's migration dashboard doesn't flag any of this. The progress bar fills up, the status column says "Completed," item counts match. From CloudM's perspective, the migration succeeded. And technically, it did. The messages transferred. The dates just didn't survive the trip.

CloudM Managed vs. Self-Service: Same Date Problem

CloudM offers two deployment models. The SaaS version (CloudM Migrate hosted) runs entirely in CloudM's infrastructure. The self-hosted version lets you deploy primary and secondary migration servers on your own network, Google Cloud, Azure, or AWS.

Some MSPs assume the self-hosted option gives more control over date handling since you manage the migration servers directly. It doesn't. The date problem happens at the destination server, not on CloudM's processing nodes. Whether your migration farm runs in CloudM's cloud or on your own Azure VM, the destination mail server still stamps the migration date on every message it receives.

CloudM also offers fully managed "Serviced Migration" where their team handles the project end to end. Same outcome for dates. The engineering is identical, the hands on the keyboard are just different. Have you ever paid for a premium service and still gotten the same limitation as the free tier? That's what this feels like.

The Invalid Date Header Complication

There's another CloudM-specific behavior that makes things worse. When CloudM encounters a source email with a Date: header that doesn't comply with RFC 822 (malformed timezone, missing day of week, non-standard format), it modifies the header to ensure the message can be migrated.

This means some emails lose even their original date reference. The modified Date: header might not match the real send date at all. CloudM's support documentation mentions this as a known behavior under "Possible Changes to Migrated Items" but doesn't specify what the modified date becomes.

For a mailbox with 12,000 messages accumulated over eight years, you might have hundreds of emails with slightly non-standard Date headers (especially messages from older mail servers, automated systems, or international senders with timezone formatting quirks). After CloudM's modification plus the destination server's Received header rewrite, these messages end up with dates that bear no resemblance to reality.

Why Manual Fixes Don't Scale After CloudM

Could you fix this yourself? Technically, the original Date: header is still embedded in most messages (except the ones CloudM modified for RFC compliance). Some admins have tried writing scripts to correct dates after a CloudM migration.

Here's the reality of that approach. You're looking at connecting to potentially thousands of mailboxes, each with thousands of messages. For every email, you need to parse the full header chain, identify which Received: headers CloudM or the destination server added, handle the edge cases (S/MIME signed messages where header modification breaks the signature, PGP-encrypted content, multipart MIME structures with nested boundaries, RFC 2047 encoded non-ASCII headers from Japanese or Korean senders), and do all of this without losing a single attachment or breaking email threading.

A script that works on 50 test emails from a clean mailbox won't survive contact with a production environment of 40,000 messages spanning a decade. What happens when you hit a 47 MB email with six nested attachments? What about the API rate limits (Google's 250 quota units per user per second, Microsoft's throttling at around 10,000 requests per 10 minutes)? What's your rollback plan when something goes wrong on message number 8,347?

And the real question most admins don't ask until it's too late: how do you verify that each corrected message is actually intact?

Fixing CloudM Migration Dates with Redate.io

Redate.io connects directly to the affected mailboxes (Google Workspace, Microsoft 365, or IMAP) and scans for emails carrying CloudM's migration date signature. The scan is free and takes a couple of minutes per mailbox, showing the exact count of affected messages before any commitment.

The correction uses a proprietary header chain analysis engine that identifies CloudM-specific migration patterns across the Received header chain. Redate.io performs targeted metadata correction without altering message content, preserving attachments, threading, labels, folders, and digital signatures. Every corrected message goes through individual verification, checking message integrity against the original before the process moves forward.

Original emails are kept in a visible Redate.io - Originals backup folder for 30 days. If anything needs to be rolled back, the originals are right there in the mailbox, not buried in some external archive.

For MSPs who used CloudM on client environments, Redate.io handles multi-mailbox corrections at scale, with the same per-message verification whether you're fixing 1 mailbox or 500. The date problem CloudM left behind doesn't have to become a permanent feature of your client's mail environment.

Platform-Specific Guides for CloudM Migrations

The correction process adapts to the destination platform. Redate.io handles each platform's specifics automatically, but for details on your setup:

• Fix CloudM migration dates in Gmail
• Fix CloudM migration dates in Outlook
• Fix CloudM migration dates in Google Workspace
• Fix CloudM migration dates in Microsoft 365

For a deeper explanation of why this happens across all migration tools, not just CloudM, see why emails show wrong dates after migration.

Migrated with CloudM and stuck with wrong dates on every email? Run a free scan to see exactly how many messages are affected and what it costs to fix them.