Microsoft Software Assurance, usually shortened to SA, is often described as maintenance for volume licences. That shorthand is convenient but misleading. SA is not one universal package, it does not guarantee that every Microsoft benefit applies to every product, and several services that appeared in older sales material have been retired.
For organisations making a 2026 purchasing or renewal decision, the useful question is not whether Software Assurance is “good value” in general. The question is whether the active rights attached to a specific product, edition, licensing model and agreement support projects the business will actually deliver. SA can materially improve the economics of a Windows Server refresh, dense SQL Server virtualisation or an Azure migration. It can also become an avoidable recurring cost when workloads are static and none of its conditional rights will be used.
This guide provides a decision framework without inventing a standard price or a universal savings percentage. Microsoft Product Terms for the relevant month, the customer’s agreement and the exact SKU always take precedence.

What Microsoft Software Assurance means in 2026
Software Assurance is coverage attached to eligible Microsoft software licences acquired through certain volume licensing programmes. Depending on programme and SKU, it may be purchased with the underlying licence, renewed for a licence already under coverage or added as SA-only in a narrowly defined qualifying scenario and within the applicable deadline. Availability should never be assumed from the product name alone.
Open Value includes SA, while Open Value Subscription grants rights for the subscription term. Enterprise Agreement enrolments, EAS, SCE and MPSA can provide relevant routes, subject to the product and agreement. By contrast, Product Terms state that Software Assurance is not available as separate coverage under the Microsoft Cloud Agreement or Microsoft Customer Agreement. A subscription purchased through a cloud channel may carry equivalent rights or qualify for Azure Hybrid Benefit, but it is not automatically SA.
This distinction matters commercially. A perpetual licence with SA remains perpetual when coverage ends and retains the version rights that vested during the coverage period. A subscription remains time-limited. Neither model should be described as the other merely because both can temporarily receive similar benefits.
Organisations should also distinguish the underlying licence from active SA rights and from Azure service consumption. The licence answers what software may be run. SA can change version, mobility, virtualisation or failover entitlements while active. Azure terms determine where eligible licences can be applied and which service charges remain. Treating these as one bundle creates unreliable forecasts and weak audit evidence.
What Software Assurance currently includes
The definitive entitlement is the benefit shown for the relevant product entry in Microsoft Product Terms. The rights below are important, but none should be applied without checking product, edition, programme and current coverage.
New Version Rights
New Version Rights allow a customer to use a new version released while SA is active. If coverage later expires, a perpetual licence can continue to use the most recent version that became available during coverage. It does not gain versions released afterwards.
This is a licensing right rather than a technical upgrade service. It does not guarantee application compatibility, deployment assistance, indefinite product support or access to a higher edition. For example, a Standard licence does not become Datacenter or Enterprise because Microsoft releases another version. Downgrade rights are separate and must also be read from the relevant product entry.
Step-up Licences
An eligible Step-up can move a covered lower edition to a listed higher edition. The base licence and Step-up must remain continuously covered by SA or an eligible subscription. They do not become two independently deployable licences; together they represent the higher edition. Routes vary by programme, product and licensing model, so a Windows Server Standard-to-Datacenter route does not prove that a similar SQL Server or desktop route exists.
License Mobility and flexible virtualisation
License Mobility across Server Farms permits reassignment of eligible server products within the same server farm as often as required. Moving between server farms is generally subject to a 90-day rule. Eligibility is product-specific, and the right should not be expanded to software that is not marked for the benefit.
License Mobility through Software Assurance is a different right. It permits eligible server applications to run on shared servers at an Authorised Mobility Partner. All licences used must have active SA, Microsoft’s verification process is required, and the licence generally remains assigned to the shared server for at least 90 days. Microsoft’s operational guidance asks customers to submit the verification form within ten days of deployment and renew verification when the agreement renews.
The general mobility benefit does not cover the Windows Server operating system, Windows client or desktop applications. The Flexible Virtualisation Benefit, available for eligible subscriptions or SA-covered software on shared infrastructure from Authorised Outsourcers, is another distinct framework. It cannot be used with Microsoft’s Listed Providers acting as Authorised Outsourcers for that benefit. A hosting decision therefore requires both technical and provider classification checks.
Disaster Recovery and failover
Eligible server products may receive an additional backup OSE for disaster recovery, subject to conditions and any replacement rules in the product entry. “Disaster recovery right” is not interchangeable with “free active replica”. The workload normally needs to remain passive except for specifically permitted operations, tests, disaster periods and transitions. SQL Server has more detailed failover rights than the general benefit and must be assessed separately.
Azure Hybrid Benefit
Azure Hybrid Benefit, or AHB, allows eligible Windows Server and SQL Server core licences with active SA, or qualifying core subscriptions, to be applied to supported Azure resources. It can reduce or remove the eligible software licence component embedded in the Azure rate. Compute, storage, networking, reservations and other service charges remain payable.
Eligibility depends on licence quantity, edition, destination, ratios and service minimums. SA or the qualifying subscription must remain active. If it is not renewed, Microsoft’s Azure guidance requires the AHB selection to be removed from affected resources. A general 180-day migration allowance supports simultaneous on-premises and Azure use during migration; it should not be converted into a permanent dual-use assumption.
Additional product-specific rights
Depending on the product entry, SA can also support Self Hosting, advanced virtualisation, CAL equivalency or extended rights, Windows VDA scenarios, MDOP and eligibility rules for Extended Security Updates. ESU is not an unlimited, free patching entitlement for every SA-covered product. Its scope and acquisition rules apply to specified products reaching end of support.

