SQL Server: when is a replica truly passive?

A secondary SQL Server is waiting for the primary to fail. The administrator moves backups onto it, an analyst adds a regular report, and operations documentation still calls the server passive. The first change may fall within expressly permitted maintenance. The second makes it a server delivering SQL data to users. Both technical diagrams can still label it “secondary”.

Passive failover rights do not provide a free second production SQL Server. The primary workload's entitlements, the replica's purpose and behaviour, its size and the applicable agreement determine coverage. Reporting from a read-only replica actively uses data, even if nobody writes to it.

Content reviewed on 21 October 2026. This article uses SQL Server 2025 Commercial Licensing guidance and current Product Terms for the Microsoft Customer Agreement. A different agreement, OEM, hosting programme or older licence may require a different assessment. Models are hypothetical and do not replace an inventory of a particular cluster.

Secondary and passive mean different things

The technical term secondary describes a role in a replication solution. Licensing passivity under the SQL Server guidance means that the replica does not serve SQL data to clients or run active SQL workloads. Read-only mode is therefore not automatically passive.

A BI query, regular analyst export or application read from the replica is not waiting for a failure. Conversely, a running database process and ongoing synchronisation do not themselves establish a separately licensed active reporting server. Distinguish actual activity from the mere state of being powered on.

For each replica, record its purpose, replication mode, failover capabilities, scheduled tasks and actual client access. Check an owner's assertion that “nobody connects here” against reporting connection strings and scheduled jobs. A forgotten regular export can change the assessment.

What SA and subscriptions add

Current SQL Server Product Terms for MCA distinguish one failover OSE for any purpose including high availability, and two additional OSEs specifically for disaster recovery, for each primary workload. One DR OSE is on an eligible server; the other is on Microsoft Azure under the stated conditions, including the ratio of qualified licences to Azure vCores.

An OSE is an operating system environment, such as the OS inside a particular VM. Entitlement is not derived solely from physical host counts or database counts in a diagram. The primary workload needs correct coverage, and additional failover environments must satisfy their category's conditions.

The Product Terms require Software Assurance for the licensed server and CALs, if any. Subscription licences receive equivalent SA rights for their subscription term. A perpetual licence without these rights does not create the described failover benefit. When coverage expires, the change is more than a billing entry: the original use-rights design is no longer substantiated.

The terms also expressly exclude these failover rights when deploying under License Mobility through SA. Do not confuse that specific deployment benefit at a provider with every VM movement between your own servers. For outsourcing and shared infrastructure, check the agreement route before transferring an on-premises calculation to a hosting quotation.

Backups and CheckDB are not reporting

The Product Terms name permitted maintenance operations for an eligible failover OSE: database consistency checks / CheckDB, log backups, full backups and monitoring resource usage. These exceptions explain why “any job requires an active licence” is wrong. They do not create a general exception for all queries or ETL jobs.

The job's actual output matters. A job named “health check” that produces a business report is not justified by its name. For each exception, document its purpose and relationship to a specifically permitted operation, rather than only the job creator's approval.

Backup capability also depends on version

Licensing permission for maintenance does not establish that a backup command works on every secondary replica. The availability group secondary backup guide distinguishes supported backup types and topology. For older versions it describes copy-only full backups; SQL Server 2025 adds support for ordinary full and differential backups on secondary replicas.

The guide also notes that backups in a distributed availability group are not universally supported on every secondary replica of a secondary group. Communication with the global primary matters. Specify version, edition, role and topology, rather than only saying “we use Always On”.

An availability group's backup preference guides job placement; it does not establish a completed, recoverable backup. Check job placement, actual output and subsequent restoration. A correct licensing calculation does not repair a broken backup plan, and a technically successful backup does not prove licensing coverage.

A larger passive replica may not be covered

Product Terms cap the licences otherwise required for a failover OSE at the number required for the corresponding primary workload. Calling a substantially larger environment “reserve capacity” is insufficient. Assess licensing requirements under the applicable model, rather than CPU utilisation percentages alone.

Hypothetical example: a company licenses individual Enterprise VMs by virtual cores with active SA. Each vCore maps to one hardware thread, the four-core minimum per VM is satisfied, and the company is not using unlimited virtualisation for an entire host. The primary VM has 8 vCores. Azure and operating-system costs are excluded.

Active P and R need 8 + 4 = 12 core licences, or six two-core packs. H and D are not unconditional free servers: their coverage depends on the substantiated benefit, passivity and relationship to primary P. The model does not add SQL CALs because it uses per-core licensing, but it does not cover other products.

If D had twelve rather than 8 vCores with the same mapping, its full twelve-licence requirement could not be treated as covered by an eight-core primary workload. Adjust its size or the design and confirm the target configuration's entitlements. Do not automatically subtract eight from twelve and present the remainder as a universal rule for this benefit.

Reporting on the DR copy changes the design

Move reporting from R to D in the previous model and remove R from operation. D now serves business reads, so the previous passive DR conclusion no longer applies. Active P and D require 8 + 8 = 16 core licences under the stated per-VM model. Combining technical functions does not necessarily reduce licensing requirements.

This is not automatic advice to move four existing licences or buy precisely four additional rights without further checks. Assignment and location changes have their own rules. The example compares required coverage for two designs with the same business need, rather than bypassing how those rights apply over time.

Our SQL Server in a VM: when is SA required? explains base models and minimum counts. Select those before adding HA and DR rights. For a host cluster, also assess Windows Server cluster licensing. A SQL benefit does not automatically cover the operating system.

Recovery testing differs from an actual outage

Product Terms permit the primary workload and DR failover OSEs to run together for brief DR testing periods every 90 days. This does not authorise permanent parallel reporting or all-day tests at any chosen interval. Document purpose, start, end and restoration of the original state. The specific wording does not establish a universal number of hours for every test.

During an actual takeover, “P active, D waiting” stops being an accurate description. Record changed roles and subsequent operation, including client connection strings and eventual failback. Update records even when VM names remain unchanged.

Checks before confirming a design

1. Establish each primary workload's version, edition, agreement programme and licensing model.
2. Document active SA or equivalent subscription rights; verify CAL coverage under Server/CAL too.
3. Map each additional OSE to a particular HA or DR category, rather than a general secondary label.
4. Check its licensing size, replication mode and failover method.
5. Review client connections and jobs. Separate expressly listed maintenance from reporting and exports.
6. Verify backup support for the version and topology, and perform a restoration test.
7. Document the procedure for role changes, workload expansion, hosting changes and SA expiry.