Azure Hybrid Benefit for SQL Server: The Rules That Decide the Saving
Azure Hybrid Benefit lets you bring SQL Server licences you already own to Azure and pay the base compute rate instead of the licence-included rate. On paper it is the largest single discount Microsoft offers for SQL Server in the cloud. In practice the saving depends on rules about which licences qualify, how cores convert between editions and services, and what happens to the on-premises deployment the licence came from. Get those wrong and the benefit is a compliance finding with a discount attached.
Here are the rules as they stand, the conversion arithmetic, and the questions to answer before you switch a deployment to the benefit.
What qualifies
- SQL Server Standard or Enterprise core licences with active Software Assurance, or the equivalent subscription licences. Licences without SA do not qualify, and SA that lapses ends the benefit on that licence.
- Per-core licences only. Server + CAL licences cannot be used for Azure Hybrid Benefit on SQL Server.
- An Enterprise Agreement, MPSA, or CSP subscription as the channel. The rights are set out in the Product Terms, and the Product Terms move; the version in force on the day you assign the licence is the one that counts.
The conversion arithmetic
The benefit is not one licence for one core. The exchange rates differ by the edition you own and the Azure service you land on:
| You own | On Azure SQL Database or Managed Instance | On SQL Server in an Azure VM |
|---|---|---|
| 1 Enterprise Edition core (with SA) | 4 vCores of General Purpose, or 1 vCore of Business Critical | 1 core of Enterprise, or (for Standard) 1 core of Standard |
| 1 Standard Edition core (with SA) | 1 vCore of General Purpose | 1 core of Standard |
| Minimums | 4 vCores per database or instance | 4 cores per VM, or the licence minimum for the SKU |
The Enterprise-to-General-Purpose ratio of one to four is the number that makes the benefit valuable, and also the number most often applied to licences that do not qualify for it. It applies on the platform services, not on SQL Server running inside a virtual machine. The same 64 Enterprise cores buy 256 General Purpose vCores of Managed Instance or 64 cores of SQL Server in VMs.
Dual use: the 180 days
A licence assigned to Azure under the benefit is, for the purpose of migration, allowed to keep running on premises for 180 days. After that the on-premises deployment must be decommissioned or separately licensed. This is the rule that produces the largest findings: the migration slips, the old server keeps serving reports, and eighteen months later both deployments are running on one licence. The 180 days are counted from assignment, not from the day the cloud workload went live.
Unlimited virtualisation is a different right
Enterprise Edition with SA carries unlimited virtualisation on premises: license all physical cores of a host and run any number of SQL Server VMs on it. That right does not travel to Azure as such. On Azure Dedicated Host you may apply it to the host's physical cores; on shared Azure infrastructure each VM is licensed on its own vCores. Teams that price the move from a heavily virtualised on-premises host to individual Azure VMs on the same licence count are surprised twice: once by the core count, once by the audit.
Passive failover and the benefit
Software Assurance grants one passive failover instance for high availability, one for disaster recovery, and one for disaster recovery in Azure, none of them requiring additional licences while they remain passive. When the primary moves to Azure under the benefit, those failover rights move with the licence, and an on-premises secondary that is genuinely passive can remain. A secondary that serves read traffic or backups beyond what the terms allow is active and needs its own licences.
Working out whether the benefit pays
- Count the qualifying cores: per-core, with SA active at the date of assignment, by edition.
- Decide the landing service per workload, because the exchange rate depends on it. A lift-and-shift to VMs converts one to one; a move to Managed Instance General Purpose converts Enterprise cores four to one.
- Subtract what must stay licensed on premises past the 180 days: the systems that will not be migrated, and any active secondaries.
- Compare the residual on-premises position after the move. Licences moved to Azure leave a gap on premises if anything is still running there; that gap is priced at full list plus SA.
- Fix the SA renewal date in the plan. The benefit lasts as long as the SA does. A benefit assigned in year three of a three-year EA needs a renewal decision baked in.
The record you will need
Microsoft asks customers using the benefit to keep records of the licences assigned, the deployments they cover and the dates. The Azure portal's own attestation is a checkbox, not a licence record. A position that survives a Microsoft review lists every SQL Server deployment, cloud and on-premises, against the licence covering it, with the assignment date, the SA expiry, and the conversion applied. That is the reconciliation Microsoft Deployment Manager maintains from your inventory and your entitlements, and the reason the benefit works in one estate and becomes a finding in the next is almost never the rules; it is whether anyone kept the record.
The Azure Hybrid Benefit is a genuine saving when the licences qualify, the exchange rate matches the service, and the on-premises side is cleaned up inside the 180 days. Treat it as a licence assignment with a discount, not as a discount with a licence assignment, and the numbers hold.
