The Exchange Online migration guide to get it right the first time (+downloadable checklist)

TL;DR: Audit, prep, execute, verify, decommission. Six phases, one checklist, no surprises on cutover day.

This guide covers the journey: picking the right migration type, auditing your environment, preparing your destination, executing the move, and closing out cleanly. It's grounded in how Microsoft's migration framework works and where a tool like ShareGate Migrate fills the gaps that Microsoft native methods leave open.

We've distilled every phase into a downloadable checklist you can print out and work through with your team on migration day. It's your task-by-task companion to this guide.

‍

Download the Exchange Online migration checklist →

‍

Jump to the section you need or work through it from start to finish.

1. First, pick the migration type

Not all Exchange migrations are the same. Here's how the four main scenarios break down.

Cutover migration

In this scenario, everything moves at once, such as mailboxes, resource accounts, and contacts.  

Using Microsoft's native tools, cutover migration works with Exchange Server 2003 or later on-premises. Microsoft technically supports up to 2,000 mailboxes this way, but their own recommendation is to stay under 150 users. Once you push past that, the time it takes to create and migrate everyone in a single batch becomes unreasonable.

On cutover day, the goal is to get all remaining mail migrated before you flip the MX record, so nothing sent during that window disappears.

Best for: Small companies doing a full move from on-premises Exchange to Exchange Online in one shot.

Staged migration

Staged migration is built for moving mailboxes in waves over time, which makes it a good fit if you need to keep disruption low across a large organization. Using Microsoft's native tools, this works if you're on Exchange Server 2003 or 2007. If you're on 2010 or 2013, staged migration isn't an option and you'll need a hybrid approach instead.

One thing to sort out before you kick off is that mail keeps flowing between on-premises and Exchange Online throughout the migration, so your MX record strategy and directory sync need to be planned in advance.

Use case: Medium-sized organizations (typically 2,000+ mailboxes) on older Exchange versions who want to move in batches.

Tenant-to-tenant migration

When your organization goes through a merger, acquisition, divestiture, or restructure, mailboxes need to move from one Microsoft 365 tenant to another. This is the most complex scenario on the list because you're dealing with overlapping domains, shared contacts, cross-tenant calendar visibility, and permissions that don't automatically survive the move. It can be complicated.

Microsoft does provide native cross-tenant migration capability through PowerShell. Before you can run it, you'll need to register an app in Microsoft Entra ID, set up a trust relationship between tenants, pre-create MailUser objects in the destination, and assign a Cross Tenant User Data Migration license to each mailbox being moved. ShareGate Migrate handles the batching, mailbox mapping, and post-migration verification so you're not managing it all manually.

Use case: Mid-size to large organizations going through mergers, acquisitions, divestitures, or restructuring.

Google Workspace to Exchange Online

Moving from Google Workspace to Exchange Online involves more steps than a straight Exchange-to-Exchange migration. Microsoft's native path is IMAP migration. IMAP is an email protocol that connects to your source mailboxes and copies messages across. It moves email only. Calendars, contacts, and tasks don't come with it. Mailboxes also aren't created for you automatically: you need to set them up in Exchange Online first, migrate the mail in, and then handle calendars and contacts separately.

ShareGate Migrate handles Google Workspace to Microsoft 365 migration in one workflow—emails, calendars, contacts, and mailbox rules—with source-to-destination mapping and post-migration reports so you can verify exactly what moved.

Use case: Organizations of any size moving from Google's environment to Microsoft 365.

Migration type comparison

*The source system restrictions in the table above apply to Microsoft's native migration tools. ShareGate Migrate supports additional source systems and scenarios beyond what native tools cover.

‍

2. Then, audit your current environment

Before setting a migration date, you need a clear picture of what's in your environment. Mailbox migration involves more than email. It touches shared mailboxes, calendars, contacts, permissions, compliance policies, and more. An audit upfront means fewer surprises mid-migration.

Mailbox inventory

• List every mailbox type: user mailboxes, shared mailboxes, room and equipment mailboxes, resource calendars, distribution groups, and mail-enabled security groups.
• Flag inactive mailboxes. These are soft-deleted mailboxes preserved under a compliance hold, and for cross-tenant migrations specifically, mailboxes on any type of hold are blocked from migration.
• Identify archive mailboxes; they need separate handling and the right licensing in the destination.
• Note any public folders that need to move. Public folder migration is its own separate process, not part of the mailbox migration.
• Find users with in-place archive mailboxes and note their sizes. If you're using ShareGate Migrate, it detects archive mailboxes during planning and flags size issues before execution.
• Check mailbox sizes, and flag anything over 100 GB. Those will take longer to migrate.

Permissions and delegation

• Document who has Send As, Send on Behalf, or Full Access permissions on shared and user mailboxes.
• Pay attention to auto-mapping: Full Access permissions automatically add the mailbox to a user's Outlook profile via Autodiscover. If that stops working after migration, users will notice immediately.

