Avoiding Common Compliance Pitfalls in SQL Server Licensing: Core Counts, Virtualisation, and Audit Risks

Why SQL Server Licensing Generates Compliance Exposure

SQL Server's licensing rules are designed around physical infrastructure, but most enterprise deployments now run in virtualised environments where the mapping between software instances and physical hardware is indirect, dynamic, and difficult to track. The licensing rules have evolved to accommodate virtualisation, but the evolution created layers of complexity — different rules for Enterprise and Standard editions, different rights for SA versus non-SA customers, different treatments of passive versus active high availability replicas — that generate systematic compliance gaps in organisations without dedicated SQL Server licensing expertise.

Microsoft's SAM review programme increasingly targets SQL Server because the density of compliance errors is high and the financial exposure per error is significant. A single SQL Server Enterprise edition instance licensed under an incorrect model can represent tens of thousands of dollars in under-licensing. When Microsoft discovers errors across multiple instances in a SAM review, the cumulative back-licence demand can reach hundreds of thousands of dollars for mid-sized enterprise deployments.

Pitfall 1: Core Counting Errors in Physical Environments

SQL Server's per-core licensing model requires licences for every physical processor core in the server where SQL Server is installed, with a minimum of four core licences per physical processor. Core licences are sold in two-packs. An eight-core, dual-socket server running SQL Server requires a minimum of 16 core licences — two four-core minimums would apply to each socket, but the actual eight physical cores per socket are what must be counted.

The most common physical environment error is miscounting hyper-threaded logical processors as physical cores. SQL Server licensing counts physical cores, not logical processors. A processor with 12 physical cores and 24 logical threads (via hyper-threading) requires 12 core licences, not 24. This error, when made in the wrong direction — counting logical processors instead of physical cores — results in over-licensing, which wastes spend but does not create compliance risk. The dangerous error is undercounting: assuming that only the cores being utilised by SQL Server at any moment require licences, rather than all physical cores in the processor.

Pitfall 2: Virtualisation Licensing Mistakes

Virtualisation is the single largest source of SQL Server compliance exposure in enterprise environments. The fundamental principle is straightforward: you must licence every virtual machine (VM) running SQL Server, not just the physical host. However, the mechanics of how virtual licensing works, and when host-level licensing becomes advantageous, generate consistent errors.

The Per-VM Core Minimum

When licensing SQL Server per virtual machine rather than per physical host, the minimum requirement is four core licences per VM, regardless of how few virtual CPUs (vCPUs) the VM is assigned. A SQL Server Standard VM configured with 2 vCPUs still requires 4 core licences. A VM reconfigured to increase its vCPU count must have its licence count updated to match. In dynamic infrastructure environments where VM sizing changes frequently, licence count updates must track VM configuration changes in real time. This is one of the most common audit findings in current Microsoft SAM reviews: VM vCPU counts have been increased for performance reasons but SQL Server licence counts were not updated to match.

Unlimited Virtualisation Rights and Software Assurance

SQL Server Enterprise edition customers with active Software Assurance have a significant virtualisation benefit: the right to run unlimited SQL Server VMs on a fully licensed host, provided every physical core in the host is covered by Enterprise edition core licences with SA. This is the unlimited virtualisation right. Without SA, this benefit does not apply — the customer must licence each VM individually, which may be far more expensive for a heavily consolidated SQL Server estate.

The most common error in this area is assuming that the unlimited virtualisation right applies without verifying that SA is current on all core licences for the host. An SA lapse on any portion of the host's core licences invalidates the unlimited virtualisation entitlement for that host, requiring per-VM licensing for every instance running on it. Organisations with large SQL Server estates on Enterprise edition must actively manage SA renewal to preserve this critical benefit.

Live Migration and Dynamic VM Placement

When VMs are live-migrated between physical hosts — as routinely happens in VMware vSphere HA, Microsoft Hyper-V with Live Migration, or Nutanix AHV — the SQL Server instance temporarily exists simultaneously on two physical hosts. The licences move with the VM, but the source host must be covered for the duration of the migration window. Under Microsoft's 90-day movement rule, an organisation may move a licenced workload to a different server and may not move it again for 90 days, unless the movement is a result of a physical hardware failure (in which case movement is unrestricted). High-frequency live migration in VMware or Hyper-V DRS environments can violate this rule if the licence management process does not account for the movement constraint.

Pitfall 3: High Availability and Failover Misconfiguration

SQL Server includes specific licence provisions for passive (standby) replicas used exclusively for failover purposes. Under these provisions, a secondary SQL Server instance that is configured as a passive failover replica — one that cannot serve any queries or connections until a failover event — does not require a separate SQL Server licence. This is the failover exception. It is widely used and frequently misconfigured.

The Readable Secondary Problem

