Microsoft Licence Mobility Through Software Assurance: Complete Documentation Guide

Licence mobility through Software Assurance is one of Microsoft's most commercially powerful but least understood provisions. It allows organisations to deploy eligible server software licences on third-party shared infrastructure — AWS, Google Cloud, and authorised hosting partners — without purchasing additional licences. For organisations in hybrid or multi-cloud strategies, this provision can represent $200,000–$2,000,000 in avoided re-licensing costs. Yet we regularly find organisations either not using it at all, or using it without the required verification documentation — which creates an audit exposure that negates the entire benefit.

What Licence Mobility Through SA Covers

Licence mobility through Software Assurance allows the deployment of SA-covered server application licences on "shared servers" at authorised hosters. The mechanism is: your on-premises SA licence entitles you to run the same product on a hoster's shared infrastructure, without the hoster needing to licence the software additionally on your behalf.

Eligible Products

Product	Licence Mobility Eligible	Notes
SQL Server Standard & Enterprise	✅ Yes	Per-core licences; shared server rules apply
Exchange Server	✅ Yes	Server + CAL model; mobility applies to server licence
SharePoint Server	✅ Yes	Server + CAL model; mobility applies to server licence
Skype for Business Server	✅ Yes	Legacy deployments only
Project Server	✅ Yes	Server + CAL model
System Center	✅ Yes	Per-OSE model
Dynamics CRM Server	✅ Yes	Server + CAL model
BizTalk Server	✅ Yes	Per-core model
Windows Server	❌ No (AHUB instead)	Covered by Azure Hybrid Benefit for Azure; not mobility eligible for third-party hosters
Microsoft 365 Apps for Enterprise	❌ No	Desktop apps excluded from licence mobility
Windows Desktop OS	❌ No	Excluded entirely

The Shared Server Requirement

Licence mobility is available only on "shared servers" — defined as servers whose physical hardware is shared among multiple customers of the hoster. This requirement has significant implications for architecture decisions in AWS and GCP.

What Qualifies as a Shared Server

In AWS: standard EC2 instances running on shared physical infrastructure qualify. EC2 Dedicated Instances (dedicated hardware per customer) also qualify for licence mobility because the "shared" definition in Microsoft's Product Terms refers to the server being operated by a hoster, not whether hardware is shared at the physical layer. EC2 Dedicated Hosts (where you control the physical host) do NOT qualify under some interpretations — because you effectively control dedicated infrastructure, making you more analogous to an on-premises customer.

In practice, we recommend that organisations deploying SQL Server on AWS via licence mobility use EC2 Dedicated Instances rather than standard shared tenancy, as Dedicated Instances provide clearer compliance documentation while still qualifying as hosted infrastructure. Consult your independent licensing adviser before finalising the architecture choice.

The 90-Day Reassignment Restriction in Cloud Contexts

Licence mobility licences are subject to the same 90-day reassignment restriction as on-premises licences: once a licence is assigned to a specific hoster deployment, it cannot be moved to a different server (or cloud region/provider) for 90 days. This restriction applies per licence, not per deployment. For cloud workloads that scale dynamically, this creates licence inventory management challenges that require careful planning.

Organisations using SQL Server licence mobility for production SQL workloads in AWS typically maintain a reserve pool of 15–20% additional licences above current deployment to cover burst scenarios — ensuring burst capacity can be licenced immediately without triggering 90-day reassignment locks on the baseline pool. For more on reassignment rules, see the licence transfer and assignment rules guide.

Documentation Requirements: The Licence Mobility Verification Process

Unlike Azure Hybrid Benefit — which is applied through the Azure portal without any documentation submission — licence mobility on third-party hosters requires a formal verification process involving both you and the hoster.

Step-by-Step Verification Process

1. Confirm SA coverage: Verify in VLSC that all products you plan to deploy under licence mobility have active SA coverage. Note the agreement numbers and SA expiry dates.
2. Confirm hoster eligibility: Your hoster must be an Authorised Mobility Partner. AWS, Microsoft Azure (not applicable — use AHUB), Google Cloud, and most major enterprise hosters are authorised. Check Microsoft's Authorised Mobility Partner list before proceeding with smaller hosters.
3. Complete the Licence Mobility Verification form: Download the form from Microsoft's Volume Licensing documentation portal. The form requires: your Microsoft agreement number, SA coverage confirmation, product name and version, deployment quantity (number of cores or server licences), hoster name, and deployment region.
4. Hoster submits to Microsoft: You provide the completed form to your hoster's licensing contact. The hoster submits to Microsoft on your behalf and receives a Microsoft acknowledgement number. This process takes 10–20 business days.
5. Retain acknowledgement documentation: File the Microsoft acknowledgement number alongside your VLSC entitlement records. This documentation is what you produce in an audit to prove licence mobility compliance.

Documentation Retention Requirements

Microsoft's audit terms require licence records to be retained for a minimum of 5 years. Licence mobility verification documentation — the completed verification form and Microsoft acknowledgement — must be retained for the same period. Maintain a centralised repository for all verification forms, indexed by: agreement number, product, hoster, deployment start date, and acknowledgement number. Do not rely solely on the hoster's records — they may not maintain documentation on the required timeline.

