Coexistence versus big-bang cutover in a tenant migration
Two companies just merged, and their people are split across two Microsoft 365 tenants. You can move everyone in one long weekend, or you can wire the tenants together and move them in waves over months. The choice decides how your risk is shaped — spread thin over time, or piled into one night.
New to cloud? CAMPUX is a free, build-first course. Start here →
This is part of the Azure tenant-to-tenant migration guide, and it is the first real fork in the road. Before you touch a single mailbox, you pick a strategy: coexistence or big-bang. They are not two tools; they are two shapes of risk. One asks you to build a bridge between the tenants and walk people across it slowly. The other asks you to move the whole population in a single cutover window and hope you finish before Monday. Both are legitimate. Choosing the wrong one for your size is how migrations turn into month-long incidents.
What coexistence actually means
Coexistence is the phased approach. The source and target tenants run side by side, and users move in waves — fifty this weekend, a few hundred the next, until the source is empty. The catch is that while the population is split, the two tenants have to behave like one company. Microsoft is blunt about this: for phased migrations, you plan for a period where users exist in both tenants. In practice that means three pieces of plumbing you build and maintain. Mail routing so a message reaches whichever tenant a person currently lives in, no matter which address the sender used. Calendar free/busy sharing so someone in the old tenant can still see whether someone in the new tenant is booked. And usually directory sync so both tenants show each other in the global address list instead of turning colleagues into external strangers.
None of that is free. It is real engineering that you stand up before the first wave, run for the length of the project, and then tear down at the end. That is the true cost of coexistence — not the mailbox moves, which are the easy part, but the bridge you have to keep standing the whole time people are split across it.
Coexistence is a bridge you build, run, and demolish. The mailboxes are the easy part.
What big-bang trades away
Big-bang is the opposite bet. Everyone moves in one window — a Friday-to-Monday weekend is the classic shape — and there is no lasting cross-tenant plumbing to build because there is barely any coexistence period to bridge. People log off in the old tenant on Friday and sign into the new one on Monday with their mail, files, and calendars already there. The tooling is simpler, the free/busy and mail-routing gymnastics mostly vanish, and the project is measured in a weekend instead of a quarter. On paper it looks cheaper, and for the right company it is.
The trade is that all your risk lands on one night. A failed batch, a mail-flow rule that silently drops external mail, a licensing shortfall in the target tenant — in a phased move you catch it on wave one and fix it before wave two. In a big-bang you find it Monday morning with the whole company watching, and your rollback story is thin. You cannot cleanly un-send a weekend once users have started sending mail and editing files in the new tenant. Big-bang only works when the window is genuinely wide enough to finish, verify, and repair inside it.
Three things settle it. Size: a few hundred users can big-bang; tens of thousands cannot finish in a weekend and force you into waves. Downtime tolerance: if the business genuinely cannot take a hard cutover window, phased is the only honest answer. Coexistence complexity: the more you need cross-tenant mail flow, shared calendars, and a unified address book during the move, the more coexistence you are signing up to build — which is itself an argument for a shorter big-bang if you can get away with it. Match the strategy to the largest of these constraints, not the most convenient one.
How the choice usually breaks
The pattern in the field is consistent. Large moves — a real merger, a multi-tenant consolidation after years of acquisitions — go coexistence, because the population is too big and the downtime tolerance too low for anything else. You accept the longer calendar and the bridge-building because waves let you catch problems small and let you pause when something goes wrong. Small moves — a spun-off business unit of a few hundred people, a clean divestiture — can big-bang, because the whole thing fits inside one weekend and the coexistence you would otherwise build is more expensive than the short outage.
Data volume is the quiet limiter underneath all of this. Even if you want a big-bang, throughput depends on how many mailboxes and how much OneDrive and SharePoint content you are moving, and mailboxes on legal hold can block outright. Past a certain size the weekend simply is not long enough, and the decision is made for you. That is why the honest planning question is not "which do I prefer" but "which one does my size and my downtime tolerance still allow." The cross-tenant details — mail routing, address-book coexistence, when to cut MX records — are where a phased plan lives or dies, and I walk through those in the piece on mail routing and coexistence.
The takeaway
Coexistence and big-bang are the same migration with the risk shaped differently. Coexistence spreads it thin over weeks and buys you the ability to catch problems small and roll back a wave, at the cost of building and running mail routing, free/busy sharing, and directory sync between two live tenants. Big-bang concentrates it into one window with far less plumbing, at the cost of a hard rollback and a bad Monday if anything slips. Large populations and low downtime tolerance push you to coexistence; small, self-contained moves can take the weekend. Pick by your constraints, size the plan to your data, and never big-bang a company that cannot fit inside its own cutover window.
Questions people also ask
What is the difference between coexistence and big-bang migration?
Coexistence is phased: the source and target tenants run side by side, with mail routing, calendar free/busy sharing, and directory sync between them, while users move in waves over weeks or months. Big-bang moves everyone in a single window, usually a weekend, with no lasting cross-tenant plumbing to build. Coexistence spreads risk over time; big-bang concentrates it into one night.
What does coexistence require in a tenant-to-tenant migration?
You stand up mail routing so messages reach whichever tenant a person currently lives in, calendar free/busy sharing so scheduling still works across the split organization, and often directory sync so both tenants can see each other in the address book. Microsoft frames this as planning for a period where users exist in both tenants. It is real engineering that you build, run, and then tear down.
Is big-bang migration risky?
The risk is concentrated rather than larger. Everyone cuts over in one window, so a failed batch or a mail-flow mistake hits the whole company at once, and your rollback story is thin because you cannot un-send a weekend cleanly. Big-bang works when the population is small enough and the cutover window wide enough that you can finish, verify, and fix inside it.
When should you use a phased migration instead of big-bang?
Choose phased when the population is large, when you cannot tolerate a hard downtime window, or when workloads are tangled enough that moving them together in one night is unrealistic. Waves let you catch a problem on the first fifty users before it reaches five thousand, and let you pause. Most large mergers and consolidations end up phased for exactly these reasons.
How long does a tenant-to-tenant migration take?
A big-bang cutover is a single weekend, but throughput still depends on data volume, so it only fits smaller estates. A phased coexistence migration runs weeks to months, driven by user count, mailbox and OneDrive sizes, mailboxes on legal hold, and bandwidth. The longer calendar is the price you pay for moving in safer, recoverable waves rather than all at once.