Most SQL Server architecture decisions in Azure are settled by licensing, and most of them are settled before anyone realises licensing is in the room. What you already own changes the relative cost of these options by multiples rather than percentages, it does so unevenly across the tiers, and it is worth nothing at all on the tier Microsoft now recommends by default. This article is the cost doctrine: what hybrid benefit is actually worth, where the money really goes, and why the argument that used to open every migration deck stopped being true in April 2026.
The exchange rate nobody reads carefully
Azure Hybrid Benefit lets you apply SQL Server licenses you already own, with active Software Assurance or under a subscription, against Azure SQL resources instead of paying the license component in the meter. Everyone knows this. What decides architectures is the exchange rate, and it is not uniform.
One Enterprise core with Software Assurance converts into four vCores of General Purpose, or one vCore of Business Critical. One Standard core converts into one vCore of General Purpose, and it takes four Standard cores to buy a single vCore of Business Critical. Sit with that for a moment, because it is the most commercially significant paragraph in this series. An Enterprise estate with Software Assurance is worth four times as many cores on General Purpose as it is on Business Critical. The same licenses, the same estate, a four-fold difference in what they buy depending on a tier choice that is usually made on technical grounds alone.
The practical doctrine that falls out of this is simple and I apply it almost every time. If the client holds Enterprise with Software Assurance, General Purpose is the default tier and Business Critical needs a performance justification strong enough to be worth surrendering a four-to-one multiplier for. If the client holds Standard, the tier decision is close to licensing-neutral and can be made purely on merit. Getting this the wrong way round, which usually happens when someone specifies Business Critical because it sounds appropriate for production, can quadruple the licensed footprint of an entire migration.
The tier decision and the licensing decision are the same decision. Teams that make them in separate meetings pay for the privilege, usually by a factor of four.
There is a migration allowance worth knowing: a documented dual-use period of a hundred and eighty days during which the same licenses may cover both the source and the target, so you are not paying twice while a migration runs. That is generous and it is finite, and I have seen projects overrun it without anyone tracking the date. Put it in the plan as a milestone, not as a footnote.
Where the benefit does not reach
Three exclusions matter enough to change designs, and the third is the one that catches people out most often now.
The older purchasing model, with its database transaction units, has no hybrid benefit at all, which is one more reason to treat it as legacy. Serverless has none either, in any tier, which means the shape that is cheapest for intermittent workloads is also the shape your existing licenses cannot subsidise. And Hyperscale, on databases created since the simplified pricing change at the end of 2023, has no license component to offset, so hybrid benefit does not apply. Databases created before that change keep the benefit only until December 2026, which is now close enough to plan around rather than to note.
Put that beside the tier advice from earlier in this series and an awkward tension appears. Microsoft’s current guidance names Hyperscale as the recommended and default tier for new and modernising workloads. Hyperscale sits outside the licensing conversation entirely. So an organisation with a large, valuable, Software-Assurance-covered Enterprise estate gets exactly no credit for it on the tier they are being steered towards. That is not a scandal, and the simplified Hyperscale price is lower precisely because the license component was removed, but it does mean the comparison has to be done properly on total cost rather than by assuming that owning licenses always makes the platform cheaper. Sometimes the tier that ignores your licenses still wins. Sometimes it does not. Model it.
Where the money actually goes
Some structural facts about the meters, which are more durable than the rates themselves. Prices move, and everything numeric here should be re-checked against the current pricing feed before it goes in a proposal, but the shapes hold.
General Purpose compute on Azure SQL Database and General Purpose compute on Managed Instance are the same price per vCore hour. Not similar, the same. The choice between the database-scoped service and the instance-scoped one is therefore not a compute-price decision, and anyone presenting it as one is arguing from a number that does not exist. Choose between them on features and dependencies, which is what the earlier articles are about, and the compute bill will be what it will be.
Serverless costs roughly three and a half times as much per vCore hour as provisioned General Purpose, which sounds damning until you remember it bills per second and pauses when idle. The break-even is a duty-cycle calculation, not a rate comparison: below roughly a third utilisation it wins, above it it loses, and for anything running steadily all day it is straightforwardly the wrong choice.
Zone redundancy on General Purpose is not free, and it is more expensive than most people account for, because it lands on two meters rather than one. The compute uplift is about sixty percent. Storage doubles. A design that turns on zone redundancy across a large estate without modelling the storage side will surprise somebody. On Azure SQL Database, Business Critical zone redundancy carries no additional compute cost, which is a genuine and underused property. Do not carry that across to Managed Instance, where zone redundancy is separately billed on both tiers.
Backups are cheaper than people fear. Point-in-time retention storage comes with a free allowance equal to a hundred percent of your maximum data size, so a normally-sized retention window on a normally-sized database frequently costs nothing at all. Long-term retention bills separately, at a substantially lower rate than the point-in-time storage, out to ten years. This is one of the few places in Azure where the responsible choice is also the cheap one.
On a virtual machine, the license is the bill
The infrastructure option has the starkest arithmetic in the family. A mid-sized four-vCPU general-purpose Windows virtual machine costs a little under three hundred dollars a month in a typical region. SQL Server Standard licensed hourly through the marketplace on that same machine costs slightly more than the machine does, so the software is a little over half the total. Enterprise costs about four times the machine, at which point the compute is a rounding error and you are essentially renting SQL Server with a free computer attached.
Two operational consequences follow. Right-sizing is a licensing exercise: every core you provision is billed twice, once as compute and once as software, and the second charge is the larger one. And there is a four-core minimum on the license, so shrinking a machine below four vCPUs reduces the compute bill and does nothing whatsoever to the license bill. Fleets of small two-core database servers are consistently the biggest saving I find on an Azure estate, because consolidating them recovers licensing that was being wasted on a floor nobody knew about.
Against that, the passive replica rights are genuinely valuable and routinely forgotten. Licenses with Software Assurance carry the right to a free passive replica for high availability and a further free passive for disaster recovery, provided the replicas sit in Azure, and equivalent rights are available on pay-as-you-go machines through a dedicated license type on the extension. A three-node availability group licensed naively costs three times what it should. The managed services have their own version of this: a failover group can designate its geo-secondary as a standby whose license vCores are free, with only storage billing. Nobody switches these on by accident.
Commitments: reservations, and the savings plan with a catch
Reservations cover compute on Azure SQL Database and Managed Instance for one or three years. They do not cover the older purchasing model, they do not cover serverless, and they do stack with hybrid benefit, which is where Microsoft’s headline combined discount claims come from. One detail that trips up procurement: a zone-redundant General Purpose deployment needs two kinds of reservation, the base and the zone-redundant uplift, and buying only the first leaves a chunk of the bill uncovered.
The savings plan for databases arrived in March 2026 and is more flexible, at one year only, and it covers things reservations never did, including serverless and Hyperscale, and extending across several other database services. It also nominally covers the hourly SQL Server license meters on Azure virtual machines and on Arc-enabled servers, and this is where you need to read the documentation rather than the summary. Those license meters draw down your commitment at the normal pay-as-you-go price. They consume the plan without discounting anything. So “buy a savings plan to reduce your SQL Server virtual machine licensing” is not a strategy, it is a way to spend your commitment on the one thing it does not discount. Check the current behaviour before advising on it, and be specific about which meters actually benefit.
A commitment instrument that covers a meter is not the same as a commitment instrument that discounts it. That distinction is worth reading the small print for.
The extended security update cliff
Now the part with dates attached, which is why this article exists in July 2026 rather than at any other time.
SQL Server 2012 is finished. Its extended security updates have ended and Microsoft’s current guidance for 2012 and earlier is simply to upgrade to a supported version. There is no price at which those instances can be patched any more, which turns every remaining 2012 database from a budget conversation into a risk conversation.
SQL Server 2014 left extended support in July 2024 and its final year of updates runs to July 2027. Note that Microsoft’s own pages disagree on the exact day by four days, and the lifecycle page is the one to cite. Critically, 2014 remains free on Azure virtual machines through the end of its programme, because it is explicitly grandfathered.
SQL Server 2016 left extended support on 14 July 2026, and its updates began billing at midnight UTC the following day. Three further years of updates are available, running to 2027, 2028 and 2029. And here is the change that invalidates a great deal of existing advice: moving a 2016 workload to an Azure virtual machine no longer provides free access to its extended security updates. The current wording is specific to 2016 and later instances, and it took effect on 1 April 2026 as part of a broader pricing alignment. The strange result is that the older version, 2014, is the one that still gets free updates in Azure, while the newer one does not.
SQL Server 2017 runs to October 2027 and 2019 to January 2030, so those are planning horizons rather than emergencies.
On what extended updates cost, be careful, because this is a place where confident numbers circulate without support. There is no official published dollar price for SQL Server 2016 extended security updates. The only official prices are the Azure hourly meters, at seventy-four cents per core hour for Enterprise and nineteen cents for Standard, which are the same rates as the 2014 meters. Microsoft’s end-of-support overview describes extended updates generically as approximately seventy-five percent of the on-premises license cost annually. A widely-repeated community figure of a hundred percent of the current license has no first-party support that I can find. If you annualise the hourly meters yourself, say so and show your working, because that arithmetic is yours and not Microsoft’s.
One behaviour to design around: subscribing late bills back to the start of the term. Delay does not save money, it accumulates it. If an instance is going to run into the coverage period, subscribe when the period starts.
The flat line under everything
The last fact is the one that should reframe how you argue for any of this. The hourly SQL Server license rate on an Azure virtual machine and the hourly rate for an Arc-enabled server sitting in your own datacentre are identical, across Standard, Enterprise and Web. Microsoft has deliberately priced the software so that its location does not change what it costs.
So the licensing argument for migration is over. It is not weak, it is absent. Whatever case you make for moving a workload to Azure has to rest on platform capability, on the operational burden you stop carrying, on availability you could not otherwise build, or on the risk of running something unsupported. Those are all good arguments. If your deck currently opens with license savings, it needs rewriting, and the version that replaces it will be more honest and considerably harder to argue with.
Every figure in this article came from the current pricing feed on the day it was written, in one region, in one currency. Prices moved twice in the eighteen months before that. Treat the structure as durable, the rates as perishable, and re-pull anything you are about to put your name to.
Azure SQL
‹ Previous: [SQL 5.1] Build Sheet: Arc-Enabling the SQL Estate
Next: [SQL 7] The Migration: Assess, Choose, Cut Over ›
