Office 365 Migration: The Definitive Playbook

An Office 365 migration that goes sideways usually doesn't fail at the technical step — it fails at the planning step three weeks earlier. You hit throttling you didn't model, MFA blocks the service account at 3am, autodiscover points at the wrong tenant, and the CFO can't see free/busy for the board. This playbook walks you through every decision point for an office 365 migration: discovery, batching, the cutover-versus-staged-versus-hybrid call, throttling math, modern auth, validation, and the failure modes that actually happen.

Start with discovery, not tooling#

The single biggest predictor of a clean Microsoft 365 migration is whether you wrote down the source state before you touched anything. Tooling decisions come after.

You need an inventory that captures, at minimum:

• Mailbox count, total size, and largest individual mailbox.
• Item count distribution. A 40 GB mailbox with 1.2 million items is a very different problem from a 40 GB mailbox with 80,000 items.
• Shared mailboxes, distribution lists, dynamic distribution groups, resource mailboxes, public folders.
• Calendar delegations and "send on behalf" permissions — these break silently if you don't enumerate them.
• Mobile device count by platform. iOS and Android handle autodiscover changes differently.
• Third-party connectors: archiving, e-discovery, journaling, signature management, encryption gateways.
• Current authentication state per account (basic auth, modern auth, MFA enrolled, app passwords issued).

For an existing on-prem Exchange estate, the Exchange Server migration guide covers the hybrid-specific discovery items in more depth. For a Google Workspace source, do the same exercise from the Workspace side using the Google Workspace migration guide.

Pick the migration method#

There are three sanctioned Microsoft paths into Office 365, and one practical fourth.

Cutover migration#

A cutover migration moves every mailbox in a single batch over a defined window, typically a weekend. Microsoft caps this at 2,000 mailboxes in theory; in practice, the ceiling is closer to 100–150 if you want predictable timing.

Choose cutover when:

• You have one source email system and one source domain.
• Total mailbox count is under roughly 150.
• You can tolerate a single coexistence-free cutover.
• Source authentication can be temporarily relaxed for a service account.

Staged migration#

A staged migration moves mailboxes in batches over days or weeks, with mail flow coexisting between source and destination. It only applies to Exchange 2003/2007 sources in the strict Microsoft definition, but the pattern — batch, validate, repeat — generalises to any source you can read over IMAP or EWS.

Choose staged when:

• You have 150–2,000 mailboxes.
• The business can tolerate some users on the old system while others are on the new one.
• You need to spread risk across multiple weekends.

Hybrid migration#

Hybrid configuration links your on-prem Exchange organisation to Exchange Online so mailboxes can be moved without breaking Outlook profiles, free/busy, or mail flow. It requires Exchange 2010 or newer on-prem and a working Azure AD Connect (or Entra Connect) sync.

Choose hybrid when:

• You have more than 2,000 mailboxes.
• You need long-term coexistence (months, not days).
• You cannot tolerate Outlook profile rebuilds at cutover.
• Calendaring across the split is non-negotiable.

Third-party tool over IMAP or EWS#

The fourth path is using a third-party migration tool that authenticates as each user (or as a single service account with impersonation) and moves data over IMAP, EWS, or Microsoft Graph. This is what most MSPs reach for when the source isn't Exchange — Google Workspace, Zoho, IMAP-only hosts, or another tenant. The tenant-to-tenant migration guide covers the M365-to-M365 case in detail.

If you want a framework for picking between these four, the cutover vs staged vs hybrid breakdown lays out the cost, risk, and timeline trade-offs.

Batch sizing and throughput math#

Throughput is the most-misunderstood part of an Office 365 migration. The marketing number — "up to 10 GB per hour per tenant" — is not what you'll see in production.

The realistic numbers, once Microsoft's throttling engages:

• EWS soft limit: approximately 2,000 items per hour per mailbox.
• Per-tenant connection ceiling: typically 20–40 concurrent connections before throttling.
• Per-mailbox throughput: 0.5–1.5 GB per hour for most mailboxes; closer to 0.3 GB per hour for mailboxes with millions of small items.
• Daily ingestion ceiling: approximately 60–150 GB per tenant per 24 hours, depending on source.

