SQL Server licensing compliance in 2026. The eight pitfalls behind most audit findings.

Most SQL Server audit findings trace back to eight rules: core minimums, virtualization rights, passive failover, Azure Hybrid Benefit, license mobility, dev and test use, edition features and CALs. Most of them depend on active Software Assurance.

Why is SQL Server the Microsoft product auditors check most?

SQL Server draws more audit attention than any other Microsoft product because it combines high spend with rules that are easy to break by accident. The number of deployments rarely matches the entitlement record, and almost every review we run finds gaps once a company passes 50 cores.

For the audit process itself, read our Microsoft audit defense guide. For the commercial side, see the Microsoft vendor management toolkit, our Microsoft advisory practice and our notes on EA discount negotiation.

Three reasons SQL Server draws audit attention

• High value. In the Microsoft accounts we review, SQL Server makes up 18 to 26 percent of enterprise spend.
• A complex metric. Core counting, virtualization rights and passive failover each carry edge cases that produce findings.
• Constant change. Cloud migration, version upgrades and consolidation change what must be licensed, and the license record lags behind.

How do you count SQL Server cores correctly?

Count physical cores when you license the server and virtual cores when you license the VM. Licenses come in two core packs, with a minimum of four core licenses per physical processor or per virtual machine.

Most errors come from mixing those two bases. Counting hardware threads on physical servers wastes money, and counting small VMs below the minimum produces a finding.

Four core counting rules

1. License all physical cores when licensing per physical processor. Standard Edition 2022 uses at most 24 cores (32 in SQL Server 2025), yet a 48 core host running Standard on physical hardware still needs 48 core licenses.
2. Minimum four cores per VM. This applies even if the VM has fewer vCPUs assigned.
3. Two core packs. Licenses are sold in even pairs only.
4. Hyperthreading does not change the physical count. Inside a VM, each vCPU needs one core license whether it maps to a core or a thread.

How do SQL Server virtualization rules differ by edition and Software Assurance?

Only Enterprise Edition with Software Assurance (SA) or subscription licenses gets unlimited virtualization. Everything else is licensed VM by VM or capped by the host's core count. Virtualization is the largest single source of SQL Server audit findings.

SQL Server 2022 also tightened the per VM rule. Licensing an individual VM now needs active SA or subscription licenses. Perpetual licenses without SA can still be assigned per VM only for SQL Server 2019 and earlier.

Why clusters create the biggest findings

Without SA, a license can be reassigned to another server only once every 90 days. A SQL VM that migrates between hosts more often needs licenses on every host it can reach, which is why auditors ask you to license the whole VMware or Hyper-V cluster.

When is a passive SQL Server failover instance free?

A passive secondary is free only while the primary has active SA and the secondary does no production work. Many companies drop SA at a renewal and keep running the same secondaries, which from that date are licensable at the primary's edition.

Four passive failover rules

• The primary must hold active SA. The benefit ends the day SA expires.
• The passive instance must stay passive. No serving data, no reports, no read workloads. Consistency checks, full and log backups, and resource monitoring are permitted.
• Free secondaries are capped. SA covers one passive for high availability and one for disaster recovery on premises, plus one for disaster recovery in Azure, each with no more compute than the primary. Any further secondary is licensable.
• Running both as active is time limited. After a failover the roles swap and the old primary must become the passive. Both may run as active together only for brief disaster recovery tests, once every 90 days.

How does Azure Hybrid Benefit work for SQL Server licenses?

Azure Hybrid Benefit applies SQL Server licenses with SA, or subscription licenses, to Azure SQL so you pay the Azure rate without the license component. Without it you pay for SQL Server twice, once in the licenses you own and again in the Azure price, which doubles license cost in many configurations.

Where Hybrid Benefit goes wrong

Some teams never switch the benefit on, so Azure bills the license while owned licenses sit idle. Others switch it on for more cores than their SA covers, which is a finding of its own.

During a migration you get 180 days of dual use rights to cover the old server and the Azure workload. Our Azure Hybrid Benefit guide covers Windows Server too.

What happens when SQL Server Software Assurance lapses?

You keep the perpetual licenses but lose license mobility, the right to reassign them between servers without the 90 day rule. Buyers who drop SA to cut the renewal then trigger a relicensing event with every workload migration, and only permanent hardware failure is exempt.

When SA expiry triggers relicensing

• Server consolidation projects. Shifting SQL workloads between servers.
• Disaster recovery testing. Running workloads at the DR site.
• Cloud migration. Shifting SQL workloads to Azure, AWS or GCP.
• VM patching cycles. Migrating VMs between hosts during maintenance.

Why we do not recommend dropping SQL Server SA across the board

A common piece of renewal advice says SA on SQL Server can go because the perpetual licenses keep working. For most companies we disagree. SA also carries passive failover, per VM licensing on SQL Server 2022 and Azure Hybrid Benefit, so removing it changes what you must license the day it lapses.

Sort workloads before the renewal instead. Keep SA on anything clustered, replicated, bound for Azure or licensed per VM, and drop it only on stable physical servers with no failover partner or migration plan. Our Software Assurance guide lists the full set of benefits.

How should SQL Server development and test environments be licensed?

