A decade ago a Microsoft estate ran in one or two places you controlled, and licensing it, while never simple, was at least a single problem. Today the same products run in Azure, in other public clouds, and in your own data centers, often simultaneously, with workloads moving between them as teams optimize for cost and performance. Each of these locations carries its own licensing logic, and the rules that make a deployment compliant in one place do not automatically make it compliant in another. At the same time, Microsoft's visibility into where its software runs has grown sharply, so the gaps that open across a fragmented estate are not only more likely, they are more likely to be seen. This article explains the principles of licensing a multi cloud estate and how to keep it defensible.
For how audit risk is selected and what raises it, the Microsoft audit triggers pillar sets out the landscape. Here we focus on the specific exposure of running across clouds.
The rules change with the location
The first principle to internalize is that the same product can be governed by different licensing rules depending on where it runs. In Azure, certain benefits and counting methods apply that do not apply elsewhere. In your own data center, the core based rules and virtualization conditions of the Product Terms govern. In a third party public cloud, the picture depends on whether the workload runs on dedicated or shared hardware, on whether License Mobility or an equivalent right was properly established, and on conditions that can differ from both Azure and your own estate. A workload that is perfectly compliant in one location can become noncompliant the moment it is moved to another without the licensing being reassessed. Teams move workloads for technical and commercial reasons, and the licensing consequence of the move is the part that is most often forgotten.
A workload that is compliant in one location can become noncompliant the moment it moves to another, and the move is the part teams forget to reassess.
The telemetry follows the workload
The second principle is that running in a third party cloud does not make a workload invisible to Microsoft. In 2026 Microsoft draws on a wide range of telemetry to understand where its software runs and how it is used, including signals from management tooling and from products that report back regardless of the underlying cloud. Azure Arc and similar tooling can surface servers running outside Azure, including unlicensed ones. The practical effect is that a buyer cannot assume that a deployment in another provider's cloud sits outside Microsoft's view. Usage spikes, entitlement mismatches, and telemetry revealing workloads that do not reconcile with what was purchased all feed the anomaly detection Microsoft uses to select audit targets. A fragmented estate generates more of these signals, not fewer, because there are more places for the position to drift out of alignment.
Where the gaps open
The exposure in a multi cloud estate concentrates in a few predictable places, all of them downstream of workloads moving faster than the licensing position is maintained.
- Workloads moved between clouds without the licensing reassessed for the new location
- Mobility into a provider cloud assumed but never properly established
- Core counts that no longer match the host the workload now runs on
- Benefits that apply in one location relied on after a move to another
- Shared versus dedicated hosting differences overlooked in a third party cloud
Each of these arises from the same root cause: the rate at which workloads move now exceeds the rate at which most organizations update their licensing position. The estate is dynamic, the position is static, and the gap between them is what an auditor finds.
A worked illustration
Consider one workload that started in an owned data center and was later moved to a third party cloud to cut cost. The labels are indicative and used only to show how the move changes the position.
| Stage | Where it ran | Licensing reality |
|---|---|---|
| Original | Owned data center | Core licensed correctly for that host |
| After move | Third party shared cloud | Mobility never established, host larger |
| Audit view | Telemetry sees it running | Unlicensed where it now runs |
Nothing about the workload broke when it moved, which is why the gap went unnoticed. The licensing that made it compliant in the data center did not travel with it, the new host changed the count, and the mobility right that would have carried the owned license was never established. The telemetry then surfaced a workload that did not reconcile. This is the multi cloud finding in miniature, and it scales with every workload moved the same way.
How to keep a multi cloud estate defensible
The defense is to make licensing a step in the workload lifecycle rather than an afterthought, so the position stays aligned with where workloads actually run.
Where this leaves you
A multi cloud estate is now normal, and so is the exposure that comes with it. The rules change with the location, the telemetry follows the workload wherever it runs, and the gaps open because workloads move faster than the licensing position is maintained. None of this makes a multi cloud strategy wrong, but it does make deliberate licensing management a requirement rather than an option. The buyers who stay defensible treat each workload move as a licensing event, keep a live map of where everything runs, and reconcile against their own telemetry before Microsoft reconciles against theirs. The ones who get caught let a dynamic estate run against a static position and waited for an auditor to find the gap.
The full picture of what raises audit risk across a cloud estate, and how targets are selected, is set out in the guide below.
When the exposure is real, we take over the process through our Microsoft audit defense engagement.