Compliance and security

• Check Microsoft Purview for active retention policies, labels, or holds on any mailboxes being migrated.
• Review DLP policies to confirm they'll apply correctly in Exchange Online.
• Confirm your migration tooling supports Modern Authentication (OAuth 2.0).

Technical readiness

• Plan your DNS strategy now, not on migration day: MX records, SPF, DKIM, and DMARC all need a cutover plan worked out in advance.
• Check network bandwidth. Microsoft throttling can slow large batches, and it's better to know your constraints ahead of time.
• Make sure Exchange Online licenses are assigned to all migrating users before migration begins.
• For cutover, staged, and Google Workspace migrations, Microsoft's native tools are available directly in the Exchange admin center Migration dashboard. For cross-tenant migrations, Exchange Online PowerShell is the native path, using the New-MigrationBatch cmdlet.
• For tenant-to-tenant and Google Workspace migrations, ShareGate Migrate’s Exchange Online migration covers the full migration workflow in one place, from planning and mailbox mapping to execution and post-migration reporting.

DNS and tooling

• Check your Domain Name System (DNS) records: MX, SPF, DKIM, DMARC, and Autodiscover all need to be accounted for before migration starts. Autodiscover is what Outlook uses to automatically configure a user's mail profile and connect to Exchange Online after migration.
• For cutover, staged, and Google Workspace migrations, Microsoft's native tools are available directly in the Exchange admin center Migration dashboard. For cross-tenant migrations, Exchange Online PowerShell is the native path, using the New-MigrationBatch cmdlet.
• For tenant-to-tenant and Google Workspace migrations, ShareGate Migrate covers the full migration workflow in one place, from planning and mailbox mapping to execution and post-migration reporting.

‍

3. Prepare the destination

The order of operations matters here. For tenant-to-tenant migrations, Entra ID users need to exist in the destination before mailbox mapping can work. Remember, mailboxes can't move to users that don't exist yet.

Provision user accounts

• Make sure destination user accounts exist before migration starts. Without them, mailboxes have nowhere to land.
• For Google Workspace migrations, create Exchange Online mailboxes for each user before you run IMAP migration.
• Exchange Online licenses are assigned after migration completes. Microsoft gives you a 30-day window before mailboxes are disabled, so plan accordingly.

Configure authentication

• Confirm Modern Authentication is enabled in Exchange Online. It's on by default in new tenants, but worth verifying it hasn't been disabled. Any migration tool relying on Basic Auth will fail.

Configure DNS and mail flow

• Add Exchange Online's sending infrastructure to your SPF record (include:spf.protection.outlook.com).
• Set up DKIM signing for your domain in Exchange Online.

Run a test migration

Run a small pilot first  before going straight in production. Start with a handful of IT staff or volunteers. If something's off with mail, calendars, delegate access, or Outlook connectivity, this is the time you’ll want to find out.

‍

4. All systems go: Migrate

With your destination prepared and pilot validated, you're ready to move production mailboxes. Run batches in the Exchange admin center or through ShareGate Migrate, and monitor throughout.

During the migration

Monitor progress in the Exchange admin center or your migration tool's dashboard throughout. Keep an eye out for failed items including missing permissions, oversized messages, or corrupt mailbox data.  

Throttling is a normal part of any Microsoft 365 migration. Microsoft limits request volume to keep the service stable for all users. If migration is running slower than expected and includes archive or group mailboxes, you can submit a service request to Microsoft to temporarily lift your Exchange Web Services (EWS) throttling limits. Microsoft grants increases for 30, 60, or 90-day windows.

To submit a service request to Microsoft to temporarily lift your EWS throttling limits:

Go to admin.microsoft.com and sign in with a global admin account.

1. In the left navigation, select Support.

2. Select New service request.

3. In the search bar, type throttling.

4. Select Increase EWS Throttling Policy from the results.

5. Complete the request form.

6. Submit the request

‍

For moves using the Mailbox Replication Service (MRS)—such as cross-tenant migrations—the item size limit is 150 MB per item. For cutover, staged, and IMAP migrations, the limit is the general message size limit of 35 MB and can’t be changed for those migration methods. Refer to Microsoft’s official documentation to learn more about Exchange Online limits.

‍

5. Validate after migration

Don't decommission the source environment until you've worked through everything here.

Validate mailbox data

• Check item counts between source and destination.  
• Verify that calendar events made it across with the correct organizer, attendees, and recurrence patterns.  
• Confirm delegate access is working: can delegates open shared mailboxes and send on behalf of the right accounts?  
• Make sure contacts carried over correctly.  

Calendar sweep (tenant-to-tenant)