SQL Server Always On Availability Groups support a configuration called readable secondaries, which allows the secondary replica to serve read-only queries while still providing failover protection. This is a popular configuration because it offloads reporting and analytics workloads from the primary replica, improving overall system performance. However, the moment a secondary replica is configured as readable, it becomes an active SQL Server instance and loses the passive failover licence exception. It requires a full SQL Server licence — the same core count as if it were a standalone instance.

This is the most common high availability compliance failure in the current Microsoft SAM review cycle. Organisations that configure Always On with readable secondaries and treat those secondaries as passive instances for licensing purposes are systematically under-licensed. Microsoft's audit tools detect Always On configuration and compare the number of replicas against the licence entitlement for each endpoint. The gap between readable secondaries and licenced instances is a direct and quantifiable compliance finding.

Log Shipping and Database Mirroring

Similar passive/active distinctions apply to log shipping and database mirroring configurations. A log shipping secondary that is maintained in a restoring state, inaccessible to users, qualifies for the passive exception. A secondary that is brought online for reporting — even periodically — loses the exception and requires a full licence for the periods it is active. Policies that periodically bring log shipping secondaries online for data refresh or reporting, without maintaining separate licence coverage for those active periods, represent compliance exposure.

Pitfall 4: The CAL Model Growth Trap

SQL Server Standard edition can be licensed under either the per-core model or the Server plus Client Access Licence (CAL) model. The Server plus CAL model uses a single server licence plus individual CALs for each user or device that accesses SQL Server. For small deployments with a defined, manageable user base, the Server plus CAL model can be highly cost-effective — particularly where the per-core cost for a large server would significantly exceed the combined server plus CAL cost for a small number of users.

The growth trap occurs when an organisation licences SQL Server on the Server plus CAL model for a 50-user deployment and then the application grows to serve 500 or 1,000 users without triggering a licence model review. Each new user accessing the SQL Server requires a CAL. Organisations that deploy web applications, portals, or self-service tools that expand the SQL Server user base without purchasing corresponding CALs create compliance exposure proportional to the number of unlicensed access points.

The internet connector provision provides some relief — a single internet connector licence allows unrestricted anonymous internet user access to SQL Server Standard — but this applies only to anonymous internet access, not authenticated internal users. For organisations with large internal user populations or authenticated web applications, the per-core model is almost always more cost-effective and compliance-safe than attempting to manage large-scale CAL programmes.

Pitfall 5: Software Assurance as a Feature Key

Software Assurance (SA) on SQL Server licences has evolved from a maintenance and support subscription into a prerequisite for key architectural features. Without active SA, SQL Server Enterprise customers lose the unlimited virtualisation right discussed above. They also lose licence mobility rights (the ability to redeploy licences to alternative servers within server farms without the 90-day restriction), the right to run SQL Server on shared infrastructure in service provider environments, and access to new version rights that allow deployment of the latest SQL Server version under an older version's licence.

Many organisations allow SA to lapse on SQL Server licences when budget pressure requires cost reduction in the software maintenance budget. The immediate financial saving is real — SA on Enterprise core licences represents a substantial annual cost. However, the functional and compliance consequences of lapsed SA can far exceed the maintenance saving, particularly for organisations with heavily virtualised SQL Server estates that rely on the unlimited virtualisation right.

Six Priority Actions for SQL Server Compliance

1. Conduct a Full SQL Server Discovery: Identify every SQL Server instance across physical servers, VMs, containers, and cloud environments. Unmanaged instances — deployed by application teams or DBAs outside the central IT governance process — are the most common source of unlicensed deployments.

2. Map Instances to Licences: For each discovered instance, identify the licence entitlement covering it: edition, version, core count, and SA status. Reconcile this mapping against the organisation's Microsoft volume licensing portal records.

3. Audit Always On Availability Group Configurations: For every Always On deployment, verify whether secondary replicas are configured as readable or passive-only. Readable secondaries require full licence coverage. Update licence counts or reconfigure replicas to passive status where the licence coverage does not support readable secondary operation.

4. Review VM vCPU Counts Against Licence Assignments: Pull the current vCPU configuration for every SQL Server VM and compare against the core licence count assigned to it. Update licence counts where VM configurations have changed without corresponding licence adjustment.

5. Verify SA Status on Enterprise Licences: Confirm that SA is current on every SQL Server Enterprise core licence being used to support unlimited virtualisation rights or licence mobility. Create calendar reminders for SA renewal dates and treat SA renewal as a compliance-critical event.

6. Evaluate Per-Core Versus CAL Model as User Base Grows: If SQL Server Standard is currently licensed on the Server plus CAL model, model the per-core cost against the current and projected user base. Where the user base has grown substantially since the CAL model was adopted, migration to per-core licensing may be both more cost-effective and compliance-safe.