CIO Playbook: Microsoft Software Assurance (SA)

CIO Playbook: Microsoft Software Assurance

Introduction

Microsoft Software Assurance (SA) has been a cornerstone of Microsoft’s volume licensing strategy for enterprises for many years. SA provides organizations with a suite of benefits – from new version upgrade rights and training to support and cloud mobility – designed to maximize the value of their software investments.

Historically, SA was introduced as part of Microsoft’s Licensing 6.0 in the early 2000s, allowing customers to spread payments over several years while receiving free upgrades to newer software versions during that period.

Over time, SA became an integral component of Enterprise Agreements (EAs) and other volume licensing programs, such as Select, Select Plus, and MPSA, which were often included by default for large customers to ensure they always had access to the latest software and additional support rights.

However, as Microsoft’s product offerings and licensing models have evolved – especially with the rise of cloud services and subscriptions – the scope and value proposition of SA have significantly changed. Several traditional SA benefits have been phased out or transformed in recent years to eliminate redundancies and align with Microsoft’s cloud-first strategy.

Today’s CIOs must re-evaluate the role of SA in their IT strategy: understanding what it still offers, what has been retired, and how it fits (or doesn’t fit) in a world increasingly dominated by Microsoft 365 and Azure subscriptions.

In this playbook, we provide an analysis of Microsoft Software Assurance, focusing on its recent updates and its impact on large enterprise customers globally. We will cover the historical role of SA in volume licensing, detail which benefits have been retired and which remain active, illustrate these changes in a comparative table, and explain where SA is still necessary, for example, to secure upgrade rights for on-premises servers.

We will also clarify how SA intersects with hybrid cloud benefits like License Mobility and Azure Hybrid Benefit, discuss Microsoft’s shift toward subscription licensing and the diminishing relevance of SA, and provide actionable recommendations on when to retain SA, when to let it go, and how to make the most of the benefits that remain.

Throughout this playbook, we include key citations and data to back up our analysis. Visual summaries and tables are provided to help you quickly grasp the changes. Each section concludes with a “Recommendations for CIOs” segment, highlighting practical advice.)

Software Assurance in Volume Licensing: Historical Role and Purpose

What is Software Assurance? Microsoft Software Assurance is essentially a software maintenance and benefits program available through volume licensing.

It provides an “insurance policy” on software investments by bundling upgrade rights and additional perks for a fixed annual fee, typically around 25% of the license cost per year.

In practical terms, SA has meant that an organization buying Microsoft licenses could pay a bit extra upfront or annually and, in return, get: automatic access to new versions, deployment resources, support, training, and more.

According to Microsoft, SA spans a broad range of Microsoft products, including Windows, Office, and server software, and offers tools and services to help plan, deploy, and use those products effectively. Over the years, Microsoft has continually added (and sometimes removed) benefits to keep SA aligned with customer needs​.

Historical Importance in Enterprise Agreements (EA) and MPSA:

In Microsoft’s traditional Enterprise Agreement, designed for 500+ users, SA is automatically included with license purchases. This made EAs a popular choice for large enterprises, as they always had rights to the latest software and extra support.

Similarly, under the Microsoft Products and Services Agreement (MPSA) and earlier programs, such as Select Plus, customers could opt for SA on their purchases to secure these advantages. SA became synonymous with future-proofing software assets – organizations with SA didn’t need to worry about surprise costs for the next Windows or Office upgrade; it was covered.

Additionally, SA conferred valuable rights, including the ability to use software on home computers (through the Home Use Program), access to exclusive enterprise editions (which were only available through SA), and license mobility for flexibility in deployment.

In sum, SA’s role was to add flexibility, support, and predictability to Microsoft licensing, which was especially critical in large enterprises managing thousands of devices and users.

Key Benefits Provided (Historically):

Historically, Software Assurance offered a comprehensive bundle of benefits to enterprises, including​:

• New Version Rights (Upgrade Protection): The flagship benefit – rights to all new version releases of covered products during the term. This ensured that organizations could always upgrade to the latest version of Windows, Office, or servers without needing a new license.
• Training and Certification Vouchers: Free training days that could be redeemed with Microsoft Certified Partners, and access to Microsoft e-Learning courses for users, to improve adoption and IT staff skills​.
• Deployment Planning Services: Vouchers for consulting services to plan deployments or migrations (e.g., SharePoint deployment planning) with Microsoft partners, reducing the burden on internal teams.
• 24/7 Problem Resolution Support: Several support incidents or calls with Microsoft support are available anytime, providing IT with fast help for critical issues.
• Extra Product Use Rights: For example, using Microsoft Office at home for employees (Home Use Program), running Windows in virtual environments (Virtual Desktop Access rights), and exclusive access to Enterprise editions of Windows and the Microsoft Desktop Optimization Pack (MDOP) toolkit.
• License Mobility: The right to reassign certain server application licenses flexibly across servers or to third-party clouds, which standard licenses did not allow (we will detail this later).
• Disaster Recovery (Cold Backup) Rights: The right to install certain server products on a “cold” standby server for disaster recovery without additional licenses​.
• Source Code Access: For the largest customers, the option to access Windows source code for internal security and development review—a niche benefit for deployments of 10,000+ desktops.

These benefits made SA a comprehensive support package for enterprise IT, from software upgrades to user training and ensuring uptime. It justified the additional 25% annual cost by offsetting other expenses, such as external training or support fees​.

In effect, SA was Microsoft’s way of keeping enterprise customers “locked in” but also well-supported and up-to-date in the Microsoft ecosystem.

It was highly relevant in the era when software was primarily on-premises and major version upgrades (e.g., Windows XP to Vista to 7, or Office 2007 to 2010) were significant events.

Recommendations for CIOs

