License Mobility and True-Up Strategy for SQL Server in Virtualized Environments
Virtualization has transformed how SQL Server is deployed but also complicates licensing. In a virtualized environment, workloads move and scale rapidly, challenging traditional licensing static rules (like a license tied to a physical server). License Mobility – the ability to reassign licenses flexibly – becomes crucial.
Additionally, organizations under Enterprise Agreements must manage the True-Up process, reporting changes in usage annually. This article guides IT asset managers through strategies to handle license mobility in virtualized setups (including clusters and cloud VM scenarios) and how to plan true-ups to avoid financial surprises.
We’ll cover maximizing Software Assurance benefits for mobility, using license models like “per host” to simplify compliance, and best practices for aligning licensing with true-up cycles in an ever-changing virtual environment.
Read about SQL Server Licensing.
License Mobility in Virtual Environments
License Mobility Defined:
License Mobility is a Microsoft Software Assurance benefit that allows certain server licenses (including SQL Server) to be reassigned more often than permitted and to authorized third-party clouds without additional fees. A SQL Server license can only move to a new server every 90 days without mobility.
In highly virtualized setups – where VMs might migrate for load balancing or failover – that 90-day rule is impractical. With license mobility (active SA), you can move licenses as needed across servers in a server farm or to cloud infrastructures like AWS (which is an Authorized Mobility Partner).
In Practice: Suppose you have a VMware cluster of 5 hosts and license SQL Server per VM (not the whole cluster). Without license mobility, if a VM running SQL moves from Host A to Host B, technically, the license couldn’t follow it for 90 days (which would mean you suddenly need another license for Host B).
This is unworkable. License mobility via SA solves that: as long as the total number of licenses equals the total number of VMs*cores that need it, those licenses are considered floating within the cluster. You can dynamically assign them to whichever physical host runs the SQL VMs at a given time.
Cloud Mobility:
License mobility also allows moving on-prem licenses to cloud VMs (e.g., AWS EC2 or Azure) and back, which is useful for hybrid or cloudburst scenarios. For example, in a disaster recovery test, you might spin up an SQL Server VM in AWS and use an existing license for a short time – license mobility makes that legal and easy. In contrast, without it you might violate terms or buy cloud-specific licensing.
Key Considerations:
- Only licenses covered by Software Assurance have mobility rights. If you have perpetual licenses without SA, treat them as anchored – if they’re assigned to a host, they should stick there (or not be used in a dynamic scenario) until you either add SA or replace them with subscription licenses.
- Microsoft’s “server farm” definition (for mobility) typically means all servers in the same datacenter or within a certain distance can share licenses with mobility. Ensure your interpretation matches Microsoft’s Product Terms (usually, two data centers in the same time zone region count as one farm).
- License Mobility Verification: When moving licenses to certain cloud providers like AWS, Microsoft asks customers to fill a License Mobility verification form through the provider. IT asset managers should be prepared to do this paperwork to stay in compliance – it’s basically informing Microsoft of your BYOL usage in the cloud.
Per-VM vs. Per-Host Licensing Strategy
When virtualizing SQL Server, you have two fundamental licensing strategies:
- License Per Virtual Machine: License each VM individually for SQL Server, based on the number of virtual cores (vCPUs) assigned to that VM (with a minimum of 4 per VM). For example, a VM with six vCPUs requires six cores of SQL licensing (sold as three 2-core packs).
- License the Host (Physical Cores): License all physical cores of the host machine with SQL Server Enterprise Edition with SA, which then covers any number of SQL VMs on that host.
Per-VM Licensing – Pros and Cons:
- Pros: You only pay for what you use. If you have a few VMs or smaller deployments scattered across hosts, you can license just those VMs. Good for scenarios where only one or two VMs in a large cluster need SQL, and others don’t (so licensing the whole host would be overkill).
- Cons: Management overhead – you must track each VM’s vCPU count and ensure sufficient licenses. Mobility considerations are critical; without SA, if that VM moves, you’re exposed (as explained). Microsoft updated its policy: starting with SQL Server 2022, per-VM licensing requires active SA or subscription. That means if you want to license VMs individually on a host that isn’t fully licensed, you need SA to be compliant. This change effectively pushes most orgs towards having SA in virtual environments or just licensing hosts outright.
Per-Host (Enterprise+SA) Licensing – Pros and Cons:
- Pros: Simplicity and unlimited virtualization rights. With Enterprise Edition and SA, one host’s cores cover unlimited SQL instances on that host. If you have a beefy server (say 32 cores) and you run 10 SQL VMs on it, you just need 32 cores worth of licenses (with SA) and you’re done, rather than licensing each VM’s cores separately, which might sum to more if VMs are overcommitted. It also means freedom to spin up new SQL Servers on that host without procurement delays. Mobility within a cluster is inherent – if every host in a cluster is licensed this way, VMs can move anywhere freely.
- Cons: Higher upfront cost. You might pay for some excess capacity if hosts aren’t fully utilized for SQL. This strategy usually makes sense when you have a high VM density of SQL or plan to in the future. Also, it’s only available with Enterprise Edition, which is pricier per core than Standard. For some smaller workloads, using Enterprise licensing just to cover virtualization might not be cost-justified.
Example Calculation:
An enterprise runs ~20 SQL Server VMs across a VMware cluster of 3 hosts (each host has 16 physical cores, for 48 cores). Each VM has between 4 and 8 vCPUs. If licensing per VM, worst-case if all VMs are fairly allocated, you might be licensing around 20*4 = 80 vCPUs (assuming average four vCPUs each, some more, some less) – requiring 80 core licenses.
If licensing per host, you’d license 48 physical cores (covering all three hosts) with Enterprise+SA, and then you can run all 20 VMs (and more if needed) across them. 48 cores vs. 80 cores—there is a big difference in license count.
Enterprise licenses cost more than standard licenses, but on that scale, the cost of an Enterprise license is worth the unlimited use. This example shows how, at scale, host licensing wins; at a smaller scale, per-VM might be fine (for instance, if there were just 2-3 VMs total, per-VM would likely be cheaper).
Read Edition Strategy: When to Use SQL Server Standard, Enterprise, or Developer Edition.
True-Up Strategy in a Virtualized World
If your organization is on a Microsoft Enterprise Agreement (EA), you likely must true-up annually. True-up reports any increase in usage (like additional licenses deployed) during the year and pays for the remainder of the term.
Virtualization can cause spikes or fluctuations in usage, so planning for true-up is key:
- Monitor Peak Usage: Track the highest number of SQL Server licenses annually. For example, maybe you normally use 100 core licenses, but at one point, you spun up extra VMs and hit 120 cores for a project. Even if those VMs were later shut down, under EA true-up rules, you might need to report the peak (depending on if licenses were short-lived or if Microsoft’s rules consider short-term spikes – generally, if something was deployed and running in production, it counts). Knowing your peak need informs what you’ll owe at true-up.
- Strategize Timing: If possible, align major deployments with EA milestones. For instance, if your true-up is every December, and you plan to deploy a big new SQL-based system in January, that means you have a whole year before it needs to be counted in a true-up (and when it is, it might be at renewal, which offers negotiation leverage). Conversely, try not to ramp up many new SQL VMs in the month before true-up. If you can help it, you’ll immediately incur costs. Of course, business needs drive timelines, but where there’s flexibility, coordinate with procurement timing.
- Removal and Decommissioning: One trick for EA true-ups is that they typically only count increases, not decreases, until renewal. That means if you removed some servers, you don’t get credit until the EA renewal (true-down). However, you should keep track of decreases to use in renewal negotiations or offset additions. For example, suppose you had 10 licenses not being used and added 10 elsewhere. In that case, you might argue you don’t need to buy more (though officially the contract might say otherwise mid-term, Microsoft might be amenable in some cases if you can show license reallocation.
- Utilize Hybrid Rights: Moving some workloads to Azure with Hybrid Benefit might not count against your on-prem license pool (since you’re repurposing licenses in Azure). Ensure this is documented because an auditor might see fewer on-prem servers and more Azure usage. If you can show that AHB covers them, you won’t be charged twice. There is no true-up on Azure consumption itself (you pay as you go), but if you shift usage to Azure for EA purposes, you might reduce the growth of on-prem license needs.
Budgeting for True-Up:
Asset managers should forecast how virtualization growth translates to license needs. A common scenario is VM sprawl – new VMs being created for projects. Each new SQL VM (if not on already licensed hosts) is an incremental license cost. When a team requests a new SQL Server VM, you should implement an internal mechanism: factor the licensing cost into the project budget or your true-up budget. This will avoid nasty surprises at year-end.
Enterprise Agreement Considerations:
- In modern licensing, Microsoft also offers subscription-based licensing through CSP or other programs, which might count differently or allow more flexibility. Some companies consider moving off EA to cloud subscriptions, especially for variable workloads.
- If you anticipate significant changes (like a big reduction because you plan to consolidate or move to PaaS databases), plan for this in the EA renewal. For example, don’t over-buy at a true-up if you know next year you’ll retire half of it – you might negotiate a shorter true-up term or some flexibility with Microsoft if discussed in advance.
Read Common Compliance Pitfalls in SQL Server Licensing.
Best Practices for Managing Licenses in a Dynamic Virtual Environment
- Use a License Management Tool: When dealing with dozens or hundreds of VMs, use tools to track where SQL Server runs. Cloud management platforms or SAM tools can map VMs to physical hosts and calculate licensing in various scenarios (per-VM vs per-host). This can inform you if you’re optimally licensed or if moving to a different model could save money.
- Host Affinity Rules: In VMware, you can set rules to restrict certain VMs to certain hosts (for example, keep all SQL Server VMs on a subset of fully licensed hosts). This way, you don’t accidentally violate compliance by moving a VM to an unlicensed host. Asset managers should collaborate with virtualization admins to implement such rules, aligning with the licensing model.
- Consider SQL Server Consolidation: Virtualization can lead to VM sprawl – many lightly used SQL VMs. Consider consolidating multiple databases onto a single SQL instance or at least fewer instances, especially if you have per-core licensing to cover a big server. Fewer instances = fewer licenses needed, as long as performance and business isolation requirements can be met. Techniques like multi-instance or multi-tenant SQL Server can be leveraged under one license if on one machine.
- Leverage Cloud for Burst: If you occasionally need extra SQL Servers (e.g., end-of-quarter processing), instead of permanently licensing for peak capacity, consider using cloud on-demand instances with licenses included for those short bursts. Yes, you pay a premium per hour, but it might be cheaper than keeping licenses idle year-round for a once-a-quarter surge. Remember that data might need to move, and performance must be tested.
- Keep SA on Virtualized Licenses: It cannot be overstated – maintain Software Assurance on any licenses in heavily virtualized use. The cost of SA is justified by the mobility and flexibility it provides. If budgeting is an issue, maybe not every single license needs SA (some standalone servers might not), but for those in clusters, budget for SA from the get-go.
- Stay Informed on Licensing Changes: Microsoft has been adapting licensing to virtualization realities (for instance, the new “Flexible Virtualization” policy and requirement of SA for per-VM licensing in SQL 2022+, as mentioned). These changes can introduce new opportunities (e.g., more flexibility for hosters) or new requirements. Keep your licensing approach updated accordingly – perhaps a compliant and optimal strategy in 2019 needs revisiting in 2025’s rules.
Recommendations for IT Asset Managers
- Analyze Workload Patterns: Review how your SQL workloads are distributed across VMs and hosts. If certain hosts consistently run many SQL VMs, consider fully licensing those hosts (Enterprise+SA) for efficiency. For hosts with sporadic SQL usage, per-VM might suffice—but ensure those VMs have SA.
- Implement License Pools: Treat licenses as a resource pool if you operate a private cloud. For example, you have a pool of 100 SQL core licenses with SA; set up a governance that at any given time, your deployed SQL VMs’ total assigned cores shouldn’t exceed 100. Use monitoring to enforce this. This way, you know you’re always within your purchased limits (and if you need more, you proactively buy or reallocate).
- Coordinate with Virtualization Teams: Make licensing a part of the VM lifecycle management. When new ESXi or Hyper-V hosts are added to a cluster, factor in whether you need to license them for SQL or keep certain hosts designated as “SQL hosts.” When migrating VMs, consult the licensing impact. This cross-team coordination prevents accidental compliance gaps.
- Plan True-Ups Proactively: Don’t treat the EA true-up as a passive annual task. A quarter before it’s due, start collating data on license usage. True-up time is also negotiation time – if you’ve optimized and reduced needs, you may negotiate to reduce some commitments, or if you increased, plan how to cover it in the most cost-effective way (maybe converting some perpetual licenses to subscriptions, etc., if that makes sense).
- Budget Cushion for Growth: Even with tight management, virtualization means someone could deploy a bunch of new VMs quickly. Have a small “buffer” of spare SQL licenses or budget allocation to immediately cover any surprise deployments without panic. Ideally, maintain at least 10-15% extra capacity in licenses or be ready to spin certain workloads down if needed.
- Audit After Big Changes: If you make a major environment change (like a data center migration, cluster re-design, or cloud integration), perform a mini-license audit of that new state. Ensure all new placements of SQL Server are correctly licensed, and all old ones have been retired from the license count. Catching issues right after a change is a better practice than months later.
- Document License Assignments in Virtual Context: Because virtualization is fluid, maintain a record (could be monthly snapshots) of how licenses are allocated. For instance: “As of Q1, Hosts 1,2,3 are fully licensed with Enterprise+SA covering X VMs. Host4 has 2 SQL VMs licensed per-VM with SA, etc.” This running documentation will help immensely if ever audited, to explain your strategy clearly to auditors.
