Cutover Migration to Microsoft 365 Explained

Cutover migration is the simplest way to move a small organization from on-premises Exchange to Exchange Online. You migrate every mailbox in one pass, switch mail flow over, and retire the old server. There’s no long-term coexistence to manage and no directory sync to keep running — which is exactly why it suits small businesses and why it falls apart if you try to stretch it past its limits.

This guide explains where cutover migration fits, the order you actually run the steps in, and the mistakes that cause most of the support calls. The single biggest one is changing the MX record at the wrong time, so if you read nothing else, read the section on step order.

What a cutover migration actually is#

In a cutover, you move the contents of all on-premises mailboxes to Microsoft 365 in a single migration batch. Microsoft 365 connects to your on-premises Exchange server over the internet using Outlook Anywhere, reads the mailboxes it discovers, and copies them up. It also creates the mail-enabled users in your tenant automatically from what it finds on the source server, so you don’t pre-create every account by hand.

While the copy runs, your old server keeps receiving mail as normal. The migration service runs an incremental sync roughly every 24 hours to catch anything new. When you’re satisfied the data is up, you flip mail flow to Microsoft 365 by changing DNS, finish the batch, and decommission the source.

When cutover migration is the right choice#

Cutover fits a fairly narrow set of conditions. Get the fit right and it’s smooth; force it onto the wrong environment and you’ll wish you’d chosen hybrid.

The official ceiling is 2,000 mailboxes, but that number is misleading. A single batch of that size is slow, throttled, and painful to monitor. For anything past a few hundred mailboxes, a staged or hybrid migration gives you more control and a smoother user experience. Treat 2,000 as the hard limit, not the target.

Cutover is a poor fit if you need both systems running side by side, if you’re on Exchange 2016 or later, or if you want to keep an on-premises footprint for management. In those cases, look at hybrid instead.

Prerequisites and prep#

Most failed cutovers fail in prep, not in the migration itself. Work through these before you create a batch.

The domain verification step matters more than people expect. You can’t assign your real email domain to users or finish mail flow until the domain is verified in the tenant. Do it early — the TXT record can take time to propagate and it blocks later steps if it’s not done.

The step order that keeps mail flowing#

Here’s the part that causes the most damage when it’s done out of sequence. Run the steps in this order:

1. Verify your domain in Microsoft 365. Add it, complete the TXT record check.
2. Create the migration endpoint. This is the connection to your on-premises Exchange via Outlook Anywhere. Test it and confirm it connects before continuing.
3. Create and start the migration batch. Microsoft 365 discovers the mailboxes, creates the users, and begins copying content. Mail still flows to the old server during this phase.
4. Let it sync and verify. Watch the batch to completion, then let the incremental syncs run. Spot-check a few migrated mailboxes in Exchange Online to confirm content arrived.
5. Assign licenses to every migrated user. A mailbox in Exchange Online needs a license to stay functional past the grace period — don’t skip this.
6. Change the MX record and autodiscover to point at Microsoft 365. This is the actual cutover of mail flow. New mail now lands in Exchange Online.
7. Let DNS propagate, then complete the batch once you’re confident all mail is flowing to the cloud and incremental syncs have caught the last on-prem deliveries.
8. Reconfigure clients and decommission the old server after a safe overlap.

Changing MX and autodiscover correctly#

When you reach the DNS step, two records matter most: the MX record (where mail is delivered) and the autodiscover record (how Outlook finds the mailbox). Both should point at Microsoft 365 after the cutover.

Lowering the TTL ahead of time is what makes the switch fast. If your MX TTL is set to a day, the world keeps delivering to your old server for up to a day after you change it. Drop the TTL to an hour or less a couple of days before the cutover, make the change, and propagation is measured in hours instead.

Don’t forget SPF. Once mail leaves through Microsoft 365, your SPF record must include spf.protection.outlook.com or your outbound mail risks being marked as spam. Update SPF as part of the DNS cutover, not as an afterthought.

Licensing and the grace period#

A migrated mailbox lands in Exchange Online, but it needs a license to keep working long term. There’s a grace period after the mailbox is created, but relying on it is risky — assign the license as part of the migration, not “later.”

You can assign licenses in the admin center or with PowerShell when you’ve got a list of users to process at once:

# Microsoft Graph PowerShell
Connect-MgGraph -Scopes "User.ReadWrite.All", "Organization.Read.All"

# Set usage location (required before assigning a license)
Update-MgUser -UserId "[email protected]" -UsageLocation "US"

# Assign a license (replace the SkuId with your tenant's)
Set-MgUserLicense -UserId "[email protected]" `
  -AddLicenses @{SkuId = "your-sku-guid-here"} -RemoveLicenses @()

Common pitfalls that derail cutovers#

Beyond the MX-timing mistake, these are the issues that come up most often. Knowing them ahead of time saves a lot of mid-migration stress.

• Outlook Anywhere not reachable or bad certificate. The endpoint can’t connect, so the batch never starts. Test external Outlook Anywhere connectivity first.
• Throttling on large batches. Cutover throttles concurrent mailbox moves. A batch of several hundred mailboxes is slow by design. If speed matters, that’s a sign cutover is the wrong method for your size.
• Outlook profiles after the switch. User profiles still point at the old server. Most users need a fresh profile that connects to Exchange Online via autodiscover, and they’ll re-enter credentials. This is the most visible end-user impact — communicate it ahead of time.
• Forgetting SPF. Outbound mail flows through Microsoft 365 after cutover; if SPF isn’t updated, messages can be flagged as spam.
• Shutting down the old server too soon. Late-delivered mail and the final incremental syncs need the source server alive through the overlap.
• Public folders and shared mailboxes. Cutover handles user mailboxes; public folders and some shared resources may need separate handling. Confirm what’s in scope.

After the cutover#

Once mail is flowing to Microsoft 365 and the batch is complete, there’s a short list of cleanup work:

1. Reconfigure Outlook for each user (new profile against Exchange Online).
2. Confirm mobile devices reconnect using the new autodiscover endpoint.
3. Verify mail flow end to end — send and receive from outside, check the message trace.
4. Keep the old server running through the overlap, then decommission it cleanly.
5. Delete the migration batch once everything is confirmed, so it stops trying to sync a server you’re retiring.

If anything looks off with delivery after the switch — messages not arriving, or bouncing — work through Microsoft 365 email not sending or receiving, which covers message trace, MX, SPF, and connector checks. And once everyone’s on Exchange Online, setting up team addresses with shared mailboxes in Microsoft 365 is a good next step for support and info inboxes.

Wrapping up#

Cutover migration earns its place for small Exchange environments because it’s simple: one batch, one DNS switch, no long coexistence. The catch is that the simplicity only holds at small scale and only if you run the steps in order. Verify the domain, build and test the migration endpoint, copy and verify mailbox content, assign licenses, and only then change MX and autodiscover. Keep the TTL low, keep the old server alive through the overlap, and warn users about the Outlook profile rebuild.

If you’re past a few hundred mailboxes, on Exchange 2016 or newer, or you need both systems running together, that’s your signal to choose hybrid instead. Picking the right method up front is what separates a quiet weekend cutover from a Monday full of tickets.