The throttling math you actually care about: take your total source size in GB, divide by 1.0 GB/hour (a safe planning rate), and that's your single-stream baseline. With 10 concurrent mailboxes in a batch, you can roughly multiply throughput by 5–7 (not 10 — throttling eats some of it). With 20 concurrent, you'll see 8–12x. Past that, you're feeding the throttler.

Batch sizing recommendations:

• Pilot batch: 5–10 mailboxes, mixed sizes, including one power user and one shared mailbox.
• Standard batches: 25–50 mailboxes for staged or hybrid moves.
• Power-user batches: mailboxes over 25 GB get their own batch, scheduled overnight.

If you hit the throttle wall mid-migration, the Office 365 throttling fix guide walks through the recovery pattern: pause, reduce concurrency, switch endpoints if available, and resume from the last completed item.

MRSProxy, EWS, and the transport question#

For on-prem Exchange sources, the Mailbox Replication Service Proxy (MRSProxy) is the bridge that lets Exchange Online pull mailbox data over HTTPS. It runs on your client access role and is published through your reverse proxy or load balancer.

The MRSProxy story is conceptual at this level — the actual configuration is per-version — but the requirements are stable:

• A publicly resolvable autodiscover endpoint.
• HTTPS on port 443 with a publicly trusted certificate.
• An EWS virtual directory reachable from Exchange Online's IP ranges.
• Modern authentication or basic auth (Microsoft still tolerates basic auth on the MRSProxy endpoint for migration, but check the current state when you plan).

For pure IMAP sources — Gmail, Zoho, hosted IMAP — you skip MRSProxy entirely. Migration runs from the destination tenant or from a third-party tool over IMAPS to the source. Throughput is lower (~0.3–0.8 GB per hour per mailbox) and you lose calendars, contacts, and tasks unless the source exposes them separately.

For Microsoft Graph-based migrations (newer tools, M365-to-M365), Graph throttling behaves differently from EWS throttling — fewer items per second but more forgiving on burst traffic.

MFA, modern auth, and the service account question#

This is where most office 365 migrations stall in 2026.

Modern authentication has been the default for new tenants for years, and basic auth for EWS, IMAP, POP, and most other protocols is either disabled or about to be. You cannot rely on "just disable MFA for the migration account" the way you could in 2018.

Your options, in rough order of preference:

1. App registration with application permissions. Register an Entra app, grant it the Mail.Read or full_access_as_app scope (depending on tool), and authenticate with a client secret or certificate. This is the cleanest path for Graph-based and EWS-impersonation-based migrations.
2. App registration with delegated permissions and a service account. Useful when the tool needs to act as a specific user with their consent.
3. App passwords on individual user accounts. A fallback for tools that don't support OAuth on a given protocol. Works on accounts where the admin has explicitly enabled app passwords. Not available in all tenant configurations.
4. Temporary MFA exemption for a migration service account. Possible via a Conditional Access exclusion, but you must document the exposure window and revert immediately after cutover.

DNS, autodiscover, and the cutover window#

The actual cutover is mostly DNS, mostly autodiscover, and mostly waiting for caches to expire.

Your cutover-day DNS list:

• MX record. Switch to the new tenant's MX after the final delta sync completes.
• Autodiscover. Point autodiscover.yourdomain.com to autodiscover.outlook.com once all mailboxes are moved. If you're hybrid, this changes only at the very end.
• SPF. Add include:spf.protection.outlook.com and remove the source provider's include when no relay path remains.
• DKIM. Publish the two Microsoft DKIM CNAMEs and enable signing in Defender for Office 365.
• DMARC. If you already had a policy, keep it. If not, start at p=none for two weeks, then move to quarantine, then reject.

TTL strategy: drop your MX and autodiscover TTLs to 300 seconds 48 hours before cutover. You'll thank yourself when you need to roll back.

Pre-cutover, cutover, and post-cutover#

Here's the sequence that consistently works.

T-minus two weeks#

• Final discovery sign-off.
• Pilot batch complete and validated.
• Communication sent to end users with screenshots of the new Outlook profile flow.
• Drop DNS TTLs.

T-minus one week#