• Recognize SA’s Original Value: Understand that Software Assurance was traditionally about future-proofing and support, ensuring your organization had access to the latest software and adequate support and training. This historical context is key when assessing its value today.
• Inventory Your SA Coverage: Take stock of which current licenses in your estate are under SA and what benefits you’ve been using. This will help determine if those benefits are still needed or if newer solutions have replaced them.
• Map Benefits to Needs: Map the historical SA benefits to your IT needs. For example, did you rely on SA for upgrade rights, for support calls, or training? This will highlight which areas might need new strategies if those benefits have changed.
• Understand License Program Ties: Remember that if you’re in an Enterprise Agreement, Software Assurance (SA) is likely included in your costs. In other licensing programs, such as MPSA and Select, you may have optional SA. This distinction will matter when planning renewals or migrations – dropping SA may mean changing your licensing program or negotiating custom terms.

Recent Changes to Software Assurance Benefits (Retired vs. Remaining)

Over the past few years, Microsoft has made significant changes to Software Assurance benefits, driven by the shift to cloud services and new support models. Many traditional SA benefits have been retired, replaced, or emphasized.

This section details which benefits have been phased out and which remain in place as of 2025. The table below provides a high-level summary, and subsequent paragraphs explain each item:

Table: Summary of key Software Assurance benefits – active vs. retired.

As shown above, many value-added services, including training, planning, and support, that were once part of SA were retired during the 2020-2023 period. Microsoft’s rationale has been to remove redundancies and streamline offerings.

For example, cloud adoption has made some planning services less relevant; FastTrack now helps with Office 365 and Azure migrations for free. Microsoft Learn provides training content to everyone at no cost, eliminating the need for training vouchers​.

Likewise, the support benefit was folded into the costly Unified Support model, as Microsoft found that large customers were already moving to comprehensive support contracts.

What remains, then, is a leaner set of “core” SA benefits focused on license rights rather than service perks. The upgrade rights (“New Version Rights”) remain the headline benefit, crucial for anyone holding perpetual licenses. License Mobility and Hybrid Cloud benefits remain highly relevant for those running workloads in the cloud; we’ll discuss these in detail in the next section.

Azure Hybrid Benefit, in particular, has become a focal point of value – it’s essentially an SA-enabled discount program for Azure. Traditional perks like the Home Use Program still exist, even though they have evolved to align with subscription offerings. Employees can now get discounted Microsoft 365 subscriptions for home use, reflecting the shift from perpetual Office to subscription-based Office 365​.

It’s worth noting that Software Assurance benefits are not available under newer purchasing models, such as the Microsoft Customer Agreement (MCA) or Cloud Solution Provider (CSP), for cloud subscriptions.

Those programs use subscription licensing, which includes some of these rights inherently (for example, an Office 365 E3 subscription includes upgrade rights and client access licenses by nature, and Azure usage is pay-as-you-go). Thus, SA benefits now mostly apply to traditional volume licensing programs, such as EA, MPSA, Open Value, and perpetual licenses.

Recommendations for CIOs

• Stay Informed of SA Retirements: Ensure your team is aware that Training Vouchers, Planning Services, and included Support incidents are no longer available under SA. If your IT plans still assume these resources, update them with alternative sources (e.g., Microsoft Learn for training, FastTrack or third-party consultants for deployment planning, and a paid support contract or ad-hoc support for break-fix issues).
• Leverage the Remaining Benefits: Make the most of the core benefits that are still available. For example, if you maintain SA on Windows Server or SQL Server, plan to upgrade to newer versions to maximize the value (don’t let your upgrade rights go unused). If you have eligible licenses, utilize Azure Hybrid Benefit to save on cloud costs – this directly impacts your bottom line​. If license mobility is relevant (moving a workload to AWS or Google Cloud), ensure that Software Assurance (SA) is in place so you remain compliant and cost-efficient.
• Communicate Changes to Stakeholders: Share the recent SA changes with stakeholders. For instance, your learning & development department should know that the old SA training voucher program ended in 2022, so they should not plan on redeeming vouchers (but can take advantage of free Microsoft Learn content). Similarly, ensure that your support teams know that free SA support incidents are no longer available, avoiding unpleasant surprises when an issue arises.
• Update Policies and Documentation: If your software asset management documentation or IT policies mention SA benefits (like “use SA vouchers for training” or “use SA support calls for P1 incidents”), update them to reflect the current reality. Align your IT budget to account for costs that SA used to cover (e.g., allocate a budget for support now that it’s no longer free with SA).
• Use the Table as a Checklist: Use the above benefit table as a checklist against your use of SA. Tick off which benefits you use. This will be useful in deciding if maintaining SA is warranted for each product (more on that in later sections).

Where is Software Assurance Still Required (and Valuable)?

Given the many changes, CIOs may ask: Do we still need Software Assurance at all? The answer depends on your organization’s licensing scenario.

SA is no longer universally needed in an era of cloud subscriptions, but there are specific scenarios where SA remains essential or highly valuable. In this section, we outline where SA is still required or provides unique value in a modern IT environment:

