Forum Discussion
Group-Based Licensing (E3 → Business Premium): MutuallyExclusiveViolation – Months Unresolved
Hi Daniel, that is a painful one, especially because group-based licensing does not give you a true atomic "swap this SKU for that SKU" operation.
In practice, I would not count on group processing order to remove E3 and add Business Premium cleanly in the same evaluation cycle. If the backend sees both SKUs as conflicting at any point, `MutuallyExclusiveViolation` can block the assignment even if the end state would be valid.
For a production migration, I would test a scripted maintenance-window approach with a small pilot group: remove the old license, immediately assign the new one, then validate Exchange, Teams, OneDrive, and service-plan state. Mailboxes should not be permanently deleted instantly just because a license is briefly removed, but access can be interrupted, so the timing and rollback plan matter. If you must use inherited group licensing only, I think Microsoft support needs to confirm a supported backend path, because Entra group licensing is not really built as an atomic SKU replacement engine.
Hi Jamony,
thank you very much for both replies — this is the clearest technical answer I have received on this topic so far, and it came within days. For comparison: the support ticket has been open for months without a single substantive statement.
Your point that Entra group licensing is not built as an atomic SKU replacement engine matches what we are seeing in practice. Our test user was added to the Business Premium EWR group and still only holds SPE_E3, while the conflict error persists for all affected accounts.
Two things on our side that unfortunately rule out the staged approach:
- A previous test migration in production caused Exchange Online access outages of 3–5 hours for several users. One user was still unlicensed the following Monday, another two weeks later. That is not something we can repeat across ~87 accounts.
- Licensing in our tenant is managed exclusively via groups. Direct assignment is not an option we can adopt as a permanent workaround, only as emergency remediation.
So we are essentially stuck waiting for exactly what you describe — a confirmed supported backend path from Microsoft, or an official statement that no such path exists. Support has hinted at the latter once but has never put it in writing.
One follow-up question, if you have experience with it: in your scripted maintenance-window approach, roughly what propagation delay have you seen between license removal and the new SKU becoming effective? Our concern is less the mailbox itself and more the service plan re-evaluation window.
Thanks again for taking the time — much appreciated.