• After cutover, recurring meetings still point to the old tenant's Teams join URLs. Organizers need to reissue invites from the new tenant.
• Focus on recurring meetings with external attendees and future one-off meetings dated after the cutover, these are the ones users will actually try to join.

Validate mail flow

• Send test messages from external accounts and confirm delivery in Exchange Online.  
• Check that out-of-office replies work.
• Make sure inbox rules and filters migrated and are running correctly.
• Confirm shared mailboxes are receiving mail as expected.

Licenses and compliance

• Confirm all migrated users have active Exchange Online licenses  
• Check that retention policies and compliance holds are applying correctly to their mailboxes.  
• For users who had archiving enabled, check archive mailbox status in the destination.  

User support

• According to Denis Molodtsov, Microsoft MVP, in our on-demand webinar about sequencing tenant-to-tenant migration, IT teams should plan for 50–100% extra help desk capacity for at least the first week. The most common ticket categories are password resets, MFA enrollment issues, device sign-in problems, and users who can't find their data.
• Users will need to set up a new Outlook profile to connect to their migrated mailbox, and desktop computers may need to be updated to work with Microsoft 365.
• Prepare FAQs and short screen recordings before cutover so users have somewhere to go, and be upfront that week one will have some friction.

‍

6. Decommission

After all mailboxes are verified and users are working from Exchange Online:

• Run a final check for anything missed—Power Platform flows, Planner, Loop, Bookings, and other services that aren't part of the mailbox migration but live in the source tenant.
• Revoke permissions and disable source accounts.
• Update DNS to remove any remaining references to the old mail infrastructure.
• Document what moved, when, and what didn't.

The single biggest post-cutover mistake is canceling the source subscription too soon. Keep the source tenant alive for at least 30 days and longer for complex migrations. You can keep it minimally licensed (just enough to prevent tenant deletion) while you verify nothing was missed. Microsoft automatically deletes tenants approximately 90–180 days after all paid subscriptions are canceled.

‍

Don't let these catch you off guard

Delegate permissions

One of the most common mistakes in mailbox migrations: delegate permissions —Full Access, Send As, and Send on Behalf—live on the mailbox object itself, not in the mail content. They don't migrate with the mailbox. If you move mailbox content without explicitly re-granting delegate permissions in the destination, users who rely on those permissions will lose access and won't understand why. Document all delegate relationships during your audit and have a plan to re-grant them after migration.

Group mailboxes and Teams

Group mailboxes should be migrated after Teams content, not before. Teams groups can have an associated shared mailbox with active, business-critical content. Migrating the group mailbox first risks losing content that's still being used.

PST files

PST files need to be handled separately. They're not part of the standard mailbox migration flow and can't be easily automated. Users with locally attached PSTs need a separate plan. Depending on the size and number of PSTs involved, options include importing them to Exchange Online before migration, moving them to OneDrive, or handling them manually after cutover. Each case is different.

Shared mailboxes

Shared mailboxes need to exist in the destination before migration starts. In tenant-to-tenant scenarios, they need to be pre-created as MailUser objects. For cutover and staged migrations, explicitly applied permissions like Full Access and Send As are migrated to Exchange Online but inherited permissions and permissions on non-mailbox objects like distribution lists are not, and those need to be reconfigured. For cross-tenant migrations, permissions don't carry over automatically and need to be re-granted explicitly after migration.

Public folders

Public folder migration is a separate workload from mailbox migration. It has its own process and its own documentation. Microsoft has guidance for migrating legacy public folders to Microsoft 365 Groups or modern public folders in Exchange Online.

Large mailboxes and throttling

For moves using the Mailbox Replication Service (MRS), such as cross-tenant migrations—the item size limit is 150 MB per item. For cutover, staged, and IMAP migrations, the limit is the general message size limit of 35 MB, which can't be changed for those migration methods. Items above the applicable limit will be skipped.

‍

Simplify your Exchange Online migration with ShareGate

Mailbox migration is one of the more complex parts of moving to Microsoft 365, but it doesn’t have to be. With the right tooling, you can make it way more predictable and manageable.

ShareGate Migrate supports tenant-to-tenant Exchange Online migrations and Google Workspace to Exchange Online.  

It handles:  

• Emails, calendars, contacts, server-side rules, and automatic replies
• Primary mailboxes with in-place and auto-expanding archive mailboxes
• Microsoft 365 Group mailboxes
• Litigation Hold settings and enforcement continuity
• Recurring meetings that follow Exchange Online rules, with new Teams meeting links created automatically
• Automated mailbox mapping between source and destination tenants
• Delta migrations to sync changes between migration runs
• Pre-migration visibility into archive size, calendar conflicts, and mailbox issues before anything moves
• Post-migration reports to verify exactly what moved and catch anything that didn't

Mailbox migration doesn’t have to feel risky. With ShareGate Migrate, you can plan ahead, move what matters, and double-check results before you call it done. Request a demo today.