• Perpetual License Upgrade Rights: If your organization uses perpetual licenses for on-premises software (as opposed to subscriptions), Software Assurance (SA) is the most efficient way to stay current. For example, suppose you run Windows Server 2019 or SQL Server 2019 on-premises and plan to upgrade to the latest versions (Windows Server 2022, SQL Server 2022, etc.). In that case, you need an active Software Assurance (SA) subscription to do so without needing to purchase new licenses. SA provides “new version rights”, meaning you can download and use the new release as part of your entitlement​. Without SA, you would have to purchase a new license for the new version or continue using the old version indefinitely. This is particularly crucial for server OS and database platforms, where new releases bring security and performance improvements. SA is effectively required to continuously modernize on-premises software. (Note: For desktop OS, if you still buy Windows 10/11 Pro licenses, SA is required to move to the next version or to use Windows Enterprise features outside a subscription model.) In short, any perpetual software that you expect to upgrade every few years should ideally be under a Software Assurance (SA) agreement – especially Windows Server, SQL Server, Exchange Server, SharePoint Server, and so on.
• License Mobility / Multi-Cloud Flexibility: Organizations pursuing a hybrid cloud or multi-cloud strategy may need SA for its “license mobility” benefits. If you want to take an on-premises license and deploy it on a third-party cloud, such as Amazon AWS or Google Cloud, Microsoft requires that Software Assurance cover the license. For instance, moving a SQL Server workload to AWS using your existing licenses is allowed only if those licenses have active SA (and you must deploy on an “Authorized Mobility Partner’s” infrastructure). Without SA, many Microsoft products cannot be legally run on someone else’s cloud infrastructure using your perpetual licenses. SA effectively enables bring-your-own-license (BYOL) scenarios for certain applications, giving you flexibility to choose the most cost-effective or capable cloud for a workload. Suppose your enterprise wants the freedom to port licenses between on-prem data centers and clouds (or between cloud providers) to optimize costs or performance. In that case, SA is often required to keep you compliant and flexible. (We will detail the mechanics in the next section, but note that even with recent Microsoft policy changes, having SA or subscription coverage on licenses is the key to flexibility in the cloud.)
• Azure Hybrid Benefit (Cost Savings in Azure): If your strategy involves heavy use of Microsoft Azure, the Azure Hybrid Benefit can be a valuable cost-saving option. AHB allows you to use your existing Windows Server and SQL Server licenses in Azure and pay a lower rate for the cloud services (you’re essentially not paying for the license portion again)​. While Azure itself is a subscription service, leveraging AHB requires that you have on-premises licenses with active Software Assurance (SA) or equivalents, such as subscription licenses. For example, a Windows Server Datacenter license with Software Assurance (SA) can cover up to two Azure VM instances, which dramatically reduces the cost of those VMs. Similarly, SQL Server licenses with SA can be used for Azure SQL Database or SQL Managed Instance at a fraction of the normal cost. AHB is one of the strongest reasons to maintain SA on server products if you plan to run hybrid deployments or migrate workloads to Azure. It can yield substantial cost savings – estimates often cite savings up to 30-50% on Azure VM workloads by using AHB. Therefore, if you anticipate using Azure for critical workloads while also owning on-prem licenses, keeping those licenses under SA ensures you can capitalize on AHB and optimize your cloud spend.
• Server Farm Flexibility and Failover Rights: In purely on-premises contexts, SA can still be required for certain advanced use rights. For example, license reassignment flexibility – standard licenses without SA can only be moved between servers (or from one piece of hardware to another) once every 90 days. SA often waives this restriction for certain products, allowing for more frequent reallocation, which is important in virtualized “server farm” environments or when using VM mobility features like VMware vMotion or Hyper-V Live Migration. Additionally, failover rights for high availability: for products like SQL Server, having SA allows for a passive secondary server for failover without additional licensing, when used for high availability (HA) or disaster recovery (DR) purposes. While Microsoft has made some failover rights standard for certain products, SA historically has been the enabler for fully covered HA/DR scenarios. CIOs running mission-critical apps on-premises should verify if SA is needed to cover their failover environments or to enable load balancing across clusters without requiring extra licenses. In summary, if your environment relies on flexibility or redundancy that standard licensing doesn’t allow, SA is likely the tool that provides those rights.
• Legacy Products and Extended Support: Another scenario is if you are stuck on older software versions that are out of support – Microsoft sometimes offers Extended Security Updates (ESUs) for products past End-of-Life only to customers with Software Assurance (or subscription equivalents). For example, Windows Server 2012/R2 extended patches required an active subscription or Software Assurance (SA) at the time of purchase, and Windows 7 Extended Security Updates (ESU) were available as an add-on for volume-licensed customers. This is a niche but critical scenario: SA can be a prerequisite to buying or qualifying for extended support patches when you cannot upgrade a legacy system by its end-of-support date. If you foresee needing to keep some legacy systems running, maintaining SA (or the closest equivalent) could provide a safety net.
• Enterprise Windows & Office Deployment (if not on M365): In cases where an enterprise has not fully migrated to Microsoft 365 and still uses perpetual versions of Windows and Office, Software Assurance (SA) is typically required for the enterprise features. For instance, the Windows Enterprise edition, which includes features like BitLocker and AppLocker, has historically required Windows Pro with Software Assurance (SA). Organizations that deploy Windows Enterprise through volume licensing still need a Software Assurance (SA) or a subscription to do so. Similarly, if you use perpetual Office licenses (Office 2019 or 2021), only SA will grant you rights like roaming use or a future upgrade to the next version. While many have shifted to Office 365, some regulated or offline environments might stick to perpetual Office; SA is the only way to ensure those Office licenses stay current with new releases. So, if you are one of the exceptions not on subscription for client software, SA retains its old importance.

In summary, SA is still required or beneficial in any scenario where you have perpetual licenses and need either continued upgrade rights, cloud flexibility, or advanced use privileges.

Large enterprises often have a mix of legacy on-premises systems and new cloud services. SA can be the bridge that allows these legacy systems to integrate or transition to the cloud smoothly, via upgrade rights or hybrid benefits.

Recommendations for CIOs

