Google Workspace to Google Workspace Migration: Broken Dates

The scenario nobody suspects

You just finished migrating one Google Workspace tenant to another. An acquisition, a domain change, a merger of two entities that had coexisted under separate G Suite accounts for years. The operation went smoothly, mailboxes are in place, users are logging in. Monday morning, first ticket: "All my emails have the same date." Then a second. Then ten.

Your instinct says: it's an IMAP problem, a misconfigured tool, something exotic. Not a Google-to-Google migration. And yet, that's exactly where it's happening.

This is probably the least documented scenario in the industry. Most IT admins who run into it spend hours looking for an explanation on the mail client side, in Outlook settings, in account configuration, before realizing the problem is in the email headers themselves.

Why a Google-to-Google migration breaks dates

To understand what's going on, you need to go back to how email headers work. Every RFC 2822 message contains an original Date: field, set by the sending client or server at the time of delivery. That's the "real" date of the email, the one that corresponds to when the message was written and sent.

But there's another mechanism: IMAP INTERNALDATE. It's a server-side metadata field that records when the message was deposited into the mailbox. And this is where things get interesting.

When a migration tool transfers an email from one Google Workspace tenant to another, it goes through the IMAP protocol (even if both servers are at Google). The message is read from the source, then reinserted into the destination. At the moment of reinsertion, the destination server automatically adds a Received: header with the timestamp of the operation, meaning the migration date.

And clients like Outlook use the first Received: header in the chain to display a message's date, not necessarily the original Date: field. Result: every email shows the migration date.

Which tools trigger the problem

Practically every tool used for Google Workspace inter-tenant migrations is affected. No notable exceptions:

• GSMMO (Google Workspace Migration for Microsoft Outlook): originally built to migrate from Exchange, but used in some GWS-to-GWS workflows.
• CloudM Migrate: widely used by MSPs for inter-Google migrations, systematically adds a migration Received: header. See the detailed CloudM analysis.
• BitTitan MigrationWiz: same behavior, documented in this article on BitTitan.
• imapsync: the open-source tool for scripting IMAP migrations, including between two Google tenants.
• Manual exports/imports via Takeout + IMAP reimport: less common, but produces exactly the same effect.

The reason is simple: all these tools function as standard IMAP clients. They don't have access to a "native" Google pathway that would preserve metadata. Even if both tenants are at Google, the transfer goes through the IMAP layer, and that layer has no idea it's talking to itself.

The Received header mechanics, in detail

