CloudekExchange email
Email Migration Methods to Microsoft 365: Cutover, Staged, Hybrid and IMAP
Compare cutover, staged, hybrid and IMAP email migration to Microsoft 365: size limits, supported sources, coexistence, and how to choose the right method.
Email Migration Methods to Microsoft 365: Cutover, Staged, Hybrid and IMAP
Originally published 27 September 2020 · Reviewed 5 November 2026
There is more than one way to move email to Microsoft 365. The right method depends on what you are moving from, how many mailboxes you have, and whether people need to work in both systems while you move. This article compares the four traditional methods and adds the options for Google Workspace and other systems. It replaces three older posts on the same topic. Check Microsoft's migration pages for the current source versions and limits before you commit, because support for older Exchange versions has ended.
Quick comparison
| Method | Source | Typical size | Coexistence | Notes |
|---|---|---|---|---|
| Cutover | Exchange 2003 or later | Up to 2,000 mailboxes, ideally about 150 or fewer | None | One-time move, then change MX |
| Staged | Exchange 2003 and 2007 only | Larger | Yes, in batches | Needs directory synchronisation; not for Exchange 2010 or later |
| Hybrid | Supported on-premises Exchange | Any size | Yes, long term | Needs the Hybrid Configuration wizard and sync |
| IMAP | Any IMAP system | Smaller | Limited | Mail only; no calendar or contacts |
Cutover migration
A cutover migration moves all mailboxes in a single operation and then switches mail routing. It is the simplest method and suits small organisations that want a short project. It does not need directory synchronisation. Users become cloud users and need licences. The details are in our cutover migration guide.
Staged migration
A staged migration moves mailboxes in batches over a period while directory synchronisation keeps accounts aligned. Microsoft documents it only for on-premises Exchange 2003 and 2007, and states that it is not available for Exchange 2010 and later. Those versions are long out of support, so staged migration is mostly of historical interest now. If you are still on them, the better plan is usually to move to a supported version or migrate directly, not to invest in a method that exists for obsolete servers.
Hybrid deployment
A hybrid deployment connects your on-premises Exchange organisation to Exchange Online so mailboxes can live in either place and move between them. Users see a shared address book and free/busy, and mail flows between the two. It needs a supported Exchange version at a recent update, directory synchronisation, valid public certificates, correct Autodiscover and open network paths. Hybrid is the method for larger organisations, for those that must keep some mailboxes on premises, and for migrations that will take months. It also costs the most to set up and keep healthy, so plan to remove it when the migration finishes.
IMAP migration
An IMAP migration copies mail from systems that support IMAP into Microsoft 365 mailboxes. It moves email only. Calendars, contacts and tasks must be moved separately. You create the mailboxes and licences first, and mail that arrives in the source after the copy is not migrated, so you switch the MX record and finalise carefully. Use it for small moves from hosting providers and other IMAP services.
Google Workspace and other sources
Microsoft provides dedicated tooling for moving from Google Workspace, which can bring across mail, calendars and contacts, and for other systems through its migration experiences in the admin center. Third-party migration tools are another option for complex sources, large archives or tenant-to-tenant moves. Compare features, price and security review requirements, because these tools need broad access to mailbox data.
How to choose
- Identify the source and its support status. An unsupported server changes the plan.
- Count mailboxes and total data. Large mailboxes and archives take time and need bandwidth.
- Decide whether coexistence is needed. If people must share calendars between systems during the move, you need hybrid or a third-party tool.
- Decide the end state. Fully cloud, or some mailboxes staying on premises?
- Check identity. Hybrid needs directory sync; cutover does not; an identity plan is needed either way.
- Plan the cutover of mail flow, including MX, Autodiscover, SPF, DKIM and DMARC.
- Pilot with a small group, and test mobile devices, shared mailboxes and applications that send mail.
Common mistakes
- Starting the project before cleaning up old mailboxes and stale accounts.
- Forgetting licences, which causes disruption after a grace period.
- Changing MX before testing routing and security filtering.
- Ignoring non-mailbox data such as public folders, archives and shared drives.
- Not tuning the DNS time to live ahead of the change.
- Skipping a communication plan for users.
A short example
Consider a firm with forty mailboxes on a supported on-premises Exchange server, no plan to keep any mail on premises, and a wish to finish in one weekend. Cutover is the natural choice: it needs no directory synchronisation, no long coexistence and no hybrid configuration. Now consider a company with six hundred mailboxes across three sites, shared calendars between teams and a plan to move over three months. That points to hybrid, with directory synchronisation and a staged schedule of mailbox moves, even though the method is called by a different name from the old staged migration. The point is to let your constraints pick the method, not the other way around.
Microsoft references
- Mailbox migration in Exchange Online, reviewed 5 November 2026.
- Hybrid deployment prerequisites, reviewed 5 November 2026.
This article was first published on 27 September 2020. It was rewritten on 5 November 2026 and now also covers the staged migration and multiple-account posts, which redirect here. Microsoft's live documentation takes precedence if it has changed.