The runbook and cutover calendar for a tenant migration

A tenant move fails or succeeds on paper long before anyone runs a cmdlet. Two documents decide it: the runbook that says what happens in what order, and the calendar that says who feels it and when. Get those right and the weekend is boring — which is exactly what you want.

New to cloud? CAMPUX is a free, build-first course. Start here →

Moving people from one Microsoft 365 tenant to another — after an acquisition, a divestiture, or a consolidation — is the kind of work where improvising costs you a payroll cycle or a locked-out sales team. This note is part of the Azure tenant-to-tenant migration guide, and it is about the two artifacts that carry the whole project: the runbook and the cutover calendar. The tooling matters less than most people think. The ordering, the ownership, and the timing matter more than almost anything.

What a runbook row actually holds

A runbook is not a wiki page of prose. It is a table, and every row is one step with five things on it. The step — plainly stated, "reroute inbound mail for Finance to the target tenant," not "handle mail." The owner — one named person, never a team, because a step owned by everyone is owned by no one. The dependency — the row that must be green before this one starts. The verification — the specific check that proves it worked, a test message that arrives, a user who signs in, a report that reads Completed. And the rollback point — where you fall back to if the check fails, and whether falling back is even possible at that stage.

That last column is the one juniors skip and seniors obsess over. Some steps are reversible right up to the moment they aren't. Moving a custom domain is the classic example: a domain is associated with exactly one tenant at a time, so the instant you remove it from the source and add it to the target, there is no quiet undo — you are committed, and the plan from that row onward has to be forward-only. Knowing which rows are past the point of no return is most of what separates a calm cutover from a frightening one.

Identity first, then mail, then the rest

The order is not a style choice; the dependencies dictate it. Identity goes first. You map source users to target users and write the attributes the later moves rely on before any data moves — get the users created and mapped, and hold off on assigning the full mailbox licenses until that mapping is done, or the target provisions a mailbox where you needed a mail-enabled placeholder. Microsoft's own identity-mapping step exists precisely to stamp the attributes a mailbox move checks for, and the move process refuses to proceed if they are missing.

Mail comes next, because a cross-tenant mailbox move needs those identity attributes already in place. Then the rest — OneDrive, SharePoint, and Teams — with the wrinkle that Teams content leans on Exchange mailboxes, so Teams travels with or after mail, not before it. If you use the Migration Orchestrator, it sequences the supported workloads for you; if you are wiring individual workload tools together, you own that ordering by hand and the runbook is where you prove you got it right.

Identity before mail before the rest. The dependencies wrote that order, not you.

Dry runs and pilot waves before the real thing

You do not learn a runbook by reading it. You learn it by running it against a small, representative group — a pilot wave — and watching what breaks. Pick a dozen or two users who span the awkward cases: a shared mailbox, someone on litigation hold, a heavy Teams user, an executive whose assistant manages their calendar. Run the real steps, measure the real incidents, and fold every surprise back into the runbook before you touch anyone else. Then scale in waves, usually grouped by department or by criticality, so a problem hits twenty people instead of two thousand.

During those waves there is a stretch where users live in both tenants at once, and coexistence has to be planned, not hoped for: mail routing between the two, free/busy calendar visibility across them, and Teams federation so a moved user can still reach one who hasn't moved. The pilot is where you confirm coexistence actually holds, because that is the part that looks fine in a diagram and falls over in practice.

One calendar the whole company works from

The runbook is for the engineers. The cutover calendar is for everyone else. It takes the same plan and answers a different question — not "what step is next" but "who feels what, and when." Which department moves in which window. When inbound mail reroutes. When the domain moves and sign-in briefly changes. When a group should expect their Teams to go quiet for an hour. There is one authoritative copy, and it is the copy the service desk works from.

That single calendar is worth more than it looks. When the help desk can see that Finance cuts over Saturday night, they stop being surprised by Monday's tickets — they pre-empt them, post the notice, staff the phones, and answer "yes, that's expected, here's what to do" instead of opening a war room. It also ties straight into the communication plan: the calendar decides the timing, the comms plan decides the wording, and a user who was told what to expect on Friday does not file a panic ticket on Monday.

The takeaway

Build the runbook as a table where every row carries a step, one owner, its dependency, a verification, and a rollback point — and be honest about which rows are past the point of no return. Order it the way the dependencies demand: identity, then mail, then the data and Teams that ride on top. Rehearse it with a pilot wave, freeze the environment for the cutover, and keep the whole thing off the business's worst weeks. Then publish one cutover calendar the service desk lives by. Do that and the migration stops being a leap of faith and becomes a checklist you walk down — which is the only kind of tenant move worth signing your name to.

Questions people also ask

What should a migration runbook contain?

Each row should name the step, the single owner responsible, the dependency that must be done first, the verification that proves it worked, and the rollback point you fall back to if it fails. The runbook is the ordered list of those rows, so anyone can read down it and see exactly what happens next and who owns it.

What order do you migrate in a tenant-to-tenant migration?

Identity comes first: map source users to target users and write the attributes mailboxes depend on before you move any data. Mail follows, because a mailbox move needs those identity attributes in place. Then the rest — OneDrive, SharePoint, and Teams, which depends on Exchange mailboxes. The Migration Orchestrator sequences supported workloads for you.

What is a cutover calendar in a migration?

It is the single authoritative schedule that translates the runbook into who-feels-what-when: which department moves in which window, when mail reroutes, when the domain moves. It exists so the service desk knows what changes before users do, and can answer or pre-empt the tickets instead of being surprised by them.

Why run a pilot before a tenant migration?

A pilot is a small, representative wave you run for real to find what the plan missed. You measure actual incidents, fix the runbook, then scale in waves. Skipping the rehearsal is how a migration that looked clean on paper turns into a Monday of locked-out users and mail bouncing between two tenants.

What is a change freeze during migration?

A change freeze is a defined window where nothing risky is touched — no new licenses, no directory edits, no domain changes outside the plan — so the migration runs against a stable state. You also avoid overlapping cutover with financial close, audits, or major sales events, when the business cannot absorb a disruption.