Dev and test environments are licensed separately from production, and production cores cannot be stretched to cover them. Visual Studio subscriptions include SQL Server for development by named users, and the free Developer editions cover dev and test servers.

Five rules for dev and test SQL Server

1. Visual Studio subscriptions cover named developer use. One subscription for each person who uses the software.
2. Load testing needs Visual Studio Enterprise. Its subscribers can run load tests with any number of virtual users, though a production server under test still needs production licenses.
3. Free Developer editions exist. SQL Server 2025 ships Enterprise Developer and Standard Developer, both licensed for dev and test only.
4. A license covers one server. Cores assigned to a production server do not also cover a separate test copy, and developer rights never cover production.
5. Some pre production counts as production. An environment that connects to a production database, backs up or stands in for production, or serves end users beyond acceptance testing needs production licenses. User acceptance testing that uses no live production data can stay on dev rights.

Which SQL Server features require Enterprise Edition?

Online index operations, full Always On availability groups and compute beyond the Standard caps require Enterprise Edition. Several features older checklists still call Enterprise only moved to Standard years ago: data compression and table partitioning with SQL Server 2016 SP1, and transparent data encryption with SQL Server 2019.

The Standard engine refuses most Enterprise only operations, so the usual finding is about what is installed. Enterprise binaries reach a server licensed for Standard through a build template, an application installer or copied media. Once an Enterprise feature is in use there, the fix is a true up to Enterprise Edition.

When does the SQL Server Server plus CAL model still apply?

Server plus CAL is still sold for Standard Edition only, and it mostly appears on legacy contracts. New deployments almost always use the per core model. Mixing the two metrics on one deployment is not allowed.

Three rules for the CAL model

• A server license plus a CAL per user or device. Count every user with access, including those who reach the database through an application or pooling layer.
• External users are licensable. Web facing access needs per core licensing or another metric.
• No mixing on one server. Per core or Server plus CAL, never both.

At Microsoft's open prices, a Standard server license costs $989 and a CAL $230. An eight core server licensed per core needs four packs at $3,945, or $15,780, so Server plus CAL wins below about 64 users. One CAL covers access to any number of licensed servers, which improves the CAL case across several servers.

What do our SQL Server compliance reviews usually find?

They usually find audit exposure of 8 to 24 percent of annual SQL spend on a typical enterprise SQL Server footprint. The eight pitfalls above account for about 90 percent of that risk, and fixing all eight keeps an audit result within a range most budgets can absorb.

Each review runs four to eight weeks. We pull the deployment inventory, entitlement record and configuration data, then build the effective license position, a value for the audit risk and a remediation plan before any Microsoft audit or renewal.

Many SQL Server findings come from rights that lapsed at a renewal while the servers kept running exactly as before.

A worked example at list price

Say a review of a hypothetical company finds three gaps, priced here at Microsoft's open list prices for SQL Server 2025. Your agreement and any settlement will change the final figure.

On $1.5 million of annual SQL spend, that is close to 15 percent. Renewing SA before it lapsed would have prevented the second line, because SA generally cannot be added back to existing licenses afterward. The Standard cores freed by the third fix can be reassigned elsewhere.

How can you check your own SQL Server licensing position?

Most of the evidence an auditor wants comes from tools you already run. Pull it per instance, then match it to your Volume Licensing entitlements, which now sit in the Microsoft 365 admin center.

What will Microsoft's auditors say, and how should you answer?

Auditors work from the data you hand over and tend to apply the most expensive reading of the rules. These four lines come up most often.

• "Every host in the cluster must be licensed." That holds for per host licensing or VMs that break the 90 day rule. Show mandatory (must run) affinity rules, since preferred rules can be overridden, plus per VM licenses with SA, and limit the finding to hosts SQL VMs can reach.
• "Your secondary replica is active." Ask for evidence of client reads, since backups and consistency checks are permitted. If reads did happen, license that replica only.
• "Enterprise is installed, so these are Enterprise deployments." If sys.dm_db_persisted_sku_features shows no Enterprise features, ask to reinstall Standard within an agreed window. It is a request, not a right.
• "Buy the gap on the new agreement and we will close the audit." Get the final findings and release terms in writing first, and price the settlement apart from new spend.

Our SQL Server audit defense service takes on these conversations with Microsoft and its audit partners.

What to do next

Open this checklist 90 days before any Microsoft renewal or audit. Start six to twelve months out if you expect edition swaps or SA changes, because both need a change window or a budget cycle.

1. Pull the SQL deployment inventory. By server, instance, edition and version.
2. Map the core counts. Physical cores, vCPU assignments and the four core minimum.
3. Audit Software Assurance status. Per license, per environment and per benefit.
4. Inventory virtualization configurations. Per VM, per host and the license model for each cluster.
5. Confirm passive failover compliance. Map each secondary to a primary with active SA.
6. Score Azure Hybrid Benefit use. Every eligible Azure SQL workload should use it, within SA coverage.
7. Separate dev and test from production. Visual Studio subscriptions or the free Developer editions.
8. Validate edition use. Confirm Enterprise features run only on Enterprise Edition. For help, see our Software Spend Assessment, benchmarking, Benchmark Program, Renewal Program and Vendor Shield, read about us, meet the management team, find our locations or contact us.

Frequently asked questions