Mapping Microsoft 365 licenses across two tenants: they don't transfer, they get rebuilt
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.
New to cloud? CAMPUX is a free, build-first course. Start here →
Two companies merge. You are moving mailboxes, OneDrive, SharePoint, and Teams out of the source tenant and into yours, and part of the Azure tenant-to-tenant migration guide is the unglamorous line item that sinks more cutovers than any mailbox: the licenses. Here is the fact to internalize before anything else. A Microsoft 365 license is tied to the tenant that owns the subscription. It does not cross the boundary. The data moves; the license stays behind. You are not migrating licenses — you are rebuilding an entitlement baseline in the target tenant from scratch.
Licenses are per-tenant, so you procure fresh in the target
Microsoft's own migration planning is blunt about this: make sure you have sufficient licenses available in the target tenant before migration. There is no button that ports a source subscription over. If the source had 400 Office 365 E3 seats, you buy 400 seats in your tenant, on your agreement, from your reseller. The source keeps paying for its own until it winds down. That means, for a window, the same human is being licensed twice — once in the tenant they are leaving and once in the tenant they are arriving in. That double-pay is unavoidable during coexistence; what is avoidable is paying for it longer than the migration actually runs.
Sequencing is the part people get wrong. Procurement has to land before the users do. A mailbox that arrives in a tenant with no license assigned is a mailbox its owner cannot open. Order the seats, confirm they show as available, assign them, then cut over. Reverse that order and your cutover morning is a queue of locked-out users and a very unhappy service desk.
Build a mapping table before you buy anything
You cannot procure the right seats until you know what the right seats are, and that is harder than it sounds because the same product wears different names in different tenants. The source may have bought Office 365 E3 through an Enterprise Agreement; you buy it through a CSP partner or direct on the web. Microsoft's licensing reference lists three identifiers for every product, a friendly name, a PowerShell string ID like ENTERPRISEPACK, and a GUID, and the friendly names shift across purchase channels. So you do not map on the label. You map on what the license actually grants.
Match on the service plans, not the sticker on the box. Two SKUs with the same marketing name can grant a different set of features.
The unit that matters is the service plan, not the SKU
A SKU is a bundle. The features inside it — Exchange Online, SharePoint, Teams, Intune, Entra ID Plan 1 — are each a service plan, and a service plan can be toggled on or off per assignment. That is why two users holding the same E3 can have different capabilities: someone disabled a service plan on one of them. So your mapping table has two columns per user that matter. Source SKU and, under it, the exact list of enabled service plans. Then the target SKU you intend to grant, and the service plans it carries. When those two service-plan lists match, the user lands whole. When they don't, someone loses a feature.
The dangerous case is not the obvious mismatch — a missing SKU throws an error and you catch it. The dangerous case is the near-match: a target SKU whose name reads close enough that everyone nods, but which omits one service plan a subset of users leaned on. Power BI, Audio Conferencing, a compliance add-on. The affected users get no error and no warning. They just find the feature gone weeks later, and now you are debugging a "why can't I schedule dial-in meetings anymore" ticket that traces back to a license column nobody diffed. Compare service plans line by line, or pay for it in tickets.
Apply it at scale with group-based licensing
Assigning SKUs one user at a time across a few hundred people is how you introduce human error. Use group-based licensing instead. You assign a subscription to a group in the Microsoft 365 admin center, and every member inherits the license and its enabled service plans automatically. Build your groups to mirror the mapping table — one group per target SKU-and-service-plan profile — drop users into the group that matches their source entitlement, and the assignment reprocesses for the whole membership. It also gives you a clean audit surface: the admin center's errors tab lists anyone who failed assignment, usually for insufficient seats, a conflicting service plan, or a missing usage location. Set usage location during user creation, because group-based assignment inherits the tenant's location when a user has none, and that is not always the location you want.
One ordering note carries over from single-tenant work: when you move a user between two licensed groups, add them to the destination group and confirm the license applied before you remove them from the old one. Remove first and the user goes unlicensed until reprocessing catches up — which, in a large tenant under migration load, is not instant.
Reconciling two baselines into one
A merger rarely hands you two identical licensing models. The source standardized on E3 with a Teams Phone add-on; you standardized on E5. Reconciliation is a business decision wearing a technical costume: do you level the incoming users up to your E5 standard and pay more per seat, or match their old entitlement exactly and carry two baselines in one tenant? Either is defensible. What is not defensible is discovering the difference on cutover day. Diff the two baselines early, decide the target profile per user cohort, price it, and get sign-off — because every service plan you add or drop here is a line on a renewal someone in finance will read.
The takeaway
Microsoft 365 licenses do not transfer between tenants — they are rebuilt in the target. Procure fresh seats before users cut over so nobody lands unlicensed, map source SKUs to target ones on their service plans rather than their names, apply the map with group-based licensing so the assignment scales without hand error, and diff service plans line by line to catch the near-match SKU that silently drops a feature. Get all of that right and the story stays simple: the data migrates, the entitlements get rebuilt, and the baselines are reconciled before anyone buys a seat. That sequence is what keeps cutover morning from turning into a queue of locked-out users.
Questions people also ask
Do Microsoft 365 licenses transfer between tenants?
No. Microsoft 365 licenses are tied to the tenant that owns the subscription, and they do not move to another tenant. In a tenant-to-tenant migration you buy or assign fresh licenses in the target tenant. The data moves; the subscription stays. Enterprise Agreement customers can sometimes negotiate a remap with Microsoft, but that is a contract exception, not a technical transfer.
How do I license users in the target tenant during a migration?
You procure the equivalent subscriptions in the target tenant first, then assign them to users before or at cutover. The reliable way to do this at scale is group-based licensing: assign the SKU to a group and every member inherits it. Procurement must land before the users do, because a user who arrives with no license is a user locked out of mail and files.
Why do SKU names differ between two tenants?
The same product carries different names and identifiers depending on how it was bought and which tool you view it in. An Enterprise Agreement, a CSP partner, and a direct web subscription can list the same Office 365 E3 under different friendly names, string IDs, and GUIDs. Map on the underlying service plans, not the label, so you compare what the license actually grants.
What is a service plan inside a Microsoft 365 SKU?
A SKU is a bundle, and the individual features inside it are service plans. Exchange Online, SharePoint, Teams, and Intune are each a service plan within a larger SKU. You can turn service plans on or off per assignment, which is why two users on the same SKU can have different features. When you map licenses across tenants, compare at the service-plan level.
How do I avoid a user losing a feature after migration?
Build the mapping table on service plans, not SKU names. A target SKU that looks like a match can quietly omit a service plan the user relied on, and the user lands with no error and a missing feature. Compare the enabled service plans on each source user against what the target SKU grants, and reconcile the gaps before you cut over, not after the ticket arrives.