Exchange Cutover Migration to Microsoft 365: When It Fits and How It Works

Exchange Cutover Migration to Microsoft 365: When It Fits and How It Works

Originally published 27 September 2020 · Reviewed 5 November 2026

A cutover migration moves an entire small Exchange organisation to Microsoft 365 in one pass. It is the simplest of Microsoft's mailbox migration methods, and it is still the right answer for some small businesses. This article explains what it does, the limits, the steps and the points that catch people out. Microsoft's pages carry the authoritative details, and Exchange versions have moved on since the original method was written, so check support status first.

What a cutover migration is

In a cutover migration, mailbox data, and optionally contacts and groups, is copied from your on-premises Exchange to Exchange Online in a migration batch. Users, mail-enabled groups and contacts from the source are created in the cloud, you assign licences, and you point your MX record to Microsoft 365 so new mail goes directly to the cloud. Then you retire the source.

It differs from other methods because everything moves together and there is no long coexistence period. Directory synchronisation is not needed and the cloud users are managed in the cloud after the move.

Limits and fit

Microsoft's documentation states these conditions:

• The source is Exchange Server 2003 or later.
• Fewer than 2,000 mailboxes are migrated, and Microsoft recommends considering cutover for about 150 or fewer.
• The primary domain used on premises is an accepted domain in your Microsoft 365 organisation.

Because many Exchange versions are now out of support, treat the version question as a planning risk. If your server runs a version that Microsoft no longer supports, plan the migration as part of retiring it, and check the current migration documentation for supported source versions.

Choose cutover when the organisation is small, wants the project finished in days or weeks, and has no need to keep any mailbox on premises. Choose another method when you need staged moves, long coexistence, directory-synced identities or more than the mailbox limits.

The steps

1. Communicate. Tell users what will change: Outlook profiles may need to be recreated and sign-in uses a cloud identity. Agree the date.
2. Verify your domain in Microsoft 365 with the DNS record the admin centre gives you.
3. Prepare the source. Make sure Outlook Anywhere (RPC over HTTP) is working, that a valid certificate is in place, and that the migration account has the permissions Microsoft documents. Clean up old mailboxes, stale accounts and very large items first.
4. Create the empty mail-enabled security groups needed in Microsoft 365 if your process requires them.
5. Create a migration endpoint, which connects Microsoft 365 to the on-premises server using Outlook Anywhere.
6. Create and start the cutover migration batch. Mailboxes sync, and a periodic incremental sync keeps them current until you finalise.
7. Assign licences to migrated users. Unlicensed migrated mailboxes will stop working after a grace period.
8. Change DNS. Update the MX record to Microsoft 365, add the Autodiscover record, and add the SPF record. Mail now flows to the cloud.
9. Verify routing and delete the batch once mail flows correctly and the final sync finishes.
10. Configure clients. Outlook usually finds the new mailbox through Autodiscover, but some profiles need recreating. Reconfigure mobile devices.
11. Decommission the source after a retention period you agree, keeping a backup.

Impact on users

Expect at least one prompt for credentials and a possible new Outlook profile. Mail sent to the old server before DNS propagates may arrive late. The mailbox size, number of items and bandwidth affect how long the initial copy takes, which is why large mailboxes should be pruned before you start. Shared resources such as public folders and archives need separate planning.

Things that catch people out

• Autodiscover and certificates. If Autodiscover points at the wrong place, clients will not find the new mailbox.
• Licences. Forgetting to assign them is the most common reason mail stops after the grace period.
• DNS time to live. Lower TTLs on MX and Autodiscover records a few days before the move to speed the switch.
• Mobile devices and scanners. They keep trying the old server. List them beforehand.
• Third-party filtering or archiving in front of Exchange needs updating to the new route.
• Non-email data. Files on shared drives, public folders and in-house applications that relay mail do not move with the mailboxes.

After the move

Run the post-migration checks: send tests in both directions, check message trace, confirm that each user can sign in, review the mail security settings for SPF, DKIM and DMARC, and secure the new tenant with MFA before you announce completion. Document the final mail flow and keep the migration logs for a few weeks.

A realistic timeline

For a small office, plan about a week of preparation, a weekend for the initial copy and final sync, and a few days of support afterwards. Do the planning, communication and cleanup in the week before. Start the copy early on a Friday so that most data is already in the cloud before you change DNS. Switch the MX record when the final sync is close, because the mail that arrives between the last sync and the DNS change must still be delivered. Keep the old server running read-only for a few weeks in case someone needs to compare or recover an item.

Microsoft references

• Cutover Exchange migration to Microsoft 365, reviewed 5 November 2026.
• Mailbox migration in Exchange Online, reviewed 5 November 2026.

This article was first published on 27 September 2020. It was rewritten on 5 November 2026 in new words with current product names. Microsoft's live documentation takes precedence if it has changed.