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.
Choose a supported identity path, prove permissions with a pilot, and rehearse the final delta. Copying bytes is only one part of retiring a file server.
Two companies became one on a slide, and below the slide is a directory, a payroll of mailboxes, and the engineer who has to make one identity out of two without anyone losing a workday. The map of that work — identity first.
Nobody’s account moves from one tenant to another — you build a new identity in the target and match it to the old one, and everything attached to it has to be rebuilt in the right order or your users get locked out on switch day.
The move itself is one cmdlet. The reason your first batch fails at 2 a.m. is an attribute you didn’t stamp on a target object three days earlier — and the service doesn’t tell you until it tries.
On cutover morning, half the acquired company opens Outlook to a “you don’t have a license” wall — because someone assumed the licenses would follow the mailboxes across the tenant boundary. They don’t.
The mailboxes move, the users move, and the access rules quietly enforcing MFA and blocking legacy sign-ins stay behind in the old tenant — so the day identities arrive is the day the estate is wide open, unless you rebuilt those policies first.
You can migrate mailboxes, groups, and licenses to a new tenant, but a B2B guest has nothing inside it to carry — it is a reference to an identity that lives somewhere else, and references do not travel.
Move a SharePoint site to another tenant and the files arrive intact — but every permission on them points at users who don’t exist in the new tenant, so unless you mapped those identities first, the content lands locked.
The bytes move themselves, quietly, without ever leaving the Microsoft cloud. The part that goes wrong is everything around them: who owns the moved OneDrive on the other side, and whether the links people already sent still open.
The consent is granted, the endpoint exists, the target MailUsers are stamped. This is the part where mailboxes leave one tenant and arrive in another — the batch, the move, and the one command that flips the source into a forwarding stub.
For a few weeks, half the mailboxes live in one tenant and half in the other — but everyone still hands out the same @contoso.com address. That domain can only be verified in one place. This is how mail crosses the line anyway.
Someone schedules a meeting across the line and every attendee shows up as a wall of hatch marks — no availability, no slot. That gap is the first thing anyone notices during coexistence, and it is fixable with an organization relationship.
Someone asks you to “just move the Teams” during a merger, and it sounds like one job. It is not. A Team is a front end stitched over several services, and the part everyone cares about — the conversations — is the part Microsoft gives you the least help moving.
Someone asks why the main line still rings in the old tenant, and you learn the hard way that a phone number is not an object you own — it is a service the carrier rents you, and it goes nowhere until a port order says so.
You migrate a user into the new tenant and assume they can sign in. Then MFA prompts them, they have no method registered on this side, and they cannot reach the page that would let them register one. A Temporary Access Pass is how you break that loop.
The source tenant is hybrid — one on-prem Active Directory synced up to Entra with Entra Connect. The users are moving to a different tenant, and the first thing you learn is that the sync you already run does not simply point somewhere new.
Someone will ask you to “just move the laptops to the new tenant.” There is no button for that. Intune enrollment is glued to the tenant, so the device leaves the old one and enrolls into the new — and its policies are rebuilt, not carried.
A pile of laptops from an acquired company shows up on your desk, and you assume you can point them at your tenant. You can’t. Every one is already claimed, keyed on a hardware fingerprint registered to someone else’s Autopilot.
A BitLocker recovery key does not belong to the laptop. It belongs to the tenant the laptop is joined to. Move the tenant and forget that, and you can delete the only copy of the key that stands between a user and a locked drive.
You can change the Microsoft Entra directory a subscription belongs to, and every VM, disk, and database goes with it. What stays behind is everyone’s permission to touch those things. That gap is the whole story.
A director asks you to hand a set of Azure resources to a company you just acquired, in their tenant. You look for a “move to another tenant” button. It isn’t there — because that operation doesn’t work the way you would expect.
Someone hands you a storage account in one company’s tenant and says “get it into ours.” That single sentence hides two completely different jobs, and picking the wrong one costs you either a support case or a silent access outage.
You can copy every mailbox in the background and nobody notices. The migration only becomes real the moment you change a DNS record and mail for the whole company starts landing somewhere new. The order and the TTL are everything.
One subscription is pulled out of the old tenant and dropped into the surviving one. The virtual networks and their gateways go with it. The wiring that connects them — peering, ExpressRoute, and overlapping address space — is where the work hides.
The resources arrived in the new tenant intact. Then someone opened Defender for Cloud, saw the Secure Score sitting at a fraction of where it was, and assumed the migration broke something. It didn’t — Defender resets, and you rebuild it.
Someone on the project asks, “and we’re bringing over the DLP policies and the labels, right?” The honest answer is no. Compliance configuration is stitched into the tenant it was born in, and it gets rebuilt, not moved.
You’ve worked out which SKUs the users need on the other side. Now you have to put those licenses on hundreds of accounts, in a sequence that doesn’t strand anyone mid-move. Group-based licensing and the right order are how.
One company writes prod, the other writes Production. One tags cost-center, the other CostCentre. Individually harmless. Together they quietly wreck your cost reports, your automation, and your governance.
Two companies merge, and someone signs off on moving a workload subscription into the surviving tenant. The resources arrive. The governance that used to wrap them does not — you rebuild the hierarchy and re-assign the policy.
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.
One short, honest Azure note at a time — plus the occasional hiring signal. No spam, no card, unsubscribe in one click.