• Identify SA-Needed Workloads: Audit your IT portfolio to identify which systems or applications depend on SA for their lifecycle management. Typical ones include on-premises servers (Windows/SQL) that you plan to upgrade, applications you might move to AWS or Google, or any use of Azure Hybrid Benefit. This will highlight where SA is still needed to meet your roadmap.
• Quantify the Value: For each area where SA is required, quantify the benefit. For example, calculate how much you’d save in Azure with Hybrid Benefit versus not having it, or the license cost avoidance of upgrading Windows Server via SA vs. buying new licenses. This cost-benefit analysis helps justify retaining SA for those specific cases (and communicating that value to finance and executives).
• Consider Alternatives but Mind Compliance: In scenarios like multi-cloud, if you’re tempted to drop SA, be aware of the compliance implications. Do not assume you can bring licenses to the cloud without SA – Microsoft’s rules prohibit that in many cases​. If you want cloud flexibility without SA, you’ll need to consider cloud-specific licensing options (e.g., acquiring licenses through AWS or using Azure’s pay-as-you-go rates, which are often more expensive). Recommendation: Where you need the flexibility, keep SA; where you don’t, consider dropping (we’ll expand on this decision in a later section).
• Use SA where it’s a Bridge to Cloud: If you have a lot of legacy investment, think of SA as a strategic bridge. For example, keeping SA on SQL/Windows for one more term might facilitate a cost-effective migration to Azure using AHB, versus dropping SA and then paying full price in Azure or for upgrades later. Plan your cloud migrations with SA timelines in mind – perhaps maintain SA until the migration is complete and then reassess.
• Double-check legacy and Support Needs: If you have any products nearing end-of-support, consult with Microsoft or your licensing partner to determine if Software Assurance (SA) is required to purchase Extended Security Updates or to receive support and maintenance benefits. In some cases, having SA can provide an additional cushion (e.g., free ESU in Azure for 3 years is a benefit if you migrate those workloads to Azure). Ensure you’re not caught off-guard by dropping SA and then finding you can’t get critical patches.
• Communicate “Why We Keep SA” to Finance: When you do choose to retain SA on certain licenses, clearly communicate the reason (e.g., “We must keep SA on Windows Server because it’s the only way to upgrade to the next version and maintain compliance when moving to cloud – avoiding a costly repurchase later”). This helps stakeholders appreciate that SA spend is deliberate and tied to strategic needs, not just an auto-renewal.

SA and Hybrid Cloud Benefits: License Mobility vs. Azure Hybrid Benefit

One of the most significant aspects of Software Assurance in recent years is its role in enabling hybrid cloud scenarios. Two terms often come up: License Mobility and Azure Hybrid Benefit. Both relate to using existing licenses in cloud environments, but they apply in different contexts.

Here, we clarify each and how they tie back to SA:

• License Mobility through Software Assurance: License Mobility is an SA benefit that allows certain on-premises application licenses to be reassigned to third-party cloud providers’ infrastructure. In simpler terms, if you have, say, a SQL Server license with active SA, License Mobility lets you deploy a SQL Server instance on a cloud VM (like in AWS, Google Cloud, or a hosting partner’s datacenter) without buying a new license through that cloud provider, as long as the provider is a Microsoft “Authorized Mobility Partner”. This was crucial for enterprises that wanted to use their existing investments in environments outside their own data center. For example, many organizations moved workloads to AWS and used License Mobility to avoid paying double for SQL or SharePoint licenses. Important details: License Mobility covers application servers (SQL, Exchange, SharePoint, Dynamics Server, etc.), but notably does not cover Windows Server itself​ – meaning you cannot bring your own Windows Server license to a multi-tenant cloud VM via License Mobility (cloud providers require you to use their Windows licensing or dedicate hardware due to Microsoft policy). Also, License Mobility requires an active SA at the time of moving the license; if the SA lapses, the right to run that license in the cloud also lapses. In 2022, Microsoft introduced a further update called the Flexible Virtualization Benefit (FVB), which expanded on License Mobility by allowing customers with SA or subscription licenses to use any cloud provider’s infrastructure (including non-Authorized ones, basically any outsourcer) except a short list of major providers, with fewer restrictions. FVB’s introduction reinforces that having SA (or subscriptions) is key to unlocking flexible use of licenses in the cloud. In summary, License Mobility (and the newer FVB) are about porting licenses to third-party clouds.
  They give CIOs negotiating power and flexibility – you can choose or switch cloud vendors for certain workloads without abandoning your on-prem license investments, provided those investments have SA. This is a strategic benefit if you want to avoid cloud vendor lock-in or maintain hybrid deployments.
• Azure Hybrid Benefit (AHB): Azure Hybrid Benefit is a Microsoft Azure-specific program that allows customers to use their existing licenses to receive discounted rates on Azure services. While not branded as an “SA benefit” per se, in practice, you must have Software Assurance or equivalent subscription rights to use Azure Hybrid Benefit. For example, with AHB, a Windows Server Datacenter license with SA allows you to run two instances of Windows Server in Azure without paying for the Windows license in those Azure VMs; you only pay the base compute rate. Similarly, suppose you have SQL Server Enterprise core licenses with SA. In that case, you can assign them to Azure SQL Database or SQL Managed Instance and pay a much lower rate, essentially covering only the Azure platform cost, not the SQL license. Azure even extends this to things like Azure VMware Solution and Azure Stack. The benefit can be activated directly in the Azure portal by declaring that you have eligible licenses. The relationship to SA: from a CIO’s perspective, AHB is effectively the reason to keep SA on your server products when moving to Azure. It provides a direct and substantial cost savings on Azure—studies and Microsoft’s guidance suggest savings up to 30-50% on workloads by using AHB compared to paying full Azure rates​. One key difference from License Mobility is that Azure Hybrid Benefit is only available for Azure (not third-party clouds), and it also covers Windows Server, which License Mobility does not. Also, Azure allows some concurrent use during migration. For example, you can use a Windows Server license both on-premises and in Azure for up to 180 days when migrating a server to Azure, provided you have Software Assurance (SA). This dual-use allowance is part of the hybrid benefit considerations and helps avoid downtime during transitions.
  In summary, Azure Hybrid Benefit is about optimizing costs in Azure using existing licenses. It’s a compelling benefit for enterprises in Azure or planning to migrate there. It turns SA into a tangible budget saver rather than just a future upgrade promise. However, if you don’t use Azure at all, AHB might be irrelevant – its value is directly tied to Azure adoption.

How they work together:

License Mobility and Azure Hybrid Benefit can be seen as complementary: one for non-Azure clouds, and one for Azure. Both require that you’re paying for SA or a subscription to the relevant product.

Without SA, if you tried to move a workload to AWS or Google Cloud, you’d likely have to pay the cloud provider’s license-included rate (and for some products, like SQL, that can be much more expensive than reusing your license).

Likewise, without SA, moving a Windows/SQL workload to Azure means you cannot claim the hybrid benefit discount, so you’d pay full price for an Azure VM (which includes a Windows license by default) or for the Azure SQL service.