Licence Mobility vs. Azure Hybrid Benefit: Choosing the Right Mechanism

Many organisations confuse licence mobility and Azure Hybrid Benefit because both involve using on-premises SA licences in cloud environments. They are different mechanisms with different eligible products and different geographic scope.

Dimension	Licence Mobility Through SA	Azure Hybrid Benefit
Applicable cloud providers	AWS, GCP, authorised hosters (NOT Azure)	Azure only
Eligible products	SQL Server, Exchange, SharePoint, others	Windows Server, SQL Server
Windows Server coverage	❌ Not eligible	✅ Yes — 40–49% Azure VM saving
Documentation requirement	Verification form required; 10–20 day process	Toggle in Azure portal — no form
SA required	Yes — active SA mandatory	Yes — active SA mandatory
Cost saving mechanism	Avoid purchasing cloud-native licences	Eliminate Windows/SQL OS charge in Azure VM pricing
Typical saving (SQL Server)	$7,128/2-core pack avoided (SQL Enterprise)	55% reduction on SQL Server Azure VM costs

Licence Mobility in M&A Contexts

Licence mobility provisions become particularly complex during mergers and acquisitions. When an organisation acquires another entity that has licence mobility deployments, those deployments are tied to the acquired entity's SA agreement — not the acquiring company's EA. Post-close, three scenarios arise:

• Acquiring an EA customer: If the acquired entity has an EA with licence mobility, the deployments remain valid under the existing agreement until EA expiry. Post-expiry, renewals must be under the acquiring entity's EA with new mobility verification forms.
• Acquiring a non-EA customer: Licence mobility requires active SA. If the acquired entity has perpetual licences without SA, no mobility rights exist. Cloud deployments at third-party hosters are unlicensed and must be remediated post-close.
• Divesting a business unit: If a divested entity's workloads were running under the parent's licence mobility rights, those rights do not transfer with the divestiture. The new entity requires its own SA coverage and new verification filings.

For the full M&A licensing framework, see our Microsoft licensing M&A post-close operations guide.

Negotiating Licence Mobility Provisions in EA Renewals

Licence mobility is a Software Assurance benefit — its availability depends on maintaining active SA on eligible products. During EA renewal negotiations, organisations with significant third-party cloud deployments should negotiate specifically around SA cost and licence mobility preservation.

Three negotiation levers apply specifically to licence mobility:

• SA cost reduction for server products: Negotiate SA as a percentage of net licence cost (typically 25%), not list licence cost. On SQL Server Enterprise at $14,256/core, SA at 25% of list = $3,564/core/year. Negotiated to 25% of net (e.g., $10,000/core) = $2,500/core/year — a meaningful reduction for large SQL Server estates.
• Licence mobility extension provisions: Request contractual language that preserves licence mobility rights for a defined period (typically 60–90 days) after SA expiry, to allow time for renewal processing without gaps in cloud compliance.
• New product inclusions: When negotiating SA renewals, push to include new products under SA that you plan to deploy via licence mobility on cloud infrastructure, rather than purchasing cloud-native licences.

For the complete EA negotiation playbook, see the Microsoft EA negotiation advanced guide and the SAM programme implementation guide for how licence mobility fits into overall SAM governance.

Frequently Asked Questions

Which Microsoft products support licence mobility through Software Assurance?

Products eligible include SQL Server (Standard and Enterprise), Exchange Server, SharePoint Server, Skype for Business Server, Project Server, System Center, Dynamics CRM Server, and BizTalk Server. Notably absent: Windows Server (covered by Azure Hybrid Benefit for Azure deployments, not by licence mobility for third-party hosters), Windows desktop OS, and Microsoft Office desktop applications.

What is the Licence Mobility Verification form and when is it required?

The Licence Mobility Verification form is a mandatory document submitted to Microsoft when deploying SA-covered server licences on a third-party hoster or cloud provider (not Azure). It confirms SA coverage, hoster eligibility, and deployment compliance. For Azure deployments, no verification form is required — Azure Hybrid Benefit applies directly.

How long does licence mobility verification take?

Typically 10 business days but can extend to 20 business days during high-volume periods. Start the process a minimum of 30 days before planned deployment to avoid unlicensed deployment windows.

Can I use licence mobility for SQL Server on AWS?

Yes, provided you have active Software Assurance on your SQL Server licences and AWS is used as an Authorised Mobility Partner hoster. The deployment must follow shared server model requirements — EC2 Dedicated Instances qualify; standard shared tenancy EC2 also qualifies under most interpretations.

What happens to licence mobility rights when Software Assurance expires?

When SA expires, licence mobility rights end immediately. Any server software deployed under licence mobility on third-party hosters becomes unlicensed. There is no grace period. Plan your SA renewal timeline to ensure mobility-dependent cloud deployments maintain continuous coverage.

Does Azure Hybrid Benefit replace licence mobility for Azure deployments?

Yes — for Azure deployments, Azure Hybrid Benefit (AHUB) is the mechanism that applies Windows Server and SQL Server SA coverage to Azure VMs. Licence mobility through SA is specifically for third-party hosters (AWS, Google Cloud, etc.), not Azure. AHUB does not require a verification form.