Short, honest write-ups of the ideas that come up in interviews and on the job. Each one teaches the concept properly, cites the Microsoft documentation, and points back to the class that drills it until it sticks.
The mailbox move almost always works. What sinks a tenant-to-tenant migration is a person who found out too late — the department head who booked a launch on cutover weekend, the user who never heard they would re-register MFA.
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 when.
Two companies just merged, their people split across two Microsoft 365 tenants. You can move everyone in one long weekend, or wire the tenants together and move them in waves. The choice shapes the whole project.
A rollback plan is not a single undo button. In a tenant-to-tenant move, one stage backs out in five minutes and the next is effectively one-way. The whole job is knowing which is which before switch night.
The mistake teams make is treating cross-tenant migration as one product to buy. Microsoft moves some of it natively, wants you to think it moves the rest, and leaves real gaps you have to tool yourself.
Native cross-tenant tooling is good at the workloads Microsoft chose to cover. The trouble starts at the edges — the chat history, the coexistence window, the reporting across thousands of users — where a third-party tool earns its cost.
Someone says “we’ll save a fortune collapsing these two tenants into one.” They are right — eventually. First there is a stretch where the same people are licensed twice and the tooling bill lands.
One short, honest Azure note at a time — plus the occasional hiring signal. No spam, no card, unsubscribe in one click.