The Complete Email Migration Guide for 2026

Email migrations look simple on paper: copy mail from A, paste it into B, done. The reality is messier. Mailboxes drift while you work. Providers throttle hard once they notice a pattern. Folder hierarchies that look identical hide subtle naming rules that wreck calendar invites two weeks after cutover.

This guide is the playbook our team uses to ship migrations that don't leak. It assumes you're the person who'll get paged at 11pm if something breaks, so it skips the marketing and goes straight to what works.

What "email migration" actually means#

When teams say "email migration" they usually mean one of four things:

• Cutover — every mailbox moves in a single window. Best for organisations under 150 mailboxes.
• Staged — mailboxes move in batches over days or weeks. Better for larger orgs, but only Exchange-style sources support this cleanly.
• Hybrid — source and destination coexist for an extended period. Used for mergers and long-running M&A integrations.
• Tenant-to-tenant — both ends are the same product (e.g. Microsoft 365 → Microsoft 365) but different organisational tenants.

The plan you build is dictated by which of these you're running. A cutover plan that assumes a single change-window is dangerous to apply to a staged migration, and vice versa.

The five phases every migration goes through#

Every successful migration we've shipped has touched these five phases in order. Skipping one is the most common cause of post-cutover incidents.

1. Discovery

   Inventory every mailbox, shared mailbox, distribution list, calendar, contact list, and resource (rooms, equipment) on the source. Note total mail volume and the largest mailboxes — they set your timeline.

2. Planning

   Map source objects to destination objects, decide on the migration pattern (cutover, staged, hybrid), and write a fallback plan. The fallback plan is not optional; it is what you read out at 2am.

3. Pilot

   Migrate 5–10 real mailboxes. Use a mix: a power user with big calendars, an exec with shared mailbox access, an account from a department with high volume. Pilot results will reshape the plan.

4. Production move

   Run the bulk move in batches. Monitor throughput and error rate, not just "progress percent" — the percent is meaningless if 12% of items are failing silently.

5. Cutover and validation

   Change MX records, do the final delta sync, and run a sampling validation — open inboxes at random and look for missing folders, broken calendar invites, missing rules.

Pre-migration checklist#

The checklist below is what we send to clients before kickoff. If you cannot answer "yes" to every item, stop and fix it before you move data.

• Confirmed administrator access on both source and destination (and a documented break-glass account on each).
• Verified DNS records (MX, SPF, DKIM, DMARC, autodiscover) and identified which need to change at cutover.
• Inventoried mailboxes with mail volume, mailbox size, and folder count per mailbox.
• Catalogued shared mailboxes and the users who have access to them.
• Listed every distribution list, security group, contact list, and resource calendar.
• Identified MFA settings and any conditional-access policies that may block the migration tool.
• Reserved a maintenance window long enough to absorb the throttling overhead — assume the longest mailbox will run 2× the average.
• Booked a known-good rollback plan and got a sign-off from the business owner.

Picking the right tool#

For more than ten mailboxes, hand-rolling the migration is a false economy. The decision between tools comes down to:

• Local vs cloud — A locally-run tool keeps mailbox data on your machine, which matters for regulated industries and clients with sovereignty constraints. A cloud tool is easier to operate but sends every message through a third-party tenant.
• Batch import — Anyone migrating more than 25 mailboxes wants CSV import. Configuring each mailbox by hand is where mistakes are born.
• Pause and resume — Network blips, expired tokens, and throttling pauses are inevitable. A tool that can't resume from the last successful message will burn hours re-downloading work it already did.
• Reporting — Compliance and audit teams will ask "did you migrate everything?" The answer needs to be a generated PDF or CSV, not a screenshot.

Mailbox Taxi was built around these requirements specifically — local-first, CSV-batch, pause/resume, and PDF/Excel reporting.

Common migration patterns by provider pair#

The mechanics of a migration depend almost entirely on what kind of mailbox sits at each end. The most common combinations we see in 2026:

• IMAP → IMAP — Universally supported, slowest, least metadata-rich. Use when at least one end is a generic provider.
• Exchange → Exchange Online — The native path via Microsoft's hybrid configuration. Best fidelity if you have the time.
• Google Workspace → Microsoft 365 — Common acquisition path. Pay attention to label-vs-folder semantics; Gmail labels don't map cleanly to Outlook folders.
• Microsoft 365 → Microsoft 365 (cross-tenant) — Microsoft now ships a native cross-tenant tool for this; third-party tools fill the gaps.

If you're already deep into a specific pair, the migration guides hub has step-by-step walkthroughs for each.

Post-cutover: validation and cleanup#

The migration is not done when the tool says "complete". It is done when a sample of users have opened their new mailbox and confirmed everything works.

Spot-check these items before declaring success:

• Folder structure — Compare a known-complex mailbox side by side. Pay attention to nested folders.
• Calendar invites — Send a test invite from a migrated mailbox to an external address. Look for the right organiser name and a working reply.
• Out-of-office and rules — Migration tools rarely move these. Plan to redo them manually or via PowerShell scripts.
• Mobile re-provisioning — Users will need to remove and re-add the account on their phones. Pre-write a one-paragraph instruction for them.
• Shared mailbox access — Verify each user who had delegate access on the source has it on the destination.

Where things break (and what to do about it)#

After dozens of migrations the same handful of problems show up repeatedly. The troubleshooting hub has detailed fixes; the headlines are:

• Duplicate emails after a resume usually mean the tool didn't checkpoint properly. A second sync will appear to "fix" the count but may double earlier messages.
• Missing folders are almost always character-encoding or trailing-space issues in folder names. Look at the raw IMAP folder list with imap LIST "" "*".
• Calendar items missing organiser is a known Exchange-Online quirk when the source organiser was an internal account on a now-deleted domain.
• MFA app password not accepted — Some providers (Gmail, Yahoo) require an app password even with OAuth disabled. This is the single most common ticket we get during migrations.

Quick reference: a one-page migration plan#

If you only remember one thing from this guide, remember this minimal one-page plan:

1. Inventory the source — every mailbox, every shared resource, every rule.
2. Pilot ten real mailboxes.
3. Pre-stage mail in batches over multiple nights to dodge throttling.
4. Cutover in a planned window with MX changes and a final delta sync.
5. Validate by opening real mailboxes, not by reading reports.
6. Keep the source alive for thirty days, then decommission.

Follow that and you'll ship migrations that don't leak. For deeper walkthroughs of specific moves, see the Office 365 migration playbook, the Google Workspace migration guide, the Exchange migration guide, or the tenant-to-tenant migration guide — and the troubleshooting hub if you're already mid-incident.