Why a Migration Checklist Matters
Email migration is one of the riskiest IT operations an organization can take on. You're moving years of business communication between platforms, and one oversight can corrupt metadata across every single mailbox. The most common casualty? Email dates. After migration, every email may display the migration date instead of the original sent or received date.
This checklist covers every phase of the migration process. Follow these steps and you'll minimize the risk of date corruption and other metadata issues. And if you've already completed a migration and discovered date problems, keep reading.
Phase 1: Pre-Migration Planning
Inventory Your Mailboxes
Before touching any migration tool, document every mailbox that will be migrated. Record the total number of mailboxes, the approximate email count per mailbox, the date range of the oldest emails, and any shared mailboxes or distribution groups. This inventory determines which migration tool to use, how long the migration will take, and what pricing tier applies for any post-migration fixes if needed.
Choose the Right Migration Tool
Not all migration tools handle dates identically. Research how each tool handles IMAP INTERNALDATE preservation and whether it adds "Received" headers during the APPEND process. Popular tools include BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, and the Exchange Admin Center native import. Every one of these tools can cause date issues because the IMAP protocol itself requires the destination server to add a "Received" header on insertion. But some tools offer better INTERNALDATE preservation than others. For a deeper understanding of how INTERNALDATE works, see IMAP INTERNALDATE Explained: Why Dates Break.
Back Up Everything
Create a complete backup of every mailbox before migration. This backup serves as both a safety net and a reference point for verifying dates afterward. For Google Workspace, use Google Takeout or a third-party backup tool. For Microsoft 365, use Exchange Online backup or export to PST. For IMAP servers, use imapsync to create a local copy.
Store backups in a location completely separate from both the source and destination servers.
Document Original Dates
Select 10 to 20 emails per mailbox spread across different date ranges (oldest, newest, and several in between). Record the "Received" date, "Sent" date, and the raw email headers for each. These reference emails become your verification baseline after migration. Screenshot the inbox sorted by date so the original chronological order is visually documented.
Phase 2: Test Migration
Migrate a Test Mailbox First
Never run a full migration without testing first.
Create a test mailbox with a representative sample of emails (at least 100, spanning multiple years). Run the migration on this single mailbox and examine the results thoroughly before proceeding. This test reveals date issues, encoding problems, attachment handling bugs, and folder structure discrepancies before they affect production mailboxes.
Verify Dates on the Test Mailbox
After migrating the test mailbox, check the dates immediately. Open the mailbox in the email client that end users will actually use (Outlook, Apple Mail, Thunderbird, or the webmail interface). Compare the displayed dates against the reference emails documented in Phase 1. Check both the "Received" and "Sent" dates. Open the raw headers of several emails and look for newly added "Received" headers with the migration timestamp.
If dates are wrong on the test mailbox, they'll be wrong on every mailbox. Stop and address the issue before proceeding with the full migration.
Test With Multiple Email Clients
Different email clients display dates differently. Gmail's web interface may show correct dates (it uses the "Date" header) while Outlook shows the migration date (it prioritizes the "Received" header). Test with every client that users in the organization rely on, including Outlook Desktop, Outlook on the web, Apple Mail, Thunderbird, and any mobile email apps.
Phase 3: Migration Execution
Migration Tool Configuration
Configure the migration tool to preserve INTERNALDATE wherever possible. In imapsync, use the appropriate flags to set the INTERNALDATE on the destination. In BitTitan MigrationWiz, check the advanced settings for date handling options. These settings won't prevent "Received" header issues entirely, but they reduce the severity of date problems in some clients. Document every configuration setting used so the migration can be replicated if needed.
Migrate in Batches
Don't migrate all mailboxes simultaneously. Migrate in batches of 10 to 20 mailboxes, verifying dates after each batch. If a batch shows date problems, you catch it before it affects the entire organization. Batch migration also reduces the load on both source and destination servers, decreasing the risk of timeouts or connection errors that can cause partial migrations.
Monitor Progress
Track the migration progress for each mailbox. Record the start time, end time, number of emails migrated, and any errors. Migration tools typically provide logs, so save these for every mailbox. If date issues are discovered later, the logs help identify exactly which migration batch and settings were used.
Phase 4: Post-Migration Verification
Verify Dates Immediately
Check email dates within 24 hours of completing the migration. For each batch, open 5 to 10 mailboxes and compare dates against the pre-migration reference. If dates are wrong, document the scope of the problem (how many mailboxes affected, how many emails per mailbox) while the information is fresh.
Check All Folder Types
Date issues can affect some folders differently than others. Verify dates in the Inbox, Sent Items, Drafts, and any custom folders or labels. Some migration tools process folders sequentially, and errors in one folder don't necessarily indicate errors in others.
Verify Search and Sorting
Open a migrated mailbox, sort by date, and confirm the chronological order matches the original. Search for emails by date range and verify the results are accurate. Test any automated rules or filters that depend on received dates. If the organization uses compliance or eDiscovery tools, verify that date-based queries return correct results.
Common Mistakes That Cause Date Issues
Skipping the Test Migration
The single most common mistake is migrating all mailboxes without testing first. By the time date issues are discovered, every mailbox is affected and the source server may have been decommissioned. A 30-minute test migration can prevent weeks of remediation work. Why would anyone skip it?
Ignoring "Received" Header Additions
Administrators often focus on INTERNALDATE preservation and overlook the "Received" header issue. Even when INTERNALDATE is correctly set, the migration "Received" header causes Outlook and other clients to display the wrong date. This is the most common source of post-migration date complaints. Read why emails show wrong dates after migration for a full technical explanation.
Decommissioning the Source Server Too Soon
If date issues are discovered after the source server has been shut down, the option to re-migrate is gone. Keep the source server accessible (even in read-only mode) for at least 30 days after migration. This provides a fallback if serious issues surface later.
What to Do If Dates Are Already Broken
If the migration has already been completed and dates are wrong, the problem is fixable. The original "Date" header is preserved inside each email, which means the correct date information still exists. Email dates can be fixed after migration, even months or years later.
Redate.io's proprietary correction engine connects to the mailbox and scans for emails with corrupted date metadata. The multi-stage analysis pipeline identifies migration signatures, applies targeted corrections while preserving message integrity (including S/MIME signatures, multipart structures, and non-ASCII headers), and runs integrity verification on every single corrected email. The scan is free and shows exactly how many emails are affected. Originals are preserved in a visible backup folder for 30 days.
Attempting this kind of correction manually or with a custom script is tempting but risky. Edge cases like PGP-encrypted messages, corrupted MIME boundaries, nested multipart structures, and Content-Transfer-Encoding mismatches can silently corrupt emails in ways you won't notice until it's too late. And how do you verify that 10000 corrected emails are all intact?
Ready to check if your mailbox has date issues? Start a free scan with Redate.io - no payment required to see how many emails are affected.