The SA Removal Question — Why Organisations Get It Wrong
The decision to remove Software Assurance from an EA product line is one of the most consequential — and most frequently defaulted rather than decided — commercial choices in an enterprise Microsoft renewal. Default behaviour is SA renewal: the path of least resistance, the position Microsoft's account team will defend vigorously, and the outcome when no one has done the work to calculate SA ROI per product line before renewal. The result is that organisations routinely renew SA at full cost for product lines where the activated benefit value is less than 30% of the SA premium paid.
The opposite error also occurs. Removing SA to cut costs without understanding the downstream licensing implications can create situations where organisations lose AHB eligibility for Azure workloads — paying significantly more for Azure compute — or lose the right to run software on outsourced infrastructure under Licence Mobility provisions. In both cases, the cost of the error exceeds the SA savings. The correct approach is not "keep SA" or "remove SA" — it is a product-line-level decision that applies specific removal criteria to each qualifying licence category and quantifies the downstream cost impact of removal before committing.
The Four Removal Criteria — When SA Does Not Pay
1. End-of-Life Products with No Upgrade Plan
SA's new version rights require a new version to be released during the SA coverage period for the benefit to activate. For products that have reached end-of-extended-support or that Microsoft has effectively ceased active development on — older perpetual Office versions, legacy CAL suites, on-premises server products being decommissioned — SA's primary benefit does not apply. If your organisation is running a legacy product that will be decommissioned rather than upgraded during the next EA term (e.g., migrating from on-premises Exchange Server to Exchange Online, or retiring a legacy SharePoint farm), SA on those licences is consuming budget with no version rights, no AHB (decommissioning means no Azure equivalent), and no Licence Mobility (decommissioning). Removal criteria: product is on an end-of-life path and will be decommissioned within the EA term. Exception: if the product remains in active production until the last quarter of the EA term, SA DR rights (passive failover coverage) may justify retention for the decommissioning transition period.
2. Products Moving Fully to SaaS/Subscription
When a product line migrates from on-premises perpetual licences to a Microsoft SaaS subscription (Exchange on-premises to Exchange Online, SharePoint Server to SharePoint Online, Skype for Business to Teams), the perpetual licences becoming the subject of the SaaS migration lose their SA value basis. SA on Exchange Server perpetual licences becomes irrelevant when the organisation migrates to Exchange Online — the Exchange Server licence is no longer in active use, AHB for Exchange Server is not applicable (it is a user CAL structure, not a compute licence), and new version rights for Exchange Server have no value if the server is decommissioned. The correct commercial action is to remove SA from the on-premises product lines as part of the migration agreement rather than carrying them through the full remaining EA term. This is a commonly missed cost reduction opportunity during M365 migration negotiations.
3. No Azure Consumption and Stable On-Premises Version
For organisations running Windows Server and SQL Server entirely on-premises with no Azure consumption and no cloud migration plans within the EA term, the two highest-value SA benefits — Azure Hybrid Benefit (no Azure usage to apply it to) and new version rights for the specific product — are the primary decision factors. If the organisation is running SQL Server 2022 or Windows Server 2022/2025 and has no plan to upgrade during the current EA term, new version rights are inactive for that term. For SQL Server Standard or Windows Server Standard on-premises with no cloud usage, SA value reduces to DR rights (passive failover licence), training vouchers (typically low activation rate), and spread payment eligibility (administrative convenience, not financial benefit). In this scenario, the SA premium of 25–29% may not be justified. The exception: if a version upgrade is planned in the following EA term, removing SA in the current term and paying for new licences in the next creates a higher total cost than continuous SA coverage. This requires a multi-term cost comparison, not a single-term ROI calculation.
4. Products Being Replaced by Third-Party Solutions
When a Microsoft product is being replaced by a third-party alternative — on-premises SQL Server being replaced by PostgreSQL or Aurora, Windows Server workloads migrating to Linux containers, Office perpetual being replaced by Google Workspace — SA on the Microsoft product being phased out has zero value beyond the phase-out point. If the replacement timeline is within the current EA term, removing SA at renewal and carrying the perpetual licence through the remaining deployment period is commercially straightforward. If the replacement timeline is uncertain, SA removal should be timed to the confirmed migration date — accepting SA for an initial period and removing at the first EA amendment opportunity when the replacement timeline is confirmed.
| Product | Remove SA When... | Keep SA When... | Primary AHB Risk if Removed |
|---|---|---|---|
| SQL Server Enterprise | No Azure SQL usage, no upgrade plan, no hosted infrastructure | Any Azure SQL workload (AHB savings dominant) | High — AHB saves 40–60% on Azure SQL costs |
| SQL Server Standard | On-premises only, no version upgrade planned, no hosting | Step-up to Enterprise planned, any Azure usage | Medium — AHB applicable for Azure SQL dev/test |
| Windows Server Datacenter | No Azure IaaS, no future version upgrade planned, decommissioning | Any Azure IaaS consumption (unlimited VM AHB) | High — Datacenter AHB covers unlimited Azure VMs |
| Windows Server Standard | Stable version, no Azure migration, stable estate count | Azure migration planned, version upgrade next term | Medium — Standard AHB covers 2 Azure VMs |
| Office perpetual (non-M365) | M365 migration in progress or planned | Committed to perpetual licensing for foreseeable future | Low — no AHB component for Office |
| CAL suites (ECA, ECAL) | Migrating constituent products to M365/cloud equivalents | Active on-premises deployment of all constituent products | Low — primarily version rights value |
The Cost Implications of SA Removal — What You Lose
SA removal is not cost-free. Before removing SA, calculate what you lose across the full benefit set — not just the benefits you are currently activating. The most common post-removal regret scenarios in our client engagements are: removing SA from Windows Server Datacenter before a cloud migration that subsequently requires Azure IaaS (losing AHB and paying full Windows Server rates in Azure — $0.096/hour per vCPU for Standard, $0.192/hour for Datacenter equivalent, compared to near-zero incremental for AHB-covered VMs); removing SA from SQL Server Enterprise before a migration to Azure SQL Managed Instance (losing AHB and facing $4,012/vCore/year Azure SQL MI Business Critical pricing versus $960/vCore/year with AHB); and removing SA from Windows Server Standard before a branch office refresh that required new version rights for Windows Server 2025.
The general principle: SA removal is safest for product lines where cloud migration is definitively complete, the product is confirmed as decommissioned with no DR or passive-use requirement, and no future use in Azure or hosted environments is anticipated. The risk of removing SA on products with any remaining Azure or hosted deployment exposure is asymmetric — the SA premium saved is 25–29% of licence value per year, but the cost of covering Azure workloads without AHB or hosted workloads without Licence Mobility can exceed the SA saving within the first year of non-coverage.
SA Removal as a Negotiation Lever — Even When You Plan to Renew
The most powerful use of the SA removal decision is as a negotiation lever, regardless of whether the organisation ultimately renews SA. Microsoft's account team earns significant incentive compensation on SA renewals — SA is high-margin recurring revenue that Microsoft's commercial teams are motivated to protect. A credible, data-supported SA removal proposal presented at renewal generates genuine Microsoft concern and unlocks discount authority that is not available through standard volume pricing discussions.
The mechanism: prepare a per-product-line SA ROI analysis showing SA cost versus activated benefit value. For the lines where ROI is negative or marginal, present a removal proposal citing the specific benefit value calculation. Microsoft's response typically escalates to licensing specialist or management level — because SA removal on large server licence pools (e.g., 500 SQL Server Enterprise cores with SA represents $3.6M/year in SA revenue) is a material commercial loss. The discount offer that follows — typically 5–15% on the lines proposed for removal, occasionally 8–12% on core licence lines to retain overall contract value — can exceed the SA saving from removal itself.
The key to executing this leverage is credibility: the removal proposal must be backed by the ROI calculation, not presented as a budget-cut demand. An SA removal proposal with supporting benefit activation data (AHB usage export from Azure Portal, SATV redemption history from VLSC, version deployment timeline from infrastructure team) is treated as a legitimate commercial challenge. A removal proposal without supporting data is treated as a negotiating tactic to be waited out. Our EA negotiation tactics guide covers how to sequence the SA removal proposal within the broader renewal negotiation timeline.
The SA Removal Process — How It Works Mechanically
SA can be removed at EA renewal (the most common timing) or at an anniversary date through an EA amendment. At renewal, SA removal is executed by excluding SA from the qualifying licence line items in the new EA. The perpetual licences without SA continue to be usable indefinitely (perpetual licence right is retained even without SA coverage) — what is lost is the SA benefit entitlements going forward. There is no backdating of benefit loss to the current term: SA benefits active during the current term (AHB configurations, Licence Mobility agreements) remain in effect through the SA expiry date at the end of the current term, and must be removed or restructured before the SA expiry if the product will continue in Azure or hosted environments without new SA coverage.
The transition window between SA terms — the period between current SA expiry and the renewal effective date — requires careful management. Azure VMs running on AHB must be reconfigured to use Windows/SQL licences at standard rates before SA expiry, or SA must be renewed to maintain coverage. Licence Mobility Verification Forms (LVFs) active with authorised outsourcers expire with SA coverage and must be renegotiated if the hosted environment continues. Failing to manage this transition window is a compliance exposure — using AHB or Licence Mobility after SA expiry without new SA coverage is a licence compliance violation. Our Software Assurance complete guide and Licence Mobility guide cover the transition management requirements.
AHB exposure: Is this product's SA coverage enabling Azure Hybrid Benefit on any Azure VM, SQL MI, or Azure Arc deployment? Calculate the AHB saving at current usage. If >$10K/year, do not remove SA without replacing with a cloud subscription that includes the equivalent right.
Licence Mobility exposure: Is this product deployed in any outsourced or hosted environment under a Licence Mobility agreement? If yes, do not remove SA until the hosting arrangement ends or SPLA-based pricing is in place for the hoster.
DR rights: Is the passive DR environment for this product relying on SA DR rights (zero-cost standby failover server)? If yes, removing SA requires either retiring the DR server or purchasing additional production licences to cover it.
Version rights residual value: Is there a version upgrade planned in the next 12–24 months? If so, calculate whether renewing SA through the upgrade and removing at the following renewal is cheaper than removing now and purchasing new version licences at upgrade.
The decision to remove Software Assurance should always be made in the context of the full EA renewal strategy — not in isolation. SA removal is one lever among several, and its optimal use is as a negotiation instrument that generates discount authority on the lines being retained, rather than simply a cost-cutting action. For the full SA value framework including ROI calculations, see our Software Assurance benefits analysis and SA ROI calculation methodology.