SQL Server in a VM: when is SA required?

The direct answer: Licensing an individual virtual operating system environment (OSE) by virtual cores requires a subscription or active Software Assurance. For a fixed Standard instance under Server/CAL, the Product Terms used here do not make virtual deployment itself conditional on SA. Mobility, failover and client access introduce further requirements. An OSE is an operating system environment, such as the OS inside a particular VM. This article covers SQL Server 2025 under Commercial Licensing and the Microsoft Customer Agreement Product Terms checked on 12 October 2026. Check the actual agreement for other versions, OEM products or programmes.

Why two answers can appear correct

In a SQL VM licensing discussion, an administrator received conflicting advice from two suppliers. The thread includes disagreement and a later correction. A Microsoft Q&A question from May 2026 describes two VMs and 100 clients. Its accepted answer emphasises mobility, but an order needs a more precise breakdown.

One answer may concern virtual cores, another a server licence plus CALs. Someone else may assume a cluster even though the deployment has one fixed host. Before comparing prices, write down the model being purchased, the physical server to which rights are assigned and every place the workload may run. The vCPU count alone cannot describe that.

Choose the model before doing the arithmetic

Microsoft’s product licensing overview distinguishes per-core from Server/CAL. Standard offers both; Enterprise is normally licensed per-core. A SQL CAL grants access rights rather than supplying an installation key. Counting connections in SQL Management Studio is therefore not a licensing inventory.

This table checks a design; it is not a list of interchangeable products. A quote should identify the SKU, version, model and SA or subscription scope. Without the model, the amount cannot establish whether the offer covers the intended operation.

Apply the minimum to each VM

Under the current SQL Server Product Terms, individual virtual OSE per-core licensing is available only with subscription rights or active SA. Count virtual cores, subject to at least four licences per OSE. Mapping a virtual core to multiple hardware threads can increase the requirement. Record physical processors, virtual cores and sales packs as separate quantities.

Hypothetical example, not a quote: Two separate VMs have two and six vCPUs. With ordinary mapping, the first requires four core licences and the second six: ten altogether. Adding 2 + 6 to obtain eight ignores the per-VM minimum. Nor does one four-core entitlement cover both VMs because the smaller one sometimes has little work to do.

The SQL 2025 guidance identifies core SKUs as two-core packs. Ten core licences in this example therefore correspond to five packs. Check the unit in the quote: “5 items” might mean ten core licences or an entirely different product. The unit belongs beside the quantity.

Do not infer Standard VM rights merely from licensing every physical core of the host. The current guidance distinguishes Standard and Enterprise rights under physical per-core licensing. Changing the counting method can also change the permitted deployment.

Server/CAL permits a VM, not unlimited instances

The SQL 2025 Product Terms used here permit one running instance in a physical or virtual OSE for each Server/CAL server licence. First record the instances and the physical host to which rights are assigned. Wording in a guide for an older SQL version does not establish SQL 2025 rights.

Hypothetical example: Two fixed VMs each contain one running SQL Standard instance. Their ERP serves 100 identified employees, each with an appropriate-version SQL User CAL. The base inventory is two server licences and 100 User CALs. Do not automatically multiply those CALs by two merely because there are two SQL servers: an assigned CAL permits access to the customer’s corresponding licensed servers. Other users, devices or automated access can change the inventory.

That example does not establish mobility, standby rights or access to future versions. It describes basic operation. Add separate lines for maintenance and failure scenarios rather than assuming they are included.

One ERP login does not replace employees’ CALs

Microsoft’s multiplexing guidance addresses intermediary access. Employees reading or writing SQL data through an ERP or web app do not become one licensed user because the app uses a common database account. Trace the data path to its end users.

Record paths such as salesperson → ERP → application server → SQL; analyst → automatically refreshed report → SQL; integration device → API → SQL. Inventory the users or devices needing rights under the selected model, rather than the entries in a SQL login list. For automation, identify both the source and the recipients of the data.

Microsoft distinguishes some manual transfers from automated distribution. A file extension cannot settle that question: a person emailing a static Excel file without a live connection differs from a report automatically refreshed from SQL. Diagram ambiguous integrations before choosing Server/CAL. Correct per-core coverage removes the SQL CAL requirement, but not separate Windows Server or application rights.

VM movement is a separate decision

Licences are assigned to a physical server. The SQL 2025 guidance describes a general minimum of 90 days between reassignments, with qualified SA or subscription rights allowing frequent movement within a server farm. Disabling automatic balancing does not settle the issue if administrators still migrate VMs during every maintenance window.

For Server/CAL, the current mobility condition also requires appropriate subscriptions or active SA for the CALs used to access the software. Check server and client rights together. “Does the server have SA?” is an incomplete question.

Equally, movement without SA is not automatically prohibited in every design. The destination may already have sufficient independent coverage, or another applicable contractual provision may apply. Assess the complete setup. Ask the partner: “How is this instance covered on every possible host, and which rights apply when it moves?”

Prepare an order that another administrator can review

1. Topology. Physical hosts, VMs, running instances, vCPUs and possible movement; include separately deployed SQL components.
2. Access map. Direct users, devices, ERP, reports and integrations. For Server/CAL, record assignments and CAL versions.
3. Failure operation. Primary and standby locations, what the standby actually does, and the failover entitlement being used. Do not classify a reporting server as passive without checking.
4. Licensing evidence. SKU, programme, purchase date, SA or subscription term and scope, and quantity units.
5. Comparable alternatives. Compare Server/CAL and per-core quotes for the same topology, users and availability requirements.

The result is a document another administrator can inspect without reconstructing an earlier conversation. It also prevents the partner having to guess what “one SQL server” means. Assign ownership of the evidence and topology reviews within your wider Microsoft licensing governance.