Post-Migration Validation: The Checklist That Catches Real Problems

The migration tool says complete. Now you have to prove it. Post-migration validation is the difference between a clean cutover and a slow-rolling support disaster that only becomes obvious when the CFO cannot find an invoice from March. This guide gives you a validation sequence — automated checks first, then sampled manual review, then platform-specific tests — that catches the real problems while you can still attribute them to the migration.

What post-migration validation actually proves#

Validation is not "the user can sign in". Sign-in proves identity works. Validation proves three things beyond that:

1. The content that was at the source is now at the destination, with the right metadata.
2. The behaviour that worked at the source still works at the destination — calendar, rules, signatures, mobile push, shared access.
3. Outbound mail flow is healthy from the destination, accepted by external recipients, and matching SPF/DKIM/DMARC.

Each of those needs its own check. None of them is implied by the migration tool's "success" message.

If you only have time for one habit from this guide, make it this: every validation step produces an artefact (a count, a screenshot, a delivery receipt). No artefact means the step did not happen.

The validation sequence#

Run the checks in this order. Earlier checks gate later ones.

1. Tool-level success status
2. Message-count delta per mailbox
3. Folder structure compare
4. Sample mailbox manual review
5. Calendar invite round-trip test
6. Rules and out-of-office check
7. Mobile re-provisioning
8. Shared mailbox access verification
9. Mail flow and deliverability check

This sequence works because failures at step 2 invalidate the assumptions behind steps 3–9. A mailbox with a 30% count gap is a mailbox you need to re-migrate, not a mailbox you need to manually inspect.

For the broader migration context this validation slots into, pair it with the email migration checklist and the email migration project plan.

Step 1: tool-level success status#

Start with the report your migration tool produces. If your tool does not produce a per-mailbox success/failure report with item counts, your validation cannot rely on it; you will need to compute deltas yourself with separate IMAP queries on source and destination.

For each mailbox, capture:

• Status: completed, completed with warnings, failed
• Source item count
• Destination item count
• Bytes transferred
• Duration
• Warnings emitted

Sort by warnings descending. The mailboxes with warnings are the ones that need attention first. Common warning types worth surfacing:

• Message too large for destination — destination rejected a message above its per-message limit
• Folder UTF-7 conversion error — folder name contained characters the destination IMAP could not represent
• AUTHENTICATIONFAILED mid-copy — token expired or password changed during the migration
• Too many simultaneous connections — destination throttle kicked in; the tool retried and may have succeeded

Each warning category needs a remediation path before you sign off the mailbox.

Step 2: message-count delta per mailbox#

The single most diagnostic check in validation is the message count delta. For every mailbox, calculate:

delta = (destination_count − source_count) / source_count

Plot the distribution. Expect a tight cluster near zero with a small tail on either side.

What different deltas mean#

• Exactly 0: ideal. Source and destination match item for item.
• Slightly negative (−0.1% to 0): usually fine. The destination filtered out empty system folders or items the IMAP RFC says should not be counted.
• More negative (−1% or worse): investigate. Common cause is a folder the tool could not access at the source.
• Slightly positive: the destination has more items than the source. Almost always means a duplicate copy ran or the user has been receiving new mail during the migration window. Stop incoming mail to the destination until you understand.
• Substantially positive (>2%): re-migration without dedup. See the duplicate emails after migration guide.

Step 3: folder structure compare#

Counts can match while folders are wrong. A user with 1,200 messages in Inbox/Clients/Acme and 1,200 messages in Inbox/Acme (because the tool flattened the hierarchy) has the same total but is going to call the help desk inside the hour.

For each mailbox, compare:

• Number of folders
• Folder hierarchy depth
• Folder names, character by character
• Special folder mapping (Inbox, Sent, Drafts, Junk, Trash, Archive)

Special-folder mapping is where IMAP migrations most often go subtly wrong. Sent mail may end up in Sent Items on the source and [Gmail]/Sent Mail on the destination — same content, different folder name, very confused user. Confirm the mapping is what you intended.