(If you've ever tried reading raw email headers in Gmail or Outlook, you know it's not exactly beach reading. But that's where all the truth hides.)

An email that traveled normally contains a chain of Received: headers in reverse order of its journey: the last server to touch the message is at the top. After a migration, the migration header ends up at the very top of the stack.

Here's what it looks like in a message migrated via CloudM from one GWS tenant to another:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <user@new-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

The Date: field says 2019. The first Received: says October 2024. Outlook reads the first Received:. The user sees October 2024 for an email from 2019.

The original Date: field is intact. It hasn't moved. That's the good news: the data is there, it's just waiting to be used correctly.

Outlook and Gmail don't behave the same way

This distinction matters. Users accessing their email via Gmail's web interface often see the correct dates, because Gmail prioritizes the RFC 2822 Date: field when displaying messages. The problem is less visible on the web side.

But users who configure their Google Workspace mailbox in Outlook via IMAP (or via Exchange ActiveSync sync) get hit hard with the wrong date, because Outlook relies on the IMAP INTERNALDATE, which reflects the date of the first Received: header added during migration.

Actually, to be precise: Outlook's behavior varies by version and connection mode. Outlook 2019 and Microsoft 365 (recent versions) use INTERNALDATE when connecting over IMAP. Older versions may behave slightly differently. But in every production case observed, a GWS-to-GWS migration via IMAP produces incorrect dates in Outlook.

So in organizations that migrated to a new tenant and have hybrid users (some on Gmail web, others on Outlook), the ticket patterns make no sense at first glance. IT teams spend time trying to figure out why "some users are affected and others aren't", when the answer is simply: it's the mail client that makes the difference.

Acquisitions, mergers, domain changes: the most common cases

This type of migration isn't rare. Here are the scenarios that generate the most tickets:

Company acquisition

An acquired company had its own Google Workspace tenant (@oldcompany.com). After the acquisition, everything needs to move to the parent company's tenant (@group.com). The 250 mailboxes, the archives, 8 years of email history. BitTitan or CloudM is brought in for the job. Result: 2.4 million emails with the migration weekend's date.

Domain change

A rebranded company moves from @oldname.com to @newname.com. Same Google infrastructure, but a new tenant is created for a clean start (a common choice to avoid configuration artifacts). Mailboxes migrated via imapsync or GSMMO. Dates break in exactly the same way.

Subsidiary consolidation

A group with 4 subsidiaries, each on their own legacy G Suite tenant, decides to consolidate everything into a single tenant. Four parallel migrations, four batches of corrupted email dates to deal with.

In all three scenarios, the problem is identical and the solution is the same. The email migration checklist helps anticipate this kind of problem before the migration starts.

Why a homemade script isn't the answer

Understanding the problem is one thing. Deciding to write a Python script that cleans up headers and running it on 30,000 production emails is another thing entirely.

Edge cases are everywhere. A script that works on 50 test emails in a clean environment will inevitably hit, on a real production mailbox:

• Messages with S/MIME signatures or PGP-encrypted content, where any modification to the message structure invalidates the cryptographic signature.
• Emails with complex nested MIME structures (multipart/alternative inside a multipart/mixed with attachments weighing several dozen megabytes).
• Headers encoded in RFC 2047 (non-ASCII characters), which poorly configured parsers silently mangle.
• 429 Too Many Requests errors from the Google API at 2 AM, mid-batch, leaving the process in an indeterminate state.
• Emails where the Received: chain is ambiguous: multiple successive migration tools have each added their own header, and it's not trivial to determine which one to target.

And the most important question: how do you verify, email by email, that every corrected message is intact and nothing was lost or corrupted? A homemade script generally doesn't do that verification. Redate.io does it automatically, with originals preserved in a visible backup folder for 30 days.

What Redate.io does with this type of migration

Redate.io connects to the destination Google Workspace tenant (via domain delegation, without manual per-mailbox intervention) and scans emails to identify those whose date metadata is inconsistent with the message content. This scan phase is free and gives an exact picture of the problem's scope before any correction happens.

The proprietary correction engine then analyzes the header chain of each message, applies pattern matching across known migration tool signatures (BitTitan, CloudM, imapsync, GSMMO, and others), and performs targeted metadata correction without altering the message content. Each corrected email is verified individually. Originals are preserved.

For Google Workspace inter-tenant migrations specifically, the pipeline handles cases where multiple migration passes have occurred (for example, a mailbox migrated first in 2021 and again in 2024), with multiple layers of spurious headers to untangle.

The fix guides for CloudM to Google Workspace and BitTitan to Google Workspace detail the connection steps for this type of configuration.

Catching the problem before users complain

The best time to detect corrupted dates is right after the migration, before go-live. A quick check on a few pilot mailboxes via an IMAP client like Thunderbird lets you compare displayed dates against what you'd expect. If all imported emails appear to share the same recent date, that's the telltale sign.

In practice, though, the problem is usually discovered weeks after the migration, when a user searches for an old contract and realizes their Gmail inbox is perfectly sorted... by migration date. Thousands of emails stacked at the same timestamp. Date-based search no longer works. Conversation threads are out of order. The entire history seems to have vanished.

For MSPs who regularly handle Google Workspace inter-tenant migrations, adding a Redate.io scan to the post-migration checklist (before client sign-off) prevents exactly this kind of surprise.

You just migrated between two Google Workspace tenants and your email dates are wrong? Run a free scan on Redate.io to measure the impact before any correction.