Cutover Migration vs Staged vs Hybrid: How to Choose

Microsoft documents four ways to move Exchange mailboxes to Exchange Online: cutover, staged, express (minimal hybrid), and full hybrid. The documentation explains each one. It does not tell you which to pick. After 1.4M+ migrated users, we can: most organizations under 150 mailboxes should run a cutover, most above 150 should run a minimal hybrid, and full hybrid is only for organizations that genuinely need long-term coexistence. Here is the reasoning, method by method.

What a cutover migration is

A cutover migration moves every mailbox in the organization to Exchange Online in a single batch. There is no coexistence. On Friday everyone is on the on-premises server; on Monday everyone is in Microsoft 365. The Exchange admin center connects to your server over Outlook Anywhere, copies all mailboxes, keeps them synchronized with incremental passes, and then you flip MX records and complete the batch.

The constraints:

• Source: Exchange 2003 or later. In 2026 that means the servers we actually see — 2010, 2013, 2016, 2019 — all qualify.
• Size: Microsoft supports up to 2,000 mailboxes but recommends 150 or fewer. We hold the line at roughly 100. Above that, initial sync duration and cutover-weekend risk grow faster than the method can absorb.
• Timeline: pre-stage the sync during the week, cut over on a weekend. The DNS cutover itself is a 2–4 hour window on Saturday; users arrive Monday to working mailboxes.
• Identity: mailboxes are re-created in the cloud. Directory synchronization must be off during the migration. Users get new passwords and reconfigure Outlook profiles — plan the communication.

Cutover is the simplest method with the fewest moving parts, which is exactly why it fails least. We covered the full runbook in our Exchange-specific cutover guide.

What a staged migration is

A staged migration moves mailboxes in batches over weeks, using directory synchronization to keep on-premises and cloud identities aligned while both environments run. It sounds like the sensible middle option. It is not, because of one restriction that Microsoft's own decision pages bury: staged migration only supports Exchange 2003 and Exchange 2007 as the source.

Both of those products left extended support more than a decade ago. In 2026, the population of organizations that (a) still run Exchange 2007 and (b) are only now moving to Microsoft 365 is close to zero. We see a handful per year, usually inside acquisitions.

The confusion persists because Microsoft's migration documentation still lists staged as a peer option next to cutover and hybrid, and articles keep recycling it as if it were a current choice. It is not. If your server is Exchange 2010 or newer, staged migration is off the table by design — the batching behavior people want from it is exactly what hybrid provides. We keep a dedicated staged migration post for the legacy cases and for people who arrive searching the term.

What a hybrid migration is

A full hybrid deployment connects on-premises Exchange (2010 or later) to Exchange Online as one logical organization. The Hybrid Configuration Wizard builds federation, secure mail flow, free/busy sharing, and MRS migration endpoints. Mailboxes then move in batches, in either direction, while every user — cloud or on-prem — sees one address book and one calendar system.

Hybrid gives you three things nothing else does:

• True coexistence. Cross-premises free/busy, unified GAL, mail flow that behaves as one org for months or years.
• Phased moves at any scale. Batch 50 users this week, 200 next month, pause for quarter-end, resume.
• Offboarding. Mailboxes can move back on-premises. No other method is reversible.

The cost is complexity. HCW touches certificates, connectors, autodiscover, federation trusts, and directory sync — and every one of those is a failure point during and after the migration. We wrote up the recurring HCW problems in our Hybrid Configuration Wizard guide. Run full hybrid when you need what it uniquely provides: more than ~150 users moving in phases over an extended period, a business requirement to keep some mailboxes on-premises, or a merger where two orgs must coexist. Do not run it as a default.

Express migration — the overlooked middle option

Express migration (Microsoft now calls it minimal hybrid) is the option most decision articles skip, and it is the one we deploy most often above the cutover line. It runs a stripped-down HCW pass that creates the migration endpoint and performs a one-time directory sync — no federation, no long-term coexistence plumbing. You then move mailboxes in batches, exactly like hybrid, and decommission when done.

What you get: batched moves from Exchange 2010+, users keep their passwords (one-time sync), and Outlook profiles reconnect automatically after the move. What you give up: cross-premises free/busy and ongoing directory sync. That trade is correct whenever the migration will finish within a few weeks — which describes almost every 150–500 seat project we run.

Decision table

Read the table in this order: source version first (it eliminates options), then user count, then how long the two environments must run side by side. Downtime tolerance decides last — cutover concentrates all risk into one weekend; the batched methods spread it out but keep the project open longer.

What we actually pick in the field

Across 1.4M+ migrated users, the pattern is consistent:

• Under ~100 mailboxes: cutover. One weekend, one communication, done. We pilot 10–20 users first to validate the endpoint and throughput, pre-stage the full sync during the week, and cut DNS on Saturday. The organization starts Monday in Microsoft 365 with a 30-day hypercare window behind it.
• 150 to ~500 mailboxes: minimal hybrid. Batched moves, passwords preserved, project closed in two to three weeks. Full hybrid at this size is usually paying for coexistence nobody will use.
• Full hybrid: only when coexistence is the requirement, not a side effect. Multi-month phased moves, regulatory reasons to keep mailboxes on-premises, or M&A scenarios. Roughly one project in ten genuinely needs it.

Every project, regardless of method, gets the same verification pass: item counts and SHA-256 checks against source, per mailbox, before we sign off. That discipline — not the method choice — is why our data-loss count across all of it is zero. The end-to-end process, including DNS and client reconfiguration, is in our Exchange to Office 365 step-by-step guide, and our Microsoft 365 migration services page covers how we scope it.

Common failure modes per method

Cutover. Outlook Anywhere endpoint failures — expired or private certificates, RPC proxy misconfiguration — stop the batch before it starts; test the endpoint a week out, not on Friday. Underestimated initial sync is the other one: a 500 GB aggregate over a thin uplink does not finish in a weekend, which is why we pre-stage. And forgetting that directory sync must be disabled first produces duplicate, unlicensed cloud users that take longer to clean up than the migration took.

Staged. On the rare 2007 project: CSV batch errors from stale or mistyped addresses, and users left mail-enabled but not converted after their batch completes, so replies route to a dead on-premises mailbox. Conversion is a post-batch step people skip.

Minimal hybrid. Treating it as full hybrid — expecting free/busy between moved and unmoved users and filing tickets when it is absent. Set that expectation in writing before batch one. Also, the one-time sync means password changes after the sync do not replicate; freeze password resets during the window.

Full hybrid. HCW failures on certificates and inbound TCP 443 to the on-premises server lead the list, followed by autodiscover records still pointing on-premises after moves, and hybrid servers left unpatched for years after "temporary" coexistence became permanent. Per Microsoft's decommissioning guidance, plan the exit before you build the hybrid — most orgs never do, and the last Exchange server outlives everyone who understood it.

Choosing in one paragraph

Exchange 2007 or older: staged (or a third-party tool). Exchange 2010+ and under ~100 users: cutover, one weekend. Exchange 2010+ and 150–500 users with a short runway: minimal hybrid. A genuine requirement for months of coexistence, reversibility, or retained on-premises mailboxes: full hybrid. If you are between two of those lines, pick the simpler method — in our experience the simpler method with disciplined verification beats the flexible method with more failure points.