The folder compare is also where you catch the "missing folder" class of bug. See the fix missing folders after migration guide for the recovery process when this fails.

Step 4: sample mailbox manual review#

You cannot manually open every mailbox. You can manually open enough to validate that the automated checks are telling the truth.

Sampling strategy#

Pick a sample that covers your risk surface:

• 5% of regular user mailboxes, random
• 100% of executive and finance mailboxes
• 100% of shared mailboxes
• 100% of meeting room and equipment mailboxes
• The 5 largest mailboxes by size
• The 5 oldest mailboxes by last-login date

For each sampled mailbox, sign in to webmail as that user (using break-glass admin impersonation if your platform supports it; otherwise coordinate with the user) and verify:

• Inbox shows recent mail with correct timestamps
• A folder three levels deep still contains its expected messages
• An attachment opens
• Sent Items shows mail sent by the user, not by the migration tool
• Drafts folder content is intact
• A message from 2018 (or the oldest year you have) opens and displays correctly

Take a screenshot of each sampled mailbox's inbox and the deep folder. The screenshot is your validation artefact.

Step 5: calendar invite round-trip test#

Calendar is the highest-risk single feature in any migration. The validation needs to test four scenarios.

Scenario A: existing recurring meeting#

Pick a real recurring meeting that crosses the cutover date. Verify the destination shows:

• Future occurrences in the right time
• Past occurrences in the past
• The correct attendee list with response status preserved
• The original organiser

If any of those is wrong, you have a calendar fidelity problem that affects every user with a recurring meeting.

Scenario B: new invite from migrated user to migrated user#

User A (post-migration) sends a meeting invite to User B (post-migration). Verify:

• User B receives the invite within 5 minutes
• User B accepts; the response reaches User A within 5 minutes
• User A sees User B's status update to "accepted"

Scenario C: new invite from migrated user to external recipient#

User A sends an invite to an external Gmail/Outlook recipient. Verify:

• External recipient receives the invite
• External recipient accepts
• The acceptance reaches User A

This scenario most often surfaces SPF/DKIM/DMARC misconfiguration. If invites are rejected as spam or fail to deliver, your destination's outbound DNS is not yet aligned.

Scenario D: external recipient sends invite to migrated user#

The reverse direction. Verify the invite arrives, can be accepted, and the response is delivered.

Run all four scenarios with at least three pairs of users. One pair is not enough.

Step 6: rules and out-of-office check#

Server-side rules and OOO replies behave differently between platforms. Some migrate; some do not.

What to check#

• Number of server-side rules per mailbox, source vs destination
• The first three rules per mailbox: are conditions and actions preserved?
• Out-of-office: is the OOO message present and dated correctly?
• OOO: is it set to internal-only when it should be, or both?

Expect rules to need recreation on most cross-platform migrations. Set the expectation in your T+1 user comms so users do not assume rules came across silently when they did not.

Step 7: mobile re-provisioning#

Mobile is the largest source of post-cutover tickets. Get ahead of it.

What to validate centrally#

• Push your MDM profile for the new account to all managed devices before users sign in for the day
• For BYOD, publish a single setup page per device family (iOS native, iOS Outlook, Android native, Android Outlook)
• Confirm the new account autodiscover record resolves correctly from outside your corporate network
• Test the setup flow yourself on at least one personal iOS device and one personal Android device

What each user must do#

• Remove the old account from the device entirely
• Add the new account using the published settings or autodiscover
• Confirm a new mail arrives within 5 minutes
• Confirm calendar appointments appear
• Confirm contacts appear if your platform syncs them

Track mobile re-provisioning as a separate completion metric. A user whose desktop works but whose mobile is still pointing at the old server is not done.

Step 8: shared mailbox access verification#

Shared mailboxes need verification by every delegate, not just by the nominal owner.

Per-shared-mailbox check#

• Owner can open the shared mailbox in webmail
• Each delegate can open it
• Each delegate can send as / send on behalf of the shared address
• Mail received during cutover is present
• Folders within the shared mailbox match the source

