Email Migration Checklist: Prevent Date Problems

Why a migration checklist actually matters

Email migration is one of the riskiest IT operations an organization can attempt. You're moving years of professional communication between platforms, and a single oversight can corrupt the metadata across every mailbox. The most common casualty? Email dates. After migration, each email risks showing the migration date instead of the original sent or received date.

This checklist covers every phase of the migration process. Follow these steps to minimize the risk of date corruption and other metadata problems. And if the migration is already done and date issues have appeared, keep reading.

Phase 1: pre-migration planning

Inventory your mailboxes

Before touching a migration tool, document every mailbox that will be migrated. Record the total number of mailboxes, the approximate number of emails 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 applies for any post-migration corrections.

Choose the right migration tool

Not all migration tools handle dates the same way. Research how each tool manages IMAP INTERNALDATE preservation and whether it adds "Received" headers during the APPEND process. Popular tools include BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, and the native Exchange Admin Center import. Each of these can cause date problems because the IMAP protocol itself requires the destination server to add a "Received" header on insertion. But some tools preserve INTERNALDATE better than others. For a deeper look at how INTERNALDATE works, see IMAP INTERNALDATE explained: why dates break.

Back up everything

Create a full backup of every mailbox before the migration. This backup serves both as a safety net and as 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 PST export. For IMAP servers, use imapsync to create a local copy.

Store backups in a location completely separate from both source and destination servers.

Document original dates

Select 10 to 20 emails per mailbox spread across different date ranges (the oldest, the most recent, and several in between). Record the "Received" date, the "Sent" date, and the raw headers of each email. These reference emails become your verification baseline after migration. Take a screenshot of the mailbox sorted by date to visually document the original chronological order.

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 several years). Run the migration on that single mailbox and examine the results thoroughly before continuing. This test reveals date problems, encoding errors, 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 be using (Outlook, Apple Mail, Thunderbird, or the webmail interface). Compare the displayed dates against the reference emails documented in Phase 1. Check both "Received" and "Sent" dates. Open the raw headers on several emails and look for newly added "Received" headers carrying the migration timestamp.

If dates are wrong on the test mailbox, they'll be wrong on every mailbox. Stop everything and fix the problem 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 favors the "Received" header). Test with every client your organization's users rely on, including Outlook Desktop, Outlook on the web, Apple Mail, Thunderbird, and any mobile email apps in use.

Phase 3: migration execution

Migration tool configuration

Configure the migration tool to preserve INTERNALDATE as much as possible. In imapsync, use the appropriate flags to set INTERNALDATE on the destination. In BitTitan MigrationWiz, check the advanced settings for date handling options. These settings won't completely prevent "Received" header issues, but they do reduce the severity of date problems in some clients. Document every configuration setting used so you can reproduce the migration if needed.

Migrate in batches

Don't migrate all mailboxes at once. Migrate in batches of 10 to 20 mailboxes and verify dates after each batch. If one batch shows date problems, you catch them before the entire organization is affected. Batch migration also reduces load on source and destination servers, cutting the risk of timeouts or connection errors that can cause partial migrations.

Monitor progress

Track migration progress for each mailbox. Record the start time, end time, number of emails migrated, and any errors. Migration tools typically generate logs, so keep them for every mailbox. If date problems are discovered later, those logs help identify exactly which migration batch and which settings were used.

Phase 4: post-migration verification

Verify dates immediately

Check email dates within 24 hours of migration. For each batch, open 5 to 10 mailboxes and compare dates against your pre-migration references. 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 problems can affect certain folders differently. 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 mean errors in others.

Verify search and sorting

Open a migrated mailbox, sort by date, and confirm that the chronological order matches the original. Search for emails by date range and verify that results are accurate. Test any automated rules or filters that depend on received dates. If your organization uses compliance or eDiscovery tools, verify that date-based queries return correct results.

Common mistakes that cause date problems

Skipping the test migration

The most common mistake is migrating all mailboxes without testing first. When date problems are discovered, every mailbox is affected and the source server may already have been decommissioned. A 30-minute test migration can prevent weeks of remediation. Why skip it?

Ignoring "Received" header additions

Admins often focus on INTERNALDATE preservation and overlook the "Received" header problem. 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 complaints. Read why emails show wrong dates after migration for a full technical explanation.

Decommissioning the source server too soon

If date problems are discovered after the source server is shut down, the re-migration option is gone. Keep the source server accessible (even read-only) for at least 30 days after migration. That gives you a fallback if serious issues surface later.

What to do if dates are already wrong

If the migration is already done and dates are incorrect, the problem is fixable. The original "Date" header is preserved in every email, which means the correct date information is still there. Email dates can be corrected after migration, even months or years later.

Redate.io's proprietary correction engine connects to the mailbox and identifies emails with corrupted date metadata. The multi-stage analysis pipeline detects migration signatures, applies targeted corrections while preserving message integrity (including S/MIME signatures, multipart structures, and non-ASCII headers), and runs an integrity check on every corrected email. The scan is free and shows exactly how many emails are affected. Originals are kept 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 without anyone noticing until it's too late. And how do you verify that 10,000 corrected emails are all intact?

Ready to check if your mailboxes have date problems? Run a free scan with Redate.io - no payment required to see how many emails are affected.