Benefits that have been retired
Older Microsoft pages and partner presentations may still show services that are no longer part of the current general SA catalogue. A 2026 business case should exclude:
- Planning Services, retired on 1 February 2021.
- Training Vouchers, retired on 1 February 2021.
- 24x7 Problem Resolution Support, whose retirement began on 1 February 2023 and took effect progressively as agreements expired.
Support, training and deployment consulting may still be purchased from Microsoft or a partner under separate arrangements. That does not make them current SA entitlements. Historical references to the Home Use Program, e-learning or vouchers should receive the same treatment: they are not evidence of a right unless the current Product Terms and customer agreement grant it.
What Software Assurance costs and how to calculate ROI
There is no responsible universal price for Software Assurance. The amount varies with product, edition, licence metric, programme, agreement term, geography, currency, purchasing route and negotiated conditions. Online rules of thumb may be useful for early orientation, but a renewal decision should use the customer’s actual quote.
A reliable ROI model values only rights likely to be exercised during the agreement term. It should include:
- Incremental coverage cost: the net SA price plus internal administration and evidence management.
- Version value: the avoidable cost of relicensing if a new release arrives and will genuinely be deployed.
- Architecture value: licences or redesign costs avoided through eligible virtualisation, mobility, HA or DR rights.
- Azure value: the actual reduction in eligible software charges through AHB for forecast resources and operating hours.
- Option value: the value of a planned Step-up or preserving flexibility during a consolidation or divestment.
- Non-use risk: the probability that a cloud migration, upgrade or infrastructure project is delayed beyond the coverage term.
Model at least a conservative case, an expected case and a transformation case. AHB savings should be calculated from the organisation’s Azure pricing, region, service tier, reservation plan and expected uptime. Upgrade value should account for release timing, testing, application certification and deployment capacity. A licence right that the business cannot operationalise has little short-term financial value even if it looks attractive on paper.
Risk also has a cost. Allowing SA to lapse can remove active rights that support the current design, and coverage may not be simple to add back later. Conversely, renewing solely because reinstatement might be difficult is not a business case. The architecture and roadmap must identify a concrete exposure.
How the analysis changes for Windows Server, SQL Server and Azure
Windows Server: edition, cores and deployment location
For Windows Server, SA may provide value through new versions, AHB, disaster recovery and virtualisation rights connected to specific licensing models. It does not grant general License Mobility through SA for the Windows Server operating system. Standard and Datacenter also remain materially different. Under physical core licensing, Standard permits two OSEs for each fully licensed server, while Datacenter permits unlimited OSEs on the correctly licensed server.
Windows Server 2025 licensing by Virtual OSE is available only with an eligible subscription or active SA. It requires at least eight core licences per Virtual OSE, and the relevant CALs must also have SA or subscription coverage. Physical licensing still carries minimums of eight cores per processor and sixteen per server. SA can therefore be important in a dynamic cluster, but it does not remove core, OSE or CAL accounting.
For an Azure VM, eight eligible Windows Server core licences cover up to eight vCores and sixteen cover up to sixteen vCores; larger VMs require additional licences in increments of eight. Standard licences must generally be used on-premises or in Azure outside the 180-day migration allowance. Datacenter has additional allocation options, but it should not be marketed as unlimited dual use without identifying the exact Azure method and terms.
SQL Server: virtualisation, availability and licensing ratios
SQL Server often creates the strongest SA business case because virtualisation and resilience rights can materially alter the licence requirement. SQL Server Enterprise Core with SA can provide unlimited virtualisation when all physical cores are correctly licensed. Licensing individual Virtual OSEs requires active SA or an eligible subscription and at least four core licences per OSE. The better model depends on host density, edition, peak movement and cluster design.
For each Primary Workload, current SQL Server terms provide one Fail-over OSE for any purpose, including high availability, plus two Fail-over OSEs specifically for disaster recovery: one on any server and one on Microsoft Azure, with the Azure instance tied to AHB allocation rules. These are not three unrestricted active production copies. Failover instances may not serve SQL data to users or run ordinary active workloads outside the permitted activities. Limited simultaneous operation is allowed for brief DR tests once every 90 days, during a disaster and while moving between primary and failover OSEs.
AHB for Azure SQL Database and Azure SQL Managed Instance applies to the vCore model with provisioned compute, not DTU or serverless. For eligible destinations, Enterprise with SA can convert one on-premises core to four General Purpose vCores or one Business Critical vCore. Standard with SA uses one core for one General Purpose vCore and four cores for one Business Critical vCore. The widely repeated “one to four” message is therefore not a universal SQL rule. Server/CAL licences must not be treated as core licences without an express entitlement.
Azure: a targeted licence saving, not free cloud
An Azure assessment should begin with an allocation register: eligible licences, active coverage dates, assigned resources, vCores and permitted ratios. Asking only whether the company “owns SA” is insufficient. AHB can be combined with Azure reservations, but the two mechanisms address different price components and should be calculated separately.
AHB and License Mobility also solve different problems. AHB provides Azure-specific economics and can apply to eligible PaaS destinations. License Mobility supports eligible server applications on shared partner infrastructure after verification and subject to assignment rules. In some deployments either route might be relevant, but they must not be blended into one claimed entitlement.
For related planning, see our guides to Azure Hybrid Benefit, Windows Server licensing and SQL Server licensing.

