Assigning licenses to a migrating population, at scale and in the right order
You have already worked out which SKUs the users need on the other side. Now you have to actually put those licenses on hundreds of accounts, in a sequence that does not strand anyone mid-move — and do it without licensing errors quietly parking half your batch.
New to cloud? CAMPUX is a free, build-first course. Start here →
This is the execution half of a job that starts on paper. It is part of the Azure tenant-to-tenant migration guide, and the companion piece to mapping the licenses — deciding that a source E3 with add-ons becomes an E5 in the target. Assume that mapping is done. What follows is how you assign those licenses across a whole population, in the order a mailbox move actually requires, and how you spot the two or three errors that will otherwise stall users you thought were finished.
Group-based licensing is how you do this at scale
Do not license a migration one account at a time. Microsoft's scalable mechanism is group-based licensing: you assign a product to a security or Microsoft 365 group, and every member inherits that license automatically. Add a user to the group and they are licensed on the way in; the assignment follows membership rather than being stamped by hand. For a migrating population, that is the whole game — build a group per target SKU, drop the right users into each, and the licenses land across everyone at once instead of in hundreds of individual clicks.
A couple of edges are worth knowing before you lean on it. Group-based licensing does not follow nested groups — if your licensing group contains other groups, only the first-level members get licensed, so keep membership flat. And on very large groups the processing is not instant; assigning or changing licenses for tens of thousands of users can take time to work through, which matters for your cutover timing.
Assign in the target before you move the mailbox
Sequence is not a nicety here. A mailbox move into the target has nowhere to land unless the target user is licensed for Exchange Online, so you assign before cutover, not after. Get this backwards and the move fails rather than waits.
The one subtlety, and it trips people: in a cross-tenant mailbox migration you do not just bulk-license the target accounts and walk away. Identity mapping has to run first so the source user's ExchangeGuid is stamped onto the matching target object. That stamp is what keeps the target account a mail user instead of provisioning it a brand-new empty mailbox — and if a fresh mailbox already exists on the target, the move fails. So the real order is: match identities and stamp the GUID, then apply the Exchange Online license, then run the batch. There is also a separate one-time cross-tenant user data migration license that has to be present, or the move stops with a licensing exception.
The target has to be licensed before the mailbox arrives — an unlicensed account is a move that fails, not one that waits.
The errors that park a batch
When an assignment fails, it does not shout — the user just sits in an "errors and issues" list on the product, and you go read why. Three causes account for most of it.
Usage location not set. Some services are not offered in every country, so a license cannot be assigned until the account has a usage location. In group-based licensing, users without one inherit the tenant's location — which is fine until that default is wrong for someone, at which point their assignment fails. Set the usage location on the account and it reprocesses.
Conflicting service plans. If a user ends up with two products whose service plans cannot coexist — often because they still hold a direct license alongside the new group one — the assignment throws what PowerShell calls a MutuallyExclusiveViolation. Entra will not pick a winner for you. You decide which product keeps the overlapping plan, usually by turning that service off on one of the two assignments.
Not enough licenses. The plainest one: the group has more members than you have seats in that SKU. Buy the shortfall or trim the group. Duplicate proxy addresses are the other classic — two Exchange objects sharing an SMTP address will block the license until you decide which object owns it.
De-licensing the source is a real step, not an afterthought. Once the mailbox and data have moved and users are working in the target, unassign the source licenses — that is what reclaims the seats and stops you paying for the same people in two tenants at once. Do it too early, though, and you can cut a user off before their target license has finished applying, so confirm the target license is live on the account first. If you are shifting a user between two licensed groups rather than off the source entirely, add them to the destination group and confirm the new license applies before removing them from the old one, or they go briefly unlicensed in the gap.
The takeaway
Reassigning licenses at migration scale is group-based licensing, applied in order. Build a group per target SKU and let membership carry the license. License the target before the mailbox move — after identity mapping has stamped the GUID, and with the one-time migration license in place. Watch the errors-and-issues list for the usage-location, conflicting-plan, and out-of-seats failures that quietly hold users back. Then, once people are live on the other side, unassign the source licenses to reclaim the seats. Assign forward, verify, reclaim behind — that is the shape of a clean cutover.
Questions people also ask
Do you need to assign licenses before a tenant-to-tenant migration?
Yes. The target user needs the right Exchange Online license before the mailbox move can land, so you assign in the target ahead of cutover, not after. There is also a one-time cross-tenant user data migration license that must be present, or the move fails with a licensing error.
What is group-based licensing in Microsoft 365?
It is assigning a product license to a security or Microsoft 365 group instead of to individuals. Every member of the group inherits the license automatically, and anyone added later is licensed on the way in. For a migrating population of hundreds of users, it is the scalable way to license everyone at once.
Why is my license assignment failing with a usage location error?
Some services are not offered in every country, so a license cannot be assigned until the user has a usage location set. In group-based licensing, users without one inherit the tenant location. If that default is wrong for a user, set the usage location explicitly on the account and the assignment reprocesses.
What causes a conflicting service plans error?
Two products assigned to the same user can each contain a service plan that cannot coexist with the other. PowerShell reports this as a MutuallyExclusiveViolation. Entra will not resolve it for you: you decide which product keeps the plan, usually by turning off the overlapping service on one of the two assignments.
When do you remove the source tenant licenses?
After the mailbox and data have moved and users are working in the target, you unassign the source licenses. Doing it earlier risks cutting a user off before their target license has finished applying. Reclaiming those source seats is also what stops you paying for the same people twice.