It’s also worth noting Microsoft’s broader strategy: by offering AHB, Microsoft encourages customers to keep their SA active when moving to Azure, rather than canceling it because they’re switching to the cloud. And by restricting certain rights (like Windows Server BYOL) in other clouds unless specific conditions are met, Microsoft indirectly nudges customers toward Azure or at least to maintain SA if they want a multi-cloud approach.

For CIOs, the takeaway is that SA is a tool that can unlock cloud flexibility and savings, but planning is essential. You should actively decide where to apply SA for maximum benefit in your cloud journey.

Recommendations for CIOs

• Plan Cloud Moves with License Mobility in Mind: If you anticipate migrating or bursting workloads to AWS, Google, or other clouds, audit which licenses will be affected and ensure they are covered with Software Assurance (SA). Only covered licenses can be moved under Microsoft’s License Mobility rules​. Engage with your cloud provider and Microsoft representative to understand the process (often, you need to fill out a license verification). This avoids compliance pitfalls and fully leverages your existing investments.
• Maximize Azure Savings: If you’re an Azure consumer, implement Azure Hybrid Benefit wherever applicable. This means keeping SA active on the relevant Windows Server and SQL Server licenses. Work with your cloud architects to verify that AHB is enabled for eligible Azure VMs and databases – this is a quick way to achieve cost savings. Monitor your Azure usage and ensure new deployments also utilize AHB if you have spare licenses. Essentially, treat AHB as a default part of your Azure cost management strategy if you own on-prem licenses.
• Use SA for a Dual Cloud Strategy: For a multi-cloud strategy, SA gives you a competitive edge. You could, for example, move a workload from your datacenter to Azure using AHB, and later decide to run it on AWS for strategic reasons using License Mobility – all with the same licenses because SA keeps that flexibility. Recommendation: Maintain SA on any critical workload licenses that you might deploy in any cloud. This hedges against changes by cloud providers and keeps your options open.
• Keep an Eye on Policy Updates: Microsoft has shown a pattern of evolving these benefits (e.g., introducing the Flexible Virtualization Benefit in 2022). Stay up to date on the latest rules for license mobility and hybrid benefits. Some new benefits, like FVB, might broaden your options (e.g., allowing more hosting scenarios if you have SA). By keeping informed, you can quickly capitalize on changes. Subscribe to Microsoft licensing news or work with a licensing specialist to get updates on any policy shifts that could affect your rights in the cloud.
• Train Your Cloud and Licensing Teams: Ensure your cloud strategy team and software asset management team collaborate. Cloud architects should understand what SA entitles them to do – for instance, they should know that “yes, we can deploy that SQL Server cluster on Google Cloud because we have SA, let’s use our licenses instead of paying Google for it.” Likewise, SAM/licensing personnel should be familiar with the organization’s cloud plans so they can advise on which licenses require Software Assurance (SA) renewal. Cross-functional planning avoids oversights, such as dropping SA on a license that the cloud team expected to reuse in AWS next year.
• Evaluate ROI of SA for Cloud Use: While SA costs money, compare it to the alternative cost of not having it in the cloud. If maintaining SA on a SQL Server Enterprise cluster costs $X, but re-licensing or paying cloud fees without SA would cost $2X, then SA is worth it. Do this math for key workloads. Often, you’ll find that SA pays for itself quickly in cloud scenarios, but make sure to validate this for your specific case (e.g., check Azure Hybrid Benefit savings rates, AWS BYOL vs. license-included prices, etc.). This will strengthen the business case for keeping SA on those assets.

Microsoft’s Shift to Subscription Licensing and SA’s Diminishing Relevance

In recent years, Microsoft has been aggressively pushing customers toward subscription-based licensing models – think Microsoft 365 (which combines Office 365, EMS, and Windows E3/E5), Dynamics 365, and Azure consumption.

This cloud-centric shift has a profound impact on the relevance of Software Assurance. In many cases, subscriptions inherently include the benefits that SA used to provide, or they make those benefits moot.

Let’s explore this shift and what it means for SA:

