From 1 November 2019, Software Assurance on SQL Server started covering three additional instances rather than one — including a disaster recovery instance in Azure. It is worth money, but only if you can prove which SQL versions and editions you actually run.
Microsoft made a change to SQL Server licensing that, if you have the right insight into your SQL environment, can save you a meaningful amount of money. But only if you have the right data.
As of 1 November 2019, Microsoft Product Terms changed how fail-over instances of SQL Server are licensed. For every SQL workload licensed with active Software Assurance you can deploy:
In Microsoft’s words at the time:
Today, we are enhancing the existing Software Assurance benefits for SQL Server which further helps customers implement a holistic business continuity plan with SQL Server. Starting Nov 1st, every Software Assurance customer of SQL Server will be able to use three enhanced benefits for any SQL Server release that is still supported by Microsoft.
Before this, the benefit stretched to a single passive secondary. Three covered instances instead of one is a material change to the economics of building a resilient SQL environment — and, as ever, a change worth nothing at all to an organisation that cannot demonstrate what it is entitled to.
Why did Microsoft do it? The disaster recovery instance hosted in Azure is the tell. Making the resilient configuration cheaper specifically when the standby lives in Azure is a competitive move against the other hyperscalers, and it works because it lands on a decision — where to put the DR site — that was previously priced against Azure.
A note on currency. These fail-over benefits have remained in Product Terms since, and the arrangement above has been stable for years. Product Terms are nonetheless revised on a regular cycle, and the current edition is always the authority — not a summary of it, including this one. Check the version in force before you plan a deployment around it.
The change affects organisations that have bought SQL Server licences with active Software Assurance and that may previously have had to licence additional instances for disaster recovery. If you built a high-availability or DR configuration before November 2019 and licensed the standby instances separately, you may be holding licences you no longer need to hold.
Two conditions have to hold for the benefit to apply, and both are worth checking rather than assuming:
If you have licensed SQL Server instances with active Software Assurance and you run a fail-over environment for high availability, disaster recovery or both, the action is to build a current discovery, inventory and Effective Licence Position. That tells you where you hold a surplus, where you have a gap, and which of your existing licences can be redirected to cover new fail-over instances rather than buying more.
The obstacle is usually the data. Getting this right requires knowing, per instance: the SQL Server version, the edition, whether the host is physical or virtual, which cluster it belongs to, how many cores are licensable, and what role the instance actually plays. Many SAM tools cannot resolve SQL editions reliably and apply generic rules to a licence metric that is not generic — which is how organisations end up with an answer that looks authoritative and is wrong in the expensive direction.
That is the part CerteroX SAM is built for. Software recognition resolves against the Software Recognition Database — 3.5 million+ normalised publisher, product and version titles — so an instance is identified down to edition rather than to “SQL Server”. Hardware configuration is inventoried alongside it, because SQL licensing turns on processor and core detail, not on an application list. Microsoft server licensing is modelled directly: SQL Server and Windows Server core and processor licensing, with cluster and virtualisation awareness, alongside device CALs, user CALs, named user and external connectors. And the resulting position is maintained continuously, so when the next Product Terms revision changes the arithmetic you are not commissioning a project to find out what it did to you.
If you are not certain what SQL versions and editions you have deployed, or how they are currently licensed, that is the thing to fix first. The benefit is worth having. You just have to be able to prove you qualify for it.
Talk to us about your Microsoft position, or book a demo to see the SQL picture built from inventory rather than from a spreadsheet.
Other posts covering the same ground.
An Oracle Unlimited Licence Agreement is only unlimited within its clauses. What certification actually asks of you, where toxic consumption creeps in, and why the measurement work has to start at the beginning of the term rather than the last six months.
Microsoft's August 2025 Product Terms changes: Extended Term standardised across programmes, Exchange and Skype for Business Server Subscription Editions, the Exchange and Windows 10 ESU programmes, and the Dynamics 365 F&O enforcement dates.
Renew, rescope or exit — an Oracle ULA gives you three routes and a narrow window to choose between them. The questions to settle first, and a six-point health check to see how ready you actually are.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.