Licence Mobility — How It Works
Licence Mobility is a Software Assurance benefit that allows SQL Server core licences to be reassigned between servers more frequently than the standard 90-day restriction — and to authorised third-party cloud providers. Without SA, a SQL Server licence assigned to Host A cannot legally move to Host B for 90 days. In virtualised environments where VMs migrate continuously, this restriction is unworkable.
Server Farm Mobility
With active SA, SQL Server licences gain mobility within a server farm. A "server farm" is defined as a set of servers managed as a unit within a single data centre, or across two data centres within the same time zone region. Within the farm, SA-covered licences can be reassigned to any server at any time — effectively creating a floating licence pool. If you have a 5-host VMware cluster with SA-covered licences assigned to the farm, SQL VMs can migrate between any of the 5 hosts without triggering the 90-day reassignment rule.
Cloud Mobility (BYOL)
SA-covered licences also enable Bring Your Own Licence (BYOL) to authorised cloud providers — including AWS (as an Authorised Mobility Partner) and Azure. You can temporarily or permanently deploy SQL Server VMs in the cloud using existing on-premises licences. For AWS, Microsoft requires a Licence Mobility Verification Form submitted through the cloud provider. For Azure, the mechanism is Azure Hybrid Benefit (AHB), which is declared directly on the VM and provides 40–55 % compute cost savings by removing the SQL Server component from the hourly rate.
Without SA — Licences Are Anchored
Perpetual licences without SA have no mobility rights. They are locked to the specific server they are assigned to for a minimum of 90 days, and can only be reassigned after 90 days (or immediately if the server permanently fails). In a virtualised environment with live migration, this means every host that could potentially run a SQL VM must be independently licensed — because any VM migration to an unlicensed host violates the terms. This is why SA is considered mandatory, not optional, for virtualised SQL Server.
"Software Assurance is the single most important investment for virtualised SQL Server. Without it, you either licence every physical host in the cluster (dramatically over-licensing) or accept compliance risk every time a VM migrates. The SA cost is almost always less than the cost of licensing every potential destination host."
Per-VM vs Per-Host — Licensing Strategy Comparison
The fundamental decision for virtualised SQL Server: licence individual VMs (based on virtual cores) or licence the entire physical host (based on physical cores). Each approach has distinct cost dynamics, compliance implications, and operational trade-offs.
| Dimension | Per-VM Licensing | Per-Host Licensing (Enterprise + SA) |
|---|---|---|
| What you licence | Virtual cores per VM (min 4 per VM) | All physical cores on the host |
| Edition | Standard or Enterprise | Enterprise only (Standard has no unlimited VM rights) |
| SA requirement | Required for SQL 2022+ per-VM licensing | Required for unlimited virtualisation rights |
| VM limits | Only licensed VMs are covered | Unlimited SQL VMs on the host |
| New VM provisioning | Requires new licence allocation per VM | No additional cost — spin up instantly |
| VM migration | Must track which host each VM runs on | Irrelevant — all hosts in farm are licensed |
| Compliance complexity | High — per-VM tracking, vMotion monitoring | Low — licence the host, document once |
| Cost efficiency | Better for 1–3 SQL VMs on a large shared host | Better for 4+ SQL VMs per host (high density) |
| True-up impact | Every new VM increases licence count at true-up | No true-up impact from new VMs on licensed hosts |
Worked Example — VMware Cluster Licensing
Consider an enterprise running 20 SQL Server VMs across a 3-host VMware cluster. Each host has 16 physical cores (48 total). Each VM is allocated 4 vCPUs.
| Approach | Licences Required | Edition | Approx. Cost (List) | Compliance Complexity |
|---|---|---|---|---|
| Per-VM (Standard) | 80 cores (20 VMs × 4 vCPU) | Standard | $315,600 (80 × $3,945) | High — track every VM migration |
| Per-VM (Enterprise) | 80 cores (20 VMs × 4 vCPU) | Enterprise | $1,140,480 (80 × $14,256) | High — same tracking burden |
| Per-Host (Enterprise + SA) | 48 cores (3 hosts × 16 cores) | Enterprise | $684,288 (48 × $14,256) | Low — hosts licensed, VMs move freely |
| Winner at 20 VMs / 3 hosts | Per-VM Standard is cheapest by licence cost — but Per-Host Enterprise is cheaper than Per-VM Enterprise and provides unlimited VM rights, zero migration tracking, and no true-up exposure for new VMs | |||
Sparse SQL VM Density
Per-VM licensing is more cost-effective when: (1) you run only 1–3 SQL VMs on a large host (licensing 12–24 vCPUs vs 32–64 physical cores), (2) SQL VMs are concentrated on dedicated hosts separate from non-SQL workloads (no wasted host licensing), (3) you use Standard Edition (significantly cheaper per core than Enterprise), and (4) your SQL VMs have small vCPU allocations (4 vCPUs each). The trade-off: you accept higher compliance complexity and must implement VM-to-host tracking, vMotion affinity rules, and per-VM licence documentation.
Dense SQL VM Environments
Per-host licensing is more cost-effective when: (1) you run 4+ SQL VMs per host (the aggregate vCPU count approaches or exceeds physical core count), (2) SQL VMs are distributed across shared infrastructure (VMware DRS moves VMs unpredictably), (3) you need Enterprise Edition features (Always On AGs, compression, partitioning — licensing Enterprise per-host is cheaper than per-VM Enterprise at scale), and (4) you want zero complete EA true-up guide exposure from new SQL VMs on licensed hosts. The trade-off: higher upfront cost, but dramatically lower compliance risk and operational overhead.
EA True-Up Strategy for Virtualised SQL Server
Organisations on Microsoft Enterprise Agreements must report licence usage increases at the annual true-up. Virtualisation creates unique true-up challenges because SQL VM counts can change rapidly.
Track Peak Usage, Not Average
EA true-up reports peak deployed usage — the maximum number of SQL Server licences in use at any point during the year. If you normally run 100 core licences but spun up additional VMs for a project reaching 120 cores for two months, you owe the true-up on 120, not 100. Monitor SQL Server licence consumption continuously (not just at true-up time) and record peak values monthly. This prevents surprises when the true-up invoice arrives.
Need Expert SQL Server Licensing Advisory?
Redress Compliance provides independent Microsoft licensing advisory — fixed-fee, no vendor affiliations. Our specialists help enterprises optimize SQL Server licensing across virtual and cloud environments.
Explore Microsoft Advisory Services →Align Major Deployments With EA Milestones
If possible, time major SQL Server deployments relative to your EA anniversary. A large new deployment immediately before true-up means you pay for a full year retroactively. The same deployment immediately after true-up gives you up to 12 months before it is reported — and if your EA renewal falls within that period, you may negotiate the incremental licences as part of renewal terms rather than paying list-rate true-up pricing. This is not about avoiding compliance — it is about optimising the financial timing of legitimate purchases.
True-Up Only Reports Increases, Not Decreases
EA true-up is one-directional during the term: you report and pay for increases, but you receive no credit for decreases until EA renewal. If you decommissioned 20 SQL VMs but added 10 new ones, you owe for 10 additional — you cannot offset the 10 against the 20 removed. However, document all decreases meticulously for use at renewal negotiation. Presenting evidence that your actual usage is below your committed baseline strengthens your position to negotiate a lower commitment in the next EA term.
Per-Host Licensing Eliminates True-Up Volatility
One of the strongest arguments for per-host licensing is true-up predictability. If all hosts in your SQL cluster are licensed with Enterprise + SA, adding new SQL VMs to those hosts creates zero true-up impact. The licence count is tied to physical cores, not VM count. New VMs on licensed hosts are already covered. This eliminates the most common cause of unexpected true-up costs in virtualised environments: VM sprawl. The only true-up trigger is adding new physical hosts to the cluster — which is a planned, infrequent event that procurement can budget for in advance.
Cloud BYOL — Extending Mobility to Azure and AWS
Azure Hybrid Benefit (AHB)
SA-covered SQL Server licences can be applied to Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs via Azure Hybrid Benefit. Each Enterprise core licence with SA covers 1 vCore of Azure SQL (Business Critical tier) or 4 vCores of General Purpose. The savings are substantial: a D8s_v5 VM (8 vCPUs) running SQL Enterprise in Azure costs ~$2.50/hour at PAYG vs ~$0.77/hour with AHB — a 69 % saving, or approximately $15,000/year per VM. AHB is declared at the VM level and can be activated or deactivated at any time.
📊 Free Assessment Tool
How optimized is your SQL Server licensing in virtualized environments? Our free assessment evaluates your license mobility and true-up strategy.
Take the Free Assessment →AWS BYOL via Licence Mobility
SQL Server licences with SA can be deployed on AWS EC2 dedicated instances or dedicated hosts through the Licence Mobility programme. AWS is a Microsoft Authorised Mobility Partner. You must submit a Licence Mobility Verification Form through AWS. Key restriction: BYOL on AWS requires dedicated tenancy (not shared/default tenancy) to ensure licence isolation. Each EC2 dedicated host's physical core count determines the licence requirement — the same per-core rules apply. BYOL to AWS is valuable for organisations with existing AWS infrastructure who want to avoid paying Microsoft's SQL Server surcharge on EC2 instances.
Best Practices for Dynamic Virtual Environments
✅ SAM Recommendations — SQL Server Licence Mobility & True-Up
- Maintain Software Assurance on all virtualised SQL licences: SA is not optional for virtualised deployments — it enables licence mobility, failover rights, per-VM licensing for SQL 2022+, and Azure Hybrid Benefit. Letting SA lapse on virtualised SQL licences creates immediate compliance risk
- Define your server farm explicitly: Document which hosts belong to your SQL Server farm for licence mobility purposes. Microsoft's definition requires servers in the same data centre or two data centres in the same time zone region. Ensure your farm boundaries match Microsoft's Product Terms
- Use VMware affinity rules for per-VM licensing: If licensing per-VM, configure DRS affinity rules to restrict SQL VMs to a subset of licensed hosts. This prevents SQL VMs from migrating to unlicensed hosts and creating compliance gaps. Without affinity rules, every host in the DRS cluster must be licensed
- Evaluate per-host vs per-VM at each EA renewal: As VM counts change, the optimal licensing approach shifts. At each EA true-up and renewal, re-calculate: would per-host licensing be cheaper than your current per-VM approach (or vice versa)? The breakpoint is typically 4–6 SQL VMs per host
- Budget for true-up based on projected peak, not current state: Forecast SQL VM growth for the coming year. Factor in planned projects, seasonal workloads, and M&A activity. Build the peak licence count into your annual budget to avoid year-end surprises
- Document VM-to-host mappings continuously: Whether licensing per-VM or per-host, maintain automated records of which SQL VMs run on which physical hosts at all times. This is the primary evidence Microsoft requests in audits. Tools: SCCM, Snow, Flexera, ServiceNow SAM, or custom PowerShell/vSphere scripts
- Activate Azure Hybrid Benefit on every eligible Azure SQL resource: Audit your Azure environment for SQL Server VMs and Azure SQL databases running at PAYG rates. AHB activation requires no migration — it is a billing toggle that can save 40–69 % per resource immediately
- Submit Licence Mobility Verification Forms for AWS BYOL: If deploying SQL on AWS using on-premises licences, complete the verification paperwork through AWS. This is a compliance requirement — failure to file the form makes your AWS SQL deployment technically unlicensed even if you own sufficient licences
Hybrid Scenarios — On-Premises + Cloud Licensing Coordination
Many enterprises run SQL Server across on-premises virtualised infrastructure and public cloud simultaneously. Coordinating licence mobility across these environments requires careful planning to avoid double-licensing or compliance gaps.
180-Day Dual-Use Window
During cloud migration, Microsoft allows 180 days of dual-use: the same SA-covered SQL licence can run simultaneously on-premises and in Azure. This window supports parallel operation during migration testing and cutover. After 180 days, the licence must be assigned to one location — on-premises or Azure (via AHB), not both. Plan migration timelines around this window: start AHB activation in Azure, complete data migration and testing, and decommission the on-premises instance within 180 days. If the migration extends beyond 180 days, you need separate licence entitlements for both environments.
Licence Pool Management Across Environments
Track your total SQL Server licence pool as a single inventory with assignments to three destinations: on-premises hosts, Azure (AHB), and AWS (BYOL). Each core licence can only be assigned to one destination at a time (outside the 180-day dual-use window). When planning cloud migration, model how many core licences shift from on-premises to cloud — and verify that the remaining on-premises hosts still have sufficient coverage. A common mistake: activating AHB on 50 cores in Azure while those same 50 cores are still assigned to on-premises hosts that continue running SQL VMs. After the dual-use window, the on-premises hosts are under-licensed.
EA True-Up Implications of Cloud Migration
Moving SQL workloads to Azure with AHB does not reduce your EA on-premises commitment during the term — EA true-up only reports increases, not decreases. However, at EA renewal, demonstrating that workloads have migrated to Azure (covered by AHB) strengthens your negotiation position to reduce the on-premises SQL Server commitment. Document every migration: source host, licence count released, Azure destination, AHB activation date. This evidence supports renewal negotiations and demonstrates compliant licence reallocation.