• Microsoft 365 and Office 365: With Office 365, customers no longer buy perpetual Office licenses; they subscribe to Microsoft 365 Apps (formerly Office ProPlus), which is always updated. This means upgrade rights are built-in – you always have the latest version as part of your subscription. There’s no need for SA to get a new Office release; it just arrives as an update. Similarly, Office 365 and Microsoft 365 plans include various user benefits, such as the ability to install on multiple devices, use mobile apps, and even for personal use at home. Each user can install Office at home via their O365 license, which largely replaces the need for the old Home Use Program. For Windows OS, Microsoft 365 E3/E5 subscriptions include Windows 10/11 Enterprise as a user-based license, which inherently provides virtualization rights, regular updates, and the ability to downgrade or upgrade across versions. Again, no separate SA is needed – the subscription covers it. The result: Organizations that moved to Microsoft 365 have found that SA for their clients is no longer relevant; the concept doesn’t apply to cloud subscriptions. In fact, under the newer Microsoft Customer Agreement or Cloud Solution Provider channels, SA isn’t even an option – everything is either a subscription or “as a Service”.
• Azure and Server Subscription Models: On the server side, Azure’s IaaS/PaaS services mean you don’t buy Windows Server or SQL Server licenses outright for Azure VMs or Azure SQL – it’s part of the service cost (unless you use AHB as discussed). Microsoft has even introduced “server subscriptions” for on-premises use in some programs. For example, in CSP, you can get a subscription for Windows Server or SQL Server that grants you rights to run the software for a year or three, including upgrades. These subscription licenses, used on-premises, function much like SA (upgrade rights, etc.), but are not called SA – they are active subscriptions. If an enterprise opts for such licensing, the classical SA program is bypassed again. Trend: Microsoft is offering more flexible subscription deals for traditionally perpetual products, which reduces the need to commit to SA in the long term. You can subscribe when you need to and cancel when you don’t, in some cases.
• Volume Licensing vs. Cloud Agreements: Microsoft has been transitioning agreements. Many enterprise customers with predominantly cloud services are being moved from the traditional EA to the Microsoft Customer Agreement (MCA). Under MCA (and its partner version CSP), Software Assurance benefits do not apply the same way, because the licensing construct is different (perpetual licenses with SA vs. subscriptions). Gartner and other analysts observe that Microsoft is de-emphasizing perpetual licensing. Certain programs, like the Select Plus agreement, were retired, and MPSA (which allowed perpetual licensing with optional support agreements) hasn’t been promoted as widely as CSP. Microsoft’s revenue model and roadmap favor recurring subscriptions. As a result, the classic SA program is less central in Microsoft’s sales motion than it was a decade ago.
• Diminishing SA Attach Rate: Many organizations are finding that fewer of their Microsoft products even qualify for or require SA. If 70% of your spend is on Microsoft 365 E5 and Azure, those don’t use SA. Perhaps only your on-prem Windows Servers or SQL Servers (which might be the remaining 30%) are under SA. And even those might be candidates to move to Azure or a subscription model, such as Azure Stack HCI or SQL managed instances. CIOs report that the “SA spend” portion of their enterprise agreements has been shrinking relative to pure cloud subscription spend. Microsoft has also reduced incentives around SA – for instance, the retirement of training and planning benefits suggests that they anticipate a lower need to sweeten the pot for SA buyers. Customers are either moving to the cloud or will pay for SA just for upgrade rights if they must.
• Cost vs. Benefit Analysis Changes: In the past, SA was often a no-brainer because you knew a new version was coming (e.g., Windows Server 2016 to 2019) and you’d definitely upgrade, so you’d calculate that SA costs less than buying a new license outright after 3 years. Now, with slower release cadences for some on-premises products and more customers skipping on-premises upgrades in favor of cloud adoption, the calculus may be different. For example, a company might decide to skip SA on a product because they plan to transition off that product in 2-3 years (perhaps moving to SaaS), so paying SA in the meantime is wasted. Microsoft’s shift to cloud makes such scenarios common – why pay for 3 years of SA on SharePoint Server if you intend to migrate to SharePoint Online next year? This thinking reduces the relevance of SA as a long-term investment, as more enterprises focus on subscription transformation projects.
• Support Model Changes: The retirement of SA’s 24/7 support benefit is emblematic of Microsoft’s broader shift to Unified Support. This paid, account-wide support model covers both cloud and on-premises services. Cloud services often come with basic support included in their cost or require a unified support contract, making SA support incidents less relevant. As more of your estate is covered by a unified support agreement (which you must buy separately), the incremental value of SA support tickets vanished – hence, Microsoft killed it. This again shows how SA is less central in the overall Microsoft ecosystem than it once was.

In essence, Software Assurance is less of a focus in a cloud-first world, and its relevance is “diminished” in many scenarios. But it’s not gone – it’s diminishing, like a sunset, but still matters for some legacy and hybrid scenarios (as we covered in the prior section).

CIOs need to recognize this trend: many of the benefits of SA are now available by default in subscriptions or replaced by other programs, meaning you should not reflexively renew SA without reconsidering its necessity.

However, diminished relevance does not mean zero relevance. Microsoft is likely to maintain SA (or its successor constructs) for customers that stay on-prem or need hybrid capabilities, for the foreseeable future.

What CIOs should do is consciously decide where SA adds value versus where it’s an artifact of the past in their organization.

Recommendations for CIOs

• Embrace Subscriptions Where Feasible: If you haven’t already, evaluate moving to Microsoft 365 for your user licensing and cloud services for your infrastructure, as these simplify licensing and often remove the need for SA. This could streamline your licensing management and potentially reduce costs (for instance, no need to pay 25% SA on Office every year if you are on an Office 365 subscription instead). However, conduct a cost analysis to ensure that subscription pricing compared to perpetual + SA makes sense for your scale and duration.
• Identify “SA Orphans”: Identify which products in your portfolio are the only ones using SA. These might be candidates to transition. For example, if Exchange Server on-premises is the last product for which you maintain SA (for upgrades or support), maybe it’s time to seriously plan the migration to Exchange Online, thereby eliminating that need. Or if you have a few Windows Server licenses with SA but most of your servers are already in Azure or AWS, consider if you can convert those to cloud subscriptions too. Reducing reliance on SA simplifies vendor management.
• Watch Microsoft’s Licensing Roadmap: Keep an eye on announcements about licensing program changes. If Microsoft decides to further phase out traditional SA or replace it with something else for on-premises use, you want to be ahead of the curve. We’ve seen announcements like “Software Assurance is not available for CSP” and moves to push EA customers to MCA. A Gartner-style insight would suggest that over the next 3-5 years, Microsoft will continue to make SA less visible, possibly incorporating those benefits into other offerings or requiring cloud subscriptions. Plan your long-term IT licensing strategy with the assumption that SA may not be as readily available or may come at a higher premium for on-premises use in the future.
• Educate Finance on OPEX vs CAPEX: The shift to subscriptions means moving from a CapEx + SA model to a pure OpEx model. Ensure the finance department understands this change. In the past, you might have budgeted for licenses (CapEx) and annual software (SA) costs. Now, with subscriptions, it’s all recurring OpEx. This can be good (more predictable, scalable down if needed) or bad (never-ending payments). Work with finance to align on the approach and highlight that dropping SA is usually part of moving to an OpEx model rather than just “losing benefits”.
• Negotiate Transition Benefits: When renewing an Enterprise Agreement or signing a new Microsoft agreement, leverage the fact that you might be dropping SA due to subscriptions to get some incentives. Microsoft might offer a discount on a Microsoft 365 E5 bundle, for example, if you show you’re eliminating a bunch of SA spend by moving fully to the cloud. Microsoft’s goal is to shift you to the cloud, so use that as a bargaining chip – e.g., “We will drop SA on all our Office and Windows licenses because we’re going to M365 – in return, can you provide pricing protections or extra FastTrack help for the transition?”
• Retain SA Expertise Internally: Even as SA becomes less central, ensure that someone on your team remains knowledgeable about it. In the interim period where you have a mixed environment, licensing complexity is at its peak (some stuff on SA, some on subscriptions). You don’t want to accidentally let SA lapse where it is still needed, nor keep paying it where it’s not. A licensing specialist or SAM manager should regularly review the organization’s approach to SA, especially at EA renewal time.