When Software Assurance is worth it
Strong reasons to maintain coverage
- A new version is likely during the term and the organisation has a funded deployment plan.
- The Windows Server or SQL Server design depends on active virtualisation, mobility, failover or DR rights.
- Predictable Azure consumption can use verified eligible licences through AHB.
- A specific Step-up route supports a planned edition change more efficiently than separate relicensing.
- Frequent movement within a server farm makes eligible reassignment rights operationally important.
- Continuous coverage preserves a right already embedded in a production architecture.
When Software Assurance may not pay back
- The deployed version will remain stable and no active-coverage benefit supports the workload.
- The forecast value relies on retired training, Planning Services or 24x7 support benefits.
- Core, OSE, CAL, vCore and assignment records are too weak to use or evidence the claimed rights.
- The intended cloud service, hosting provider or licensing model is not eligible.
- The organisation already buys cloud subscriptions with sufficient rights and cannot identify why duplicate coverage is needed.
- The financial model assumes permanent on-premises and Azure dual use or unlicensed active failover replicas.
The answer can differ across the same estate. Maintaining SA for SQL Server Enterprise on highly virtualised hosts while allowing coverage to lapse for a stable, low-risk product may be rational. Segmenting by licence pool, SKU and workload normally produces a better result than an all-or-nothing policy.
Software Assurance purchase and renewal checklist
- Confirm country, organisation type, programme and current agreement.
- Record every SKU, edition, version and metric: Core, Server/CAL, user or device.
- Separate perpetual licences with SA from subscriptions carrying equivalent rights.
- Capture coverage expiry and the contractual renewal window.
- Count physical cores, processors, hosts, OSEs, vCores and CALs.
- Map each expected benefit to a named project, workload and delivery date.
- Classify the provider as Azure, Authorised Mobility Partner, Authorised Outsourcer or Listed Provider.
- Check 90-day reassignment restrictions and the 180-day migration allowance.
- Label every failover workload as HA, passive DR, testing or disaster operation.
- Complete License Mobility verification where required.
- Compare the real SA quote with conservative, expected and transformation scenarios.
- Retain the applicable monthly Product Terms, agreement, orders and allocation evidence.
Our Microsoft licensing audit checklist can help organise the wider evidence set. Revalidate it before renewal, after a migration and whenever hosts or providers change.
Decision element
| Signal | Prudent decision |
|---|---|
| Planned upgrade | Value New Version Rights |
| Hybrid migration | Validate AHB in Product Terms |
| No defined project | Do not renew by inertia |
Frequently asked questions
Does Software Assurance include 24x7 support?
Not as a current general benefit. Microsoft began retiring 24x7 Problem Resolution Support on 1 February 2023, with the change applying as agreements expired. Support may exist under a separate contract.
Does SA let us upgrade to any new edition?
No. New Version Rights cover a new version of the licensed edition released during active coverage. Moving to a higher edition requires an eligible Step-up route or another licence.
Can we move Windows Server licences to any cloud?
No. General License Mobility through SA does not cover the Windows Server operating system. Azure Hybrid Benefit and outsourcing frameworks have specific destinations, provider classifications and conditions.
Can the same licence be used on-premises and in Azure?
An eligible migration can use the general 180-day simultaneous-use allowance. Outside that period, product and allocation rules apply; permanent dual use should not be assumed.
What happens when Software Assurance expires?
A perpetual licence retains vested perpetual rights and the most recent version made available during coverage. Rights requiring active coverage end. A subscription ends under its contract and does not become perpetual.
Where should we verify the final entitlement?
Use the current Microsoft Product Terms, select the correct programme and product entry, and read them with the customer agreement and purchase records. Microsoft Learn supports implementation but does not replace the licence terms.
Conclusion: pay for rights your roadmap will use
Software Assurance can protect a Microsoft licensing investment and enable designs that would otherwise require more licences or a different architecture. Its value comes from connecting a specific entitlement to an actual project: a version that will be deployed, a server farm that needs reassignment flexibility, a correctly designed SQL failover topology or Azure resources that can consume AHB.
The case should be rebuilt at every renewal. Product Terms change, legacy benefits disappear and infrastructure plans move. A SKU-level review using a current quote and measured workload data shows which coverage deserves to continue and which is simply adding cost.
Need a defensible answer before your next purchase or renewal? Ask Licendi to review your Software Assurance position. We will map products, coverage, infrastructure and planned use to a documented recommendation without assuming rights that do not apply.




