As workloads move out of owned data centers and into provider clouds, a question follows them that many buyers never asked when everything ran on their own hardware: can the licenses I already paid for follow the workload to where it now runs? For a set of eligible products the answer is yes, through License Mobility, and it can save real money by letting you reuse owned licenses rather than rent them again from the provider. But the right comes with conditions, and the conditions are precisely where exposure hides. A buyer who assumes mobility applies, deploys accordingly, and misses a condition has an unlicensed workload running in a provider environment, with the gap multiplied across every instance handled the same way. As estates fragment across providers, this has become one of the cleaner findings for an auditor to surface. This article explains how the right works and how it is tested.
For the full method of mapping deployments to entitlements and rebuilding your position, the Effective License Position guide is the pillar. Here we focus on mobility as one mechanic that feeds it.
What License Mobility is
License Mobility is the right to take certain server licenses you own and assign them to run in a third party service provider environment rather than only on your own hardware. Without it, the default rule keeps many server licenses tied to the hardware and licensing model where they were deployed, which would force you to rent equivalent licenses from the provider when you move the workload there. With it, you can carry your owned entitlement to the provider and avoid paying twice. The economic logic is straightforward and the benefit is real, which is why buyers reach for it. The trouble is that the right is not a blanket permission. It applies to specific eligible products, it depends on conditions being met, and it requires steps that buyers frequently skip because nothing stops the workload from running when they do.
The conditions that make it valid
The single most important condition is active Software Assurance. License Mobility is a Software Assurance benefit, which means the right exists only while the coverage is active on the licenses in question. Let Software Assurance lapse and the mobility right lapses with it, even though the workload keeps running unchanged in the provider cloud. Beyond coverage, the product itself must be eligible, since not every server license can be moved this way. And there is a process step that buyers most often overlook: moving eligible licenses into a qualifying provider environment typically requires notifying Microsoft, often through a verification form associated with the provider. A buyer who has the coverage and the eligible product but never completed the process step has still not properly exercised the right. Each of these conditions is a separate place the arrangement can fail.
License Mobility is a Software Assurance benefit. Let the coverage lapse and the right lapses with it, while the workload keeps running as though nothing changed.
- Software Assurance must be active on the licenses being moved
- The specific product must be eligible for mobility
- The required notification or verification step must be completed
- The provider environment must be one that qualifies for the right
Why auditors test it
Mobility is attractive to an auditor because it sits at the intersection of two things that are hard for buyers to keep aligned: the licensing position and the actual location of workloads. The workload moved months or years ago when a team migrated to a provider. The Software Assurance status is tracked, if it is tracked, somewhere else entirely. The process step, if it was ever known about, was a one time action that nobody revisits. An auditor only has to ask where eligible workloads are running, then check whether the conditions for mobility were met for each one. Where a workload is running on a provider under an assumed mobility right that was never properly established, or whose Software Assurance has since lapsed, the workload is simply unlicensed where it runs. Because migrations happen in batches, one misunderstanding usually appears many times, and the finding scales with the migration.
A worked illustration
Consider a buyer who migrated a set of eligible workloads to a provider cloud and assumed their owned licenses came along. The figures are indicative and used only to show how the conditions decide the outcome.
| Condition | Buyer assumption | Audit finding |
|---|---|---|
| Software Assurance | Active on all licenses | Lapsed on part of the estate |
| Product eligibility | All eligible | Some products not eligible to move |
| Process step | Not aware one was needed | Notification never completed |
| Result | Fully covered by owned licenses | Workloads unlicensed where they run |
None of these failures stopped a workload from operating, which is exactly why they went unnoticed. The auditor reconstructs the position the buyer never maintained, and the gap that was invisible operationally becomes a clear finding. The defense is to know, for every moved workload, that each condition was actually met, rather than assuming the right travelled with the workload automatically.
How to defend the mobility position
Defending mobility is a matter of evidence rather than argument. For each eligible workload running in a provider environment, you want to be able to show that the product was eligible, that Software Assurance was active throughout the period in question, and that any required process step was completed. Where that evidence exists, the workload is defended. Where it does not, you want to find that out yourself, before an auditor does, so the gap can be addressed on your terms rather than presented to you as a finding. This is why mobility belongs in any self assessment of an estate that spans providers. It is also why the broader discipline of keeping deployments mapped to entitlements matters so much: mobility is one of several rights whose validity depends on conditions that are easy to lose track of once a workload has moved.
Where this leaves you
License Mobility is a genuine benefit that saves money, but it is a conditional right, not a default one. It depends on active Software Assurance, on product eligibility, and on a process step buyers routinely miss, and a failure on any of these leaves a workload unlicensed in the provider cloud where it runs. Because migrations happen in batches and nothing breaks when a condition is missed, the exposure builds quietly and scales with the move. Auditors test mobility precisely because it is hard for buyers to keep the licensing position aligned with where workloads actually live. The defensible position is to verify every condition for every moved workload yourself, as part of knowing your real position before anyone presents you with theirs.
The full method for mapping moved workloads to entitlements and rebuilding the position is set out in the guide below.
When the exposure is real, we take over the process through our Microsoft audit defense engagement.