Send-As is the failure mode that hurts the most because it works for the owner — who tests — but not for the delegates who use it daily. Every named delegate must run a send-as test before sign-off.

For each shared mailbox, log in your validation sheet:

• Owner sign-off (timestamp)
• Each delegate sign-off (timestamp)
• Send-as test result (sent timestamp, received timestamp)

If your shared mailbox count is in the hundreds, this is the longest single step of validation. Budget for it.

Step 9: mail flow and deliverability#

The final check confirms that mail leaving the destination is being accepted by the rest of the internet at the rate you expect.

What to test#

• Send to a small set of external addresses (Gmail, Outlook.com, Yahoo, a self-managed test domain)
• Check SPF alignment on each delivered message
• Check DKIM signature passes
• Check DMARC reports the next morning for any aggregate failures
• Check spam-folder rate at the major receivers
• Verify return-path matches what you intend

Tools like mail-tester or the major receivers' own postmaster reports give you a fast read on whether you have an alignment problem.

If your DMARC policy was at none for the source domain and you flipped it to quarantine or reject for the destination, expect some legitimate mail to land in spam for 48 hours while reputation builds. This is normal but uncomfortable; warn users.

Validation tracking#

The simplest tracking is a spreadsheet with one row per mailbox and one column per validation step. The columns should be:

• Mailbox address
• Tool status
• Source count
• Destination count
• Delta
• Folder structure match (Y/N)
• Manual review (date, reviewer initials)
• Calendar test (Y/N/N/A)
• Rules/OOO check (Y/N)
• Mobile re-provisioned (date)
• Delegates verified (date)
• Final sign-off (date, reviewer)

Aggregate this sheet daily. Your migration is not complete until every row is green or has a documented exception.

When validation fails#

Different failures need different responses.

Count delta on one mailbox: re-migrate that mailbox with the tool's resume function. If resume is not possible, run a delta-only sync to catch what was missed.

Folder structure wrong on many mailboxes: this is a tool-configuration bug, not a per-mailbox problem. Pause cutover for new waves; fix the mapping; re-run the affected mailboxes.

Calendar wrong: usually a timezone or recurrence-rule conversion issue. If it affects everyone, hold cutover. If it affects one user, work the case manually.

Mobile not working for a class of device: re-test the autodiscover and the published setup steps. If autodiscover is wrong, fix it before notifying more users.

External delivery failing: drop everything. SPF/DKIM/DMARC alignment must be fixed before more mail is sent or you will burn your sending reputation.

The validation report#

When validation closes, produce a 1-page report for stakeholders:

• Mailboxes migrated: count
• Mailboxes signed off: count and percentage
• Exceptions: list with severity
• Outstanding tickets: count by category
• External deliverability: pass/fail summary
• Recommendation: cutover is complete / hold open the validation window for N more days

The recommendation is the only sentence the executive sponsor reads. Make it explicit.

What to do in the seven days after sign-off#

Validation is not over the moment you sign off. The next seven days are when low-frequency issues surface.

• Day 1: open ticket triage twice per day
• Day 2–3: monitor the help desk for category trends; look for "I cannot find a folder" or "Send-as fails for shared mailbox" recurring
• Day 4–7: monitor DMARC aggregate reports for residual alignment failures
• Day 7: send the user satisfaction survey and confirm the migration is closed

If you have followed the operational pattern in the complete email migration guide, the seven-day tail is short. If not, expect the tail to keep generating tickets for two to three weeks.

A short note on tooling#

The validation steps above are tool-agnostic. They work for any IMAP-to-IMAP migration and for most platform-native migrations. The right migration tool — one that produces detailed per-mailbox reports, handles UTF-7 folder names correctly, and provides resume on failure — makes validation faster, but it does not replace the human checks. The manual sample, the calendar round-trip, the delegate send-as test: those are non-negotiable.

If you are evaluating tools, the validation features to look for are: per-mailbox item count export, folder mapping override, throttle-aware retry, and a resume function that does not duplicate. Mailbox Taxi provides each of these when you run it locally against any IMAP endpoint.