Migrating From On-Premise Exchange to Microsoft 365: What to Expect

Moving from an on-premise Exchange server to Microsoft 365 is one of the most common migrations a small business will undertake, and one of the most visible — email failing is noticed instantly by everyone.

The mailbox data itself is rarely the difficult part. The complications are in identity, in the objects around mailboxes, and in the cutover.

The migration paths

Cutover migration

All mailboxes move in a single operation. Suitable for smaller organisations — Microsoft's supported limit is well above what most small businesses have, but practical experience puts the comfortable ceiling considerably lower, particularly with large mailboxes.

Simple, and it means a defined switchover moment rather than a period of coexistence. The tradeoff is that everyone changes at once, which concentrates risk and support load into a single weekend.

Staged migration

Mailboxes move in batches over time. Applies to older Exchange versions and is less commonly the right answer now, but it allows a phased approach where cutover would be too disruptive.

Hybrid migration

On-premise Exchange and Microsoft 365 run together, with mailboxes moving gradually and full coexistence — free/busy calendar lookups, unified address list, mail flow between both. The right answer for larger or more complex environments, and for anyone who needs to move slowly.

It is also considerably more complex to configure, and worth being honest about: for a business with fifty mailboxes and no unusual requirements, hybrid is usually more machinery than the problem needs.

Third-party migration tools

Commercial tools handle the copy independently of Microsoft's native paths, generally with better reporting, better handling of large or problematic mailboxes, and the ability to run repeated incremental passes. For anything beyond a simple cutover, these frequently pay for themselves in reduced risk.

Decide identity first

The single most consequential decision, and the one that should be settled before any mailbox moves.

• Cloud-only identity — accounts live in Entra ID with no on-premise directory. Simplest, and the right answer if you are also retiring your domain controllers.
• Directory synchronisation — accounts remain mastered on-premise and synchronise to the cloud. Appropriate where on-premise Active Directory is staying for other reasons.

Two things worth doing regardless: clean the directory before synchronising anything, because stale accounts, duplicates and inconsistent attributes propagate permanently; and plan MFA rollout as part of the migration rather than after it. Introducing MFA during a change everyone already expects is far easier than introducing it later as a separate imposition.

The objects that cause problems

Mailboxes migrate predictably. These are where the hours go:

• Shared mailboxes and their permissions, which frequently do not map cleanly and need documenting before the move.
• Public folders. If you still have them, budget separately — migration is genuinely awkward, and the better outcome is usually replacing them with shared mailboxes or Teams rather than moving them.
• Delegate and send-as permissions, particularly executive assistant arrangements. These break silently and are noticed immediately by exactly the people you least want inconvenienced.
• Distribution groups, and deciding which should become Microsoft 365 groups.
• Resource mailboxes for rooms and equipment, with their booking policies.
• Mail-enabled applications — scanners, line-of-business systems, alerting tools that relay through Exchange. These are the most commonly forgotten and the most commonly broken.
• Archives and PST files scattered across user machines.

That mail-enabled applications point deserves attention. A multifunction printer configured years ago to scan-to-email through the local Exchange server will simply stop, and nobody will connect it to the email migration until someone tries to scan a document.

Cutover mechanics

The details that determine whether the switchover is smooth:

1. Lower the DNS TTL on your mail records several days beforehand, so the change propagates quickly rather than over hours.
2. Complete a full data sync in advance, then run a final incremental pass at cutover so only recent mail moves during the window.
3. Change the MX record, and expect a period where mail arrives at both destinations while DNS propagates.
4. Reconfigure clients. Outlook generally handles this automatically with autodiscover configured correctly, and mobile devices frequently need manual attention.
5. Verify mail flow in both directions, and specifically test any application that sends mail.
6. Keep the old environment running for a period. Do not decommission Exchange the following week.

On that last point: if you are keeping directory synchronisation, be aware that fully removing the last Exchange server is not straightforward, because Exchange management tooling remains a supported way to manage certain mail attributes on synchronised objects. Plan the decommissioning deliberately rather than assuming it is a simple uninstall.

After the move

• Arrange backup for Microsoft 365. Retention policies are not backup, and data protection is your responsibility under the shared responsibility model.
• Configure security properly — MFA, conditional access, and blocking legacy authentication protocols, which cannot enforce MFA and are the most common way MFA gets bypassed.
• Set up SPF, DKIM and DMARC for the new mail flow.
• Review licence assignment against actual users, which usually finds savings.
• Expect a support spike for two to three weeks, largely from mobile device configuration and people finding features in different places.

The security configuration is the item most often deferred and least often returned to. A new tenant starts with defaults, and defaults are not a security posture.

Sources

1. Microsoft Learn — Migrate email to Exchange Online using the Exchange cutover method
2. Microsoft Learn — What you need to know about a staged email migration
3. Microsoft Learn — Manage recipients in Exchange Hybrid environments using Management tools
4. Microsoft Learn — Block legacy authentication with Conditional Access