BitTitan MigrationWiz: Fix Wrong Email Dates

What BitTitan MigrationWiz Does to Email Dates

You finished the migration last Friday. 47 mailboxes moved from on-prem Exchange to Microsoft 365, all green in the MigrationWiz dashboard. Then Monday morning hits, and the first ticket comes in: "All my emails show March 28, 2026."

Every single message. Years of correspondence, client proposals from 2019, invoices from 2021, all stamped with the migration date. The MigrationWiz log says everything transferred successfully (and it did, technically). But the dates are gone.

BitTitan MigrationWiz is one of the most widely used tools for cloud-to-cloud email migration. It handles Exchange to Microsoft 365, Google Workspace to Exchange, cross-tenant moves, you name it. The tool itself works well for what it does. The date problem isn't a bug in MigrationWiz. It's a consequence of how IMAP migration works at the protocol level, and MigrationWiz triggers it in a specific way.

How MigrationWiz Handles Received Headers

When MigrationWiz transfers an email from source to destination, it uses the IMAP protocol (or Exchange Web Services, depending on the endpoint type). During this process, the destination mail server stamps the message with a new Received: header containing the current timestamp, exactly the way it would stamp any incoming email.

Here's what a typical Received header chain looks like after a MigrationWiz migration:

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

The original Received: header from 2019 is still there. So is the original Date: header. But email clients like Outlook don't use those. Outlook reads the most recent Received: header to determine when to display the message, and that header now says March 28, 2026.

The INTERNALDATE value (the timestamp IMAP servers use for sorting) also gets overwritten during the transfer. MigrationWiz does attempt to preserve dates when the destination supports it, but the result depends heavily on the destination server's behavior. Microsoft 365's transport pipeline, for instance, overwrites the INTERNALDATE with its own delivery timestamp regardless of what MigrationWiz requests.

Why MigrationWiz Date Mapping Falls Short

BitTitan offers a "Date Mapping" feature in the MigrationWiz Advanced Options. On paper, it sounds like the solution. In practice? It controls which date range of messages to migrate, not how dates are preserved at the destination.

The confusion is understandable. The setting says "date" right there in the name. But what it actually does is filter source messages by date range before migration. A message from 2018 still arrives at the destination with the migration timestamp.

There's also the question of IMAP vs. Exchange endpoints. When MigrationWiz migrates between two Exchange servers using EWS (Exchange Web Services), date preservation works better because EWS has more control over message metadata. But the moment IMAP is involved on either side, whether source or destination, the IMAP APPEND operation takes over and the destination server decides what timestamp to use.

Some admins have tried re-running the migration with different endpoint configurations, hoping that switching from IMAP to EWS would fix the dates retroactively. It doesn't. The messages are already at the destination with wrong dates. Running MigrationWiz again would just create duplicates.

Specific MigrationWiz Scenarios That Break Dates

Not every MigrationWiz migration causes date issues. The problem depends on the endpoint combination:

• Exchange (on-prem) to Microsoft 365 via IMAP: Dates break. The M365 transport pipeline stamps new Received headers and overwrites INTERNALDATE.
• Google Workspace to Microsoft 365: Dates break. MigrationWiz uses IMAP to read from Google and writes to M365, which adds its transport headers.
• Exchange to Exchange (EWS to EWS): Dates are usually preserved. EWS bypasses the transport pipeline on both sides.
• Anything to Google Workspace via IMAP: Dates break. Google's IMAP implementation adds a Received header with the insertion timestamp.
• Cross-tenant Microsoft 365: Depends on the method. IMAP path breaks dates. Direct EWS may preserve them.

The MigrationWiz dashboard doesn't flag date issues. Everything shows as "Completed" because the messages did transfer successfully. The content is intact, attachments are fine, folder structure is preserved. It's only the dates that changed, and MigrationWiz doesn't track that as a migration error.

The Real Cost of Wrong Dates After MigrationWiz

Wrong email dates aren't just annoying. For organizations that migrated with BitTitan, the consequences go beyond a messy inbox.

Legal teams can't use emails as evidence when every message shows the migration date instead of the actual send date. Tax audits require chronological proof of communications. Compliance frameworks like SOX, HIPAA, and GDPR mandate accurate record-keeping, and emails with fabricated timestamps fail that requirement.

And then there's the practical side. Try finding that contract discussion from November 2022 when your entire mailbox shows March 2026. Sort by date? Useless. Search by date range? Returns everything or nothing.

For MSPs who used MigrationWiz on client environments, this creates a liability issue. The client paid for a migration. They got one, but their email archive is effectively broken for date-based workflows.

One MSP we heard from had migrated around 380 mailboxes for a law firm. Three months later, the firm's litigation team discovered the date issue during document discovery. Every email they needed to present as evidence showed the migration date. The MSP had to explain why 6 years of timestamped correspondence now all said June 2025.

Fixing BitTitan MigrationWiz Dates

The original Date: header is still inside every email. MigrationWiz doesn't touch the message body or the original headers. It's the additional Received: header and the overwritten INTERNALDATE that cause the display problem.

Redate.io connects to the mailbox (Google Workspace, Microsoft 365, or IMAP), scans for emails affected by the MigrationWiz migration, and corrects the date metadata through a proprietary multi-stage analysis pipeline. The correction targets the metadata layer specifically, pattern matching against known MigrationWiz header signatures including the characteristic mx.migrationwiz.com and bittitan.com identifiers in the Received chain.

Every corrected email is individually verified against the original. The verification checks message integrity, attachment preservation, folder placement, and threading. Original emails are kept in a visible Redate.io - Originals folder for 30 days in case a rollback is needed.

Understanding the problem is one thing. Correcting 15,000 emails without losing a single attachment, breaking S/MIME signatures, or corrupting multipart MIME boundaries is another. A script that works on 10 test messages in a lab won't handle the edge cases of a production mailbox with 7 years of correspondence, PGP-encrypted messages, and RFC 2047 non-ASCII headers.

How do you verify that each corrected message is intact? That the threading still works, that calendar invites still resolve, that the 47 MB attachment on that one email from 2020 didn't get corrupted? Redate.io does this automatically, for every single message. And if something looks off, the original is right there in the backup folder.

The free scan takes about two minutes. It connects to the mailbox, identifies every email stamped with the MigrationWiz migration date, and shows you the exact count and cost before you pay anything. No credit card, no commitment.

Platform-Specific Fix Guides for BitTitan

The fix process varies depending on where MigrationWiz moved your emails. Redate.io handles each platform's specifics automatically, but if you want details on your specific setup:

• Fix BitTitan dates in Outlook
• Fix BitTitan dates in Microsoft 365
• Fix BitTitan dates in Google Workspace
• Fix BitTitan dates in Exchange Online

Redate.io also works for migrations completed months or years ago. The original Date header doesn't expire.

Migrated with BitTitan MigrationWiz and stuck with wrong dates? Run a free scan to see exactly how many emails are affected before committing to anything.