Retain or Retire? Making the SA Decision in 2025

With all the information above, the ultimate question for a CIO is: “Where should we keep paying for Software Assurance, and where can we safely drop it?”

This section serves as a playbook summary and decision guide for deciding whether to retain or discontinue SA, and provides tips for maximizing any SA you keep.

When to Retain SA (or Equivalent Subscription):

1. Suppose the product is core to your business and new versions are anticipated. In that case, you should keep SA for products like Windows Server, SQL Server, or other server software that you know will be upgraded during your planning horizon. This ensures you can deploy the latest features and security updates without new license purchases. The cost of SA (typically ~25% of license cost per year) will usually be less than purchasing a new license every few years, so if you intend to stay current, SA is worth it.
2. If you need Hybrid Cloud use rights: Retain SA on any licenses you plan to use in the cloud (Azure or third-party). For Azure, if you want to leverage Azure Hybrid Benefit for cost savings, keep SA active. For third-party clouds (AWS, GCP, or hosting), if you might move or extend workloads there, maintain SA for License Mobility rights. Essentially, for any workload mobility or cloud integration scenario, SA is a must. Dropping it could lock that workload to your datacenter or force higher costs later.
3. If you require special SA-only benefits, for example, if you heavily use Disaster Recovery rights (cold backups) or need to frequently reassign licenses in a virtual environment, SA provides those flexibilities. Similarly, if you’re among the few who leverage the Workplace Discount (Home Use) for employees or have a large developer team using the bonus tools (like MDOP), those are factors to keep in mind. While these alone might not justify the SA cost, they add to the value if you’re already leaning towards keeping it.
4. If the product has no good subscription alternative yet, some Microsoft products might still only be available as perpetual licenses (though this list is shrinking). If you rely on such a product and it’s mission-critical, you might need SA to ensure support and upgrades. For example, certain developer tools or specialized server products may not have a cloud equivalent that you can migrate to; hence, you stay on SA to receive upgrades. Also, suppose you’re in an industry where the cloud is not an option for certain systems (due to data residency or compliance requirements). In that case, you will treat those on-premises systems as long-term investments, and SA is your lifeline for keeping them up to date.

When to Let SA Lapse (or Drop at Renewal):

1. If you’re migrating to Cloud/Substitution in <1-2 years: When you have a concrete plan to decommission on-prem licenses in favor of cloud services, continuing SA on those licenses might be wasted money. For example, if you are moving from SQL Server on-premises to Azure SQL or a SaaS solution, once the migration is complete, the old SQL licenses may no longer be needed. In such cases, it might make sense not to renew SA at the next cycle for those licenses – instead, continue using the current version and then retire it. Be careful with timing: if the migration delays, you might end up running an outdated version without support if SA is dropped. So coordinate SA decisions with project timelines (perhaps keep SA until the migration cut-over is complete).
2. If a product is stable and you don’t plan to upgrade or move it, there are often systems that operate in a steady state. For instance, a manufacturing plant might be running a specific version of SQL or Windows for an equipment system that won’t be upgraded for more than 5 years. If you’re confident that you won’t need to upgrade or relocate the system, paying SA annually might be unnecessary. You can let the SA lapse after the current term and run the software with the perpetual license you have. This saves costs, but you must accept the trade-off that if you suddenly need an upgrade in 3 years, you’ll have to buy new licenses at that point (which can be more expensive as a lump sum). In terms of cost, this is like choosing a pay-as-you-go upgrade model over an insurance model. It can be sensible for legacy or end-of-life systems that you intend to eventually phase out without enhancing.
3. If the SA cost outweighs the realized benefits, it’s crucial to assess whether your organization is using the benefits that justify SA. Maybe you kept SA on Windows desktops for years, but now all your desktops are on Windows 10, and you have no immediate need for Windows 11. Alternatively, you could upgrade some via Windows 11 free updates if you’re licensed appropriately. Or you paid for SA on Office, but then moved everyone to Office 365 – so those Office perpetual licenses with SA are sitting unused. These are scenarios where SA spend is not yielding a return. According to one analysis, SA adds around 25% to the license cost each year, so over four years, that’s equivalent to buying the license again. If at that time you haven’t gotten value (no upgrades used, no support calls, etc.), that money is effectively wasted. CIOs should cut those losses and not renew SA on such products. A Gartner-style recommendation is to “optimize or eliminate under-utilized entitlements” – SA is no exception. Use it or lose it.
4. If you switch to a subscription model, this is straightforward – if you transition a workload to a Microsoft subscription or SaaS, you don’t need SA on the old license because you won’t be using it. For example, if you move from Office 2019 with SA to Microsoft 365 Apps, after the switch, you can drop SA (or even drop the perpetual licenses entirely at the next true-up) because your users are now covered by subscription. Similarly, suppose you adopt Windows E5 per-user licensing. In that case, you might decide not to renew Windows OS SA on your device-based licenses since the user subscriptions cover all your usage as we advance. Essentially, avoid double-paying – don’t keep SA on something that you’ve replaced with a subscription, unless there’s an interim overlap period needed for safety.

Maximizing Value of SA (for the benefits you retain): If you do choose to keep SA on certain products, make sure to extract full value from it:

