What it actually buys, what it costs as a percentage, which benefits get used, and when keeping it is genuinely wrong. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session nine of forty. Last week we looked at metrics, and one of the distinctions we drew was between subscription and perpetual: what you rent, and what you own. Today we look at the thing that sits on top of the owned part, Software Assurance, which is a recurring percentage attached to your perpetual licences. And SA is interesting for a specific reason: it is one of the largest recurring costs in a Microsoft estate that almost nobody audits, because it arrives as a percentage on a line rather than as a purchase decision with a business case. Today: what SA actually is and, importantly, what it is not, the benefit list, the gap between benefits paid for and benefits claimed, the genuine case for dropping it, and the cloud interaction that frequently reverses the whole analysis. Let me flag that last one now: for any workload heading to Azure, SA is often the most valuable line on your quote. Let's find out whether yours is.
Five takeaways. One, what it is: a recurring percentage attached to perpetual licences, and the difference between an upgrade right and a maintenance contract, which is not a pedantic distinction, it protects a lot of unexamined spending. Two, the benefit list: what the programme actually includes beyond upgrade rights, and which entries carry real cash value for a typical estate rather than brochure value. Three, what actually gets used: the gap between benefits you pay for and benefits anybody claims, which is where an honest analysis has to start. Four, the drop case: the specific circumstances where dropping SA is genuinely right, and the consequences that make it a one way door in practice. And five, the cloud interaction, Azure Hybrid Benefit and migration rights, which is where SA quietly becomes the largest saving in a migration business case. One promise: this session does not have a predetermined answer. Some estates should drop SA and some absolutely should not, and the point is to know which one you are.
What SA is, three things to be precise about before any value judgement. It rides on perpetual licences: SA attaches to licences you own, and subscriptions already include their own upgrade path, so this is a question about the perpetual part of your estate, servers mostly, plus whatever desktop perpetual remains. It is a recurring percentage: charged annually as a proportion of licence value, which means it compounds with every licence you add, and it is one of very few costs in your estate that grows automatically without anyone making a decision. And it buys rights plus a benefit list: the headline is version upgrade rights, while SA is current you may move to new versions, and around that sits a list of benefits whose value varies enormously between estates, which is the substance of today. Now the note, which matters more than it looks: SA is not support. Support is bought separately. Conflating the two is extremely common and it protects a great deal of spending, because the moment somebody believes dropping SA means nobody will answer the phone in an incident, the conversation ends before it starts. It does not mean that. Those are two different purchases.
The benefit list, six rows, and I want you to read this as a portfolio rather than as a package. Version upgrade rights: move to new versions while SA is current, worth money to estates that actually upgrade on a cycle and worth nothing to estates that do not. Cloud migration rights: use owned licences against cloud compute, and this is the big one, it gets its own slide later. Deployment and planning services: funded planning days, worth real money to an estate running a major deployment, if anybody claims them. Training vouchers: a structured training entitlement, valuable where training is planned centrally and invisible where it is not. Home use and roaming rights: extended use rights for staff, which matter for distributed workforces where policy allows it. And spread payments: annual rather than upfront licence cost, a genuine treasury benefit and one that is routinely overstated in sales conversations, because a payment schedule is not a discount. Read as a portfolio, some of these entries are worth many times their cost to a particular estate and literally nothing to the estate next door, which is exactly why the answer to should we keep SA is always specific and never general.
First check. A CFO asks why you pay Software Assurance on a server estate you have not upgraded in four years. The most complete answer: A, it is mandatory on enterprise agreements. B, it is insurance in case we need support. C, it buys upgrade rights we have not used, plus a benefit list that includes cloud migration rights, so the honest answer is an audit: value the benefits this estate actually uses or plans to use, and compare that against the recurring percentage. Or D, dropping it would breach the agreement. Pause here. Which of the benefits on that list applies to an estate that never upgrades, and which applies to one that is about to migrate?
The answer is C, and I want to say something about the question itself first: the CFO is right to ask it, and it deserves a real answer rather than a defensive one. An estate that has not upgraded in four years is genuinely not getting value from the headline benefit, and saying so out loud is the beginning of a credible analysis rather than an admission of failure. It may still be getting very large value from cloud migration rights if any part of that estate is heading to Azure, which is the slide after next and which frequently reverses the conclusion entirely. A and D are the reflexes that keep unexamined costs alive for years, and both are simply wrong: SA is a purchasing choice, not a requirement, and no agreement is breached by declining it. B conflates SA with support, which we just separated, and that confusion protects an enormous amount of spending that has never been justified because the conversation always stops there. So the correct method is the audit: value the benefits actually used or credibly planned, compare against the recurring cost, and reach a conclusion that could legitimately go either way. That is what makes it analysis rather than a position.
What actually gets used, five points, and there is a pattern in them worth naming at the end. Upgrade rights: genuinely valuable to an estate on an upgrade cycle, worth nothing to an estate sitting on a version for six years, and check your actual upgrade history rather than your upgrade intentions, because those two differ in most organisations. Planning services: funded days that expire unclaimed in most estates, because nobody owns the claiming process, which makes them a real entitlement and an unreal benefit. Training vouchers: exactly the same pattern, valuable where somebody schedules them and invisible where nobody does, and both outcomes are extremely common. Cloud migration rights: the exception to the pattern, because this benefit gets claimed automatically by anyone using it, since it shows up as a reduction in cloud compute cost rather than as a form somebody has to remember to fill in. And there is the rule: benefits that require an action get forgotten, benefits that apply automatically get used. So audit the first group ruthlessly and count the second group honestly. Our guest analyst has a story about the first group.
Guest analyst The Software Assurance conversation I remember best started as a cost cutting exercise and ended somewhere completely different. A financial services client, substantial server estate, and their new CFO had done exactly what a good CFO does: found a recurring line nobody could explain and asked why it existed. The instruction to me was, in effect, help us drop this. So we audited it, and two things came out. The first was that they had accumulated a significant number of planning services days and training vouchers, entitlements they had been paying for across several years and had claimed almost none of, because the person who used to handle it had left in 2022 and nobody had picked it up. Not a scandal, just an ownership gap, and I see it constantly. We claimed what was still claimable, which was worth a meaningful fraction of a year's SA on its own. The second finding was the one that changed the decision: their infrastructure team had a funded plan to move a large part of the SQL estate to Azure within two years, and Azure Hybrid Benefit on those licences was worth several times the annual SA cost. Dropping SA would have saved a percentage and forfeited a multiple. So the answer to the CFO was: you are right that we were not using this, and here is the value we just recovered, and here is why we are keeping it on this specific set of workloads and dropping it on that one. That is the shape of a good SA decision. It is per workload, it is written down, and it survives the next person who asks the question.
An ownership gap since 2022 leaving entitlements unclaimed, and a hybrid benefit worth several times the annual cost on the workloads that were moving. Keep on some workloads, drop on others, written down. That is the shape of a good SA decision. Second check.
Check two. Your SA audit finds unclaimed planning services days and training vouchers worth a meaningful fraction of the annual SA cost. What follows? A, nothing, unclaimed benefits are the customer's own fault. B, two actions: claim what is claimable now, since these entitlements expire, and assign an owner so the claiming happens annually, which converts a paper benefit into a real one and changes the SA arithmetic in the process. C, drop SA immediately, since the benefits are clearly not being used. Or D, ask Microsoft to refund the unclaimed value. Pause here. An unclaimed benefit has two possible fixes. Which one do you try before deciding SA is not worth it?
The answer is B, and the framing is that there are exactly two ways to close a gap between what you pay for and what you use: stop paying, or start using. C reaches for the first without trying the second, and that is premature when the benefits are genuinely useful to your organisation and simply unclaimed, because claiming them costs an owner and a calendar entry rather than money. Tom's client recovered a meaningful fraction of a year's SA that way, before any decision about the programme itself. A is true as an observation and useless as a response, and it is the kind of true statement that ends conversations that should continue. D asks for a refund of an entitlement that was available and went unused, which no programme of this kind provides. What makes B complete is the sequencing: claim now because entitlements expire, assign the ownership so next year is different, and only then run the SA arithmetic again with the benefits properly valued. If the numbers still say drop after you have started using what you already pay for, that conclusion is now defensible in front of anyone. Which brings us to when dropping is genuinely right.
The case for dropping, because it exists and this course is not here to defend vendor spending. When it is right: a stable estate on a version it intends to keep, with no cloud migration planned for that workload, no upgrade cycle, and no claimed benefits. In that situation SA is a recurring percentage buying rights the estate will never exercise, and dropping it is simply correct. What you keep: the perpetual licences themselves, frozen at the version you own, and that is a real asset that keeps working, which is precisely the difference between perpetual and subscription from session eight, and it is worth being clear about because people confuse dropping SA with losing their software. You do not lose it. You stop receiving new versions. And what it costs to reverse: reinstating lapsed SA is deliberately expensive and often simply unavailable, so a drop should be treated as a one way door and modelled across your whole horizon rather than as this year's saving. Then the note, which is the trap: dropping SA on an estate that later migrates to Azure forfeits the hybrid benefit on those licences, which is frequently worth more than every year of SA you saved. Check the cloud plan before touching the SA line. Always.
SA in a cloud estate, four situations. Migrating servers to Azure: hybrid benefit lets your owned licences offset cloud compute, and this is often the single largest saving in a migration business case, large enough that it changes whether the migration is approved. Hybrid estate, on premises plus cloud: licences can serve both sides under the right terms, so dropping SA can strand the on premises asset in a way nobody anticipated. No cloud plans for that workload: the hybrid benefit is dormant value, and this is a genuine drop candidate, provided the plan really is stable rather than merely unstated. And cloud plans within the horizon: the benefit becomes cash at migration, so you keep SA and model the saving into the migration case, where it belongs. The reason this table exists, and the note says it plainly: SA decisions belong with the cloud strategy rather than with the licensing renewal. The right answer for the identical set of licences changes completely depending on whether that workload is moving in the next three years, which means the licensing person cannot make this decision alone and neither can the infrastructure person. Last check is exactly that conversation going wrong.
Last check. An infrastructure team proposes dropping SA on a large SQL estate to save the recurring percentage. A migration of that same estate to Azure is scheduled in eighteen months. The analysis: A, drop it, the saving is certain and the migration is not. B, keep it and model the hybrid benefit into the migration case: dropping SA forfeits the ability to apply those licences against Azure compute, which is typically worth more than the SA saved, and reinstatement afterwards is expensive or unavailable. C, drop it now and repurchase licences at migration. Or D, keep SA indefinitely regardless of the plan. Pause here. What does SA let you do with an owned licence when the workload moves to Azure?
The answer is B, and this is the trap from the previous slide arriving dressed as a sensible cost saving, proposed by people acting in good faith. Azure Hybrid Benefit lets licences with active SA offset cloud compute cost, so on a large SQL estate that benefit typically exceeds several years of the SA percentage, and dropping SA eighteen months before the migration forfeits exactly that, permanently. Now I want to be fair to A, because it contains a real argument: the saving is certain and the migration is a plan, and plans slip. If the migration genuinely is not funded and not resourced, A may well be right, and the honest way to make that case is to challenge the migration plan directly rather than to quietly assume it will not happen. That is a much better conversation to have. C is the expensive route, repurchasing licences at migration costs far more than maintaining SA through to it. And D is the mirror image of A, a policy substituting for an analysis, which this course argues against in every module. The general rule: SA is priced against the cloud plan for the same workloads, and those two decisions cannot be made in separate rooms by people who do not talk to each other.
The SA method, three steps, run once a term rather than argued annually. Audit the benefits: list what SA provides for your estate, mark each entry used, claimable, or irrelevant, and value the used and claimable ones at what they would cost to buy separately, which is the only fair way to price them. Map the cloud plan: for every workload carrying SA, is it moving in the next three years, because hybrid benefit turns dormant value into cash at migration and that single conversion decides most of these cases. And decide by workload: SA is not an all or nothing estate decision, and treating it as one is why these conversations become religious. Keep it where upgrades or migration are real, drop it where the version is frozen and the workload is staying, and document both decisions with their reasons, so that when the next CFO asks the question, and they will, the answer takes four minutes rather than four weeks. Next session closes module two with the quote itself: the price sheet, the SKU names, the bundles, and the arithmetic to run before any discount conversation starts.
Session nine, three sentences. One: SA is a recurring percentage attached to perpetual licences that buys upgrade rights plus a benefit list, and it is not support, which is a separate purchase and a confusion that protects a great deal of unexamined spending. Two: benefits requiring an action get forgotten while benefits applying automatically get used, so the first response to an unused benefit is to claim it and assign an owner rather than to cancel the programme, and only then to rerun the arithmetic. Three: Azure Hybrid Benefit usually makes SA the most valuable line on the quote for any workload heading to the cloud, which is why SA is decided per workload alongside the cloud plan rather than as an estate wide policy, and why dropping it eighteen months before a migration is the expensive version of a good instinct. Next week, reading a Microsoft quote, and module two closes. See you there.
Homework, about an hour, and this week you audit your own SA. One, find the SA line: what you pay annually, on which licences, as a percentage, because most estates know the total and cannot break down the composition, which is itself the finding. Two, check the upgrade history: which products carrying SA have actually been upgraded in the last three years, history rather than intention, and be honest, because the intention version of this table is always more flattering. Three, count the unclaimed: planning services days and training vouchers available and unused, claim what is still claimable, and name an owner for next year, which is Tom's client recovering value before making any decision at all. Four, map the cloud plan: for each workload with SA, is it moving to Azure within three years, marked yes, no, or unknown, and treat every unknown as a question for your infrastructure lead this week rather than a permanent state. And five, decide by workload: one line each, keep, drop, or decide at renewal, with the reason written next to it. That table is your SA position and it will survive the next CFO question comfortably.
Five reads before next session, all free on redress compliance dot com. First, the Microsoft licensing guide, for where SA sits inside the wider programme structure. Second, Microsoft licensing implications for cloud migration, which covers hybrid benefit and migration rights, and is the decisive factor in most SA decisions, so read it before you make one. Third, the Azure licensing and cost optimisation playbook, for where owned licences reduce cloud spend, worked through with numbers. Fourth, the piece on alternatives to Microsoft Unified Support, because the support question is genuinely separate from SA and the two get conflated constantly, and separating them properly can be worth as much as the SA decision itself. And fifth, Microsoft SAM and licence optimisation, the practice that keeps the benefit audit current between renewals so that nobody inherits an ownership gap in 2028. That is session nine. SA is a portfolio not a package, unclaimed is not the same as worthless, and the cloud plan decides most of it. Next week, the quote. See you there.