• All bulk batches complete except the final delta.
• Mobile device communication: re-enrol instructions for iOS, Android, and any MDM.
• Shared mailbox permissions exported from source and re-applied to destination.

Cutover weekend#

• Friday evening: final delta sync starts. Source mail flow continues.
• Saturday morning: delta sync completes. Validate item counts on a 10% sample.
• Saturday midday: MX and autodiscover switch.
• Saturday afternoon: re-test mail flow inbound and outbound. Send a known test message from gmail.com, yahoo.com, and a personal domain.
• Sunday: monitor queues. Re-run delta against any straggler mailboxes that received mail after the original delta.

Post-cutover validation#

Run this checklist for every batch, not just the final one:

• Item count delta per folder is within 1%.
• Total size delta per mailbox is within 2% (some headers compress differently).
• Send a test from each migrated mailbox to an external address.
• Receive a test to each migrated mailbox from an external address.
• Free/busy resolves across the org.
• Shared mailbox auto-mapping works in Outlook desktop.
• Mobile devices either reconnect via autodiscover or are wiped and re-enrolled.

The email migration checklist has the full validation matrix in printable form.

Common Office 365 migration errors#

These are the errors you'll actually see in logs, and what they mean:

• MigrationPermanentException: The connection to the server was terminated. — usually a throttling event or a TLS handshake failure on the source. Reduce concurrency.
• Too many simultaneous connections — IMAP source is enforcing its own connection cap. Drop concurrent connections per mailbox.
• OAuth2 token expired — your migration tool's refresh token cycle is misaligned with Microsoft's token lifetime. Restart the batch.
• AUTHENTICATIONFAILED — modern auth not enabled on the account, or app password not generated, or Conditional Access blocking the location.
• Folder UTF-7 conversion error — IMAP folder names with non-ASCII characters. Pre-rename problem folders or let the tool handle UTF-7 IMAP encoding.
• Message too large for destination — destination tenant message size cap (typically 150 MB) is smaller than source. Split or archive.
• MapiExceptionShutoffQuotaExceeded — the mailbox hit a soft quota. Increase the destination mailbox cap before resuming.

If a migration appears stuck for more than 6 hours with no progress, it almost always is — not just slow. Pause, inspect the most recent error, and restart from the last completed item.

Cost modelling#

Office 365 migration cost has three layers most plans underweight:

1. Licensing. Microsoft licensing for the destination tenant during the migration window, plus any source-side licensing you can't cancel until cutover.
2. Tooling. Per-mailbox cost for the migration tool, typically $5–$25 per mailbox depending on vendor and features. Some tools include unlimited reruns; some charge per attempt.
3. Labour. The biggest line item. A 500-mailbox migration is typically 80–160 person-hours including discovery, pilot, batches, cutover, and the 72-hour post-cutover support window.

The Office 365 migration cost breakdown walks through realistic numbers for tenant sizes from 25 to 5,000 mailboxes, and the best Office 365 migration tools comparison covers the tooling layer.

When migration is moving from another mail system#

Two source scenarios deserve their own pillars:

• Moving from Exchange or another Microsoft 365 tenant: see migrate Exchange to Office 365 for the on-prem case and the tenant-to-tenant migration guide for cross-tenant.
• Moving from Gmail or Google Workspace: see migrate Gmail to Office 365 for personal Gmail and migrate Google Workspace to Office 365 for business sources.

Each of those has provider-specific quirks — label-to-folder semantics from Gmail, public folder handling from on-prem Exchange — that don't fit cleanly in a generic playbook.

What good looks like at the 72-hour mark#

You'll know the migration succeeded when, 72 hours after MX switch:

• Inbound mail flow is fully on the new tenant. The source MX still resolves but receives nothing.
• Mobile devices are reconnected without help-desk intervention.
• Shared mailbox auto-mapping is consistent across all delegated users.
• Free/busy resolves both within the org and to federated partners.
• Calendar invites sent before the migration still resolve correctly to the new mailbox.
• No more than 2% of users have reported any user-visible issue.

Anything worse than this and you have a follow-up batch to plan — usually a handful of mailboxes that didn't complete their delta cleanly. Re-run, validate, close out.