• Upgrade Timing: Plan your upgrade projects to align with your SA term. For instance, if you renewed SA on Windows Server in 2025 and it runs through 2028, you are entitled to any Windows Server released during that window. Encourage your infrastructure teams to schedule upgrades (like moving to Windows Server 2025 or 2026 if that release) before SA expires. If you let SA lapse after 2028, you can still use any version released before then, but not after – so timing matters. Don’t leave upgrades on the table.
• Use AHB and Mobility Aggressively: We’ve emphasized this, but it bears repeating under value maximization. If you’re paying for SA, actively use Azure Hybrid Benefit if you have any Azure footprint – it’s a direct way to recoup SA cost. Similarly, if you have spare capacity on licenses with SA, consider shifting some compatible workloads from expensive cloud instances to BYOL using SA. For example, maybe you have an on-prem SQL that’s lightly used and a heavily used SQL in AWS that you pay hourly for; you could reassign the license to AWS via SA mobility and cut costs. These tactical moves ensure SA is delivering monetary value.
• Employee Benefits (WDP): If you maintain SA on any desktop products (or have Microsoft 365, which grants similar rights), promote the Workplace Discount Program to employees. It’s a morale perk – employees can get Office 365 Personal or Family at a discounted rate at home. While this isn’t a direct ROI for the company, it improves goodwill and usage of Microsoft tech. It was one of those SA benefits that cost you nothing extra, but many companies forget to tell their employees about it. Now it’s open even with minimal requirements, so use it as a value-add of your Microsoft partnership.
• Step-up Licenses: If you foresee needing a higher edition (for example, you own SQL Standard with SA and might need SQL Enterprise for an upcoming project), use the Step-up license benefit instead of buying new full licenses. With SA, you can pay the difference to upgrade to a different edition. This can save a lot if that scenario arises. So keep an eye out to see if any of your SA-covered products have a higher edition that could solve a problem, and leverage the step-up to get it at a prorated cost.
• Leverage Microsoft’s Help: When you have SA, you often have a Microsoft account team or licensing partner who can help you utilize it. Don’t hesitate to ask Microsoft, “We have these SA benefits, what’s the best way to use them before they expire?” For example, even though Planning Services was retired, Microsoft now often provides FastTrack assistance for cloud deployments for free – ensure you take advantage of it if eligible. FastTrack eligibility often comes with having certain licenses, such as Microsoft 365, and a specific number of seats. For support, while SA’s free incidents are no longer available, Microsoft sometimes offers a “Unified Support credit” or trial for SA customers. Check if your organization qualifies so you can get a head start on the new support model. Essentially, squeeze every possible benefit (old or new) out of the fact that you’re an SA customer.

To conclude this section, making the SA decision is about weighing the ongoing cost vs. the strategic benefits. A balanced approach often works best: keep SA for the areas that truly need it (or where it pays off), and trim it where it’s not needed. It’s not all-or-nothing; you might, for example, keep SA on your server products but drop it on your desktop products. Or even within servers, keep SQL but drop a no-growth product like BizTalk if you’re phasing it out. Microsoft allows license-level or product-level SA choices at renewal, with some programmatic nuances, so you can fine-tune this.

Above all, tie the decision to your IT roadmap – if SA aligns with enabling that roadmap (such as upgrades, cloud migrations, or flexibility), it’s likely worth it; if it doesn’t, then it might be an unnecessary legacy expenditure in the cloud era.

Recommendations for CIOs

• Perform an SA Value Assessment: Before each Enterprise Agreement renewal (or annually if on Open/MPSA), perform a structured assessment of each product’s SA. Include stakeholders: app owners, infrastructure, cloud strategy, and finance. Determine for each: are we using it, and do we need it as we advance? Use a scoring system or at least a discussion to decide whether to retain or drop each product. This ensures a conscious decision rather than inertia.
• Adopt a Selective SA Strategy: It’s perfectly acceptable (and often optimal) to be selective with SA. Keep SA for what you need; drop it for what you don’t. Don’t feel compelled to have a blanket approach. Microsoft might offer blanket coverage, but you can negotiate an EA that, for instance, covers Windows and SQL with SA, but not Office perpetual without SA, because you plan to drop those. Document this strategy so that everyone understands why certain things are covered and others are not.
• Communicate Decisions and Implications: If you decide to let SA lapse on certain products, notify the relevant IT teams of the implications. For example, “We are not renewing SA on Visio because most users moved to Visio Online; this means the remaining Visio 2016 users won’t get Visio 2022 automatically – if they need it, we’ll have to buy new licenses or subscriptions at that time.” Setting this expectation avoids confusion later (“why can’t we upgrade, we always did before?”). Similarly, highlight areas where you did keep SA: “We renewed SA on SQL Server precisely so that you can upgrade to SQL 2022 next year for our analytics project – please go ahead and plan that upgrade.”
• Monitor SA Utilization: Treat SA like any other investment – track the benefits used. For instance, track how many Azure VM cores are using Hybrid Benefit, how many licenses have been upgraded this year thanks to SA, etc. This information is powerful in justifying the next SA renewal; you can, for example, show that SA saved the company $ 500,000 in license costs or cloud costs. If you find utilization is low, it might indicate over-investment, prompting a rethink.
• Be Prepared to Re-enter SA if Needed: If you drop SA on a product but later find you need those benefits again, remember that you can typically re-enroll licenses in SA at the next agreement, although this may incur a penalty or only be possible if the product is currently supported. Microsoft often has a SKU for “Software Assurance only” purchase if you already own a license. Keep this in mind as a safety: dropping SA now isn’t irreparable – you could, in a future EA, add SA back (or purchase a subscription that confers equivalent rights). It might cost a bit more at that time (especially if new versions have been released), but it’s an option. This means you can make bold decisions now, knowing you’re not completely cutting off future flexibility (just be mindful of rules, like you usually can only add SA to the current version of a product, so if you skip too many versions, you might have to buy a full license again to then add SA).
• Leverage Partners and Gartner Advice: Finally, don’t decide in a vacuum. Consult with your Microsoft licensing partner or seek advice from firms (or Gartner analysts) who specialize in software licensing optimization. They can provide benchmarks (“X% of enterprises our size have dropped SA on productivity software after cloud migration” or “We see many keeping SA on SQL until they are 100% in Azure”). Such insights can validate your plan or help you identify something you missed. Given the high stakes (potentially millions in licensing fees), a bit of outside perspective can be very valuable.

Do you want to know more about our Microsoft Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit