When the components beat the bundle, when they do not, and the arithmetic that decides it. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
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 thirteen of forty. Last session we established that the E3 to E5 step up pays only where something gets switched off, and we ended with a mixed estate: E5 for the roles that use the delta, E3 for the rest, and a middle band where the answer was neither. Today is that middle band. Buying capability piecemeal, one component at a time, attached to the base plan a person already holds. And I want to set expectations honestly, because this is a session where the answer genuinely depends on your numbers. Components are cheaper than the suite up to a point, and past that point they are more expensive, and the point moves depending on your rates. So the deliverable is not a rule. It is a calculation you can run in an afternoon, plus a reconciliation that most estates have never done and that tends to pay for the afternoon several times over.
Five takeaways. One, the rules: add ons need a qualifying base plan and must sit on the same user, which sounds purely administrative until it starts producing unusable licences on your price sheet. Two, the families: security, compliance, voice, analytics, and AI, and knowing the family tells you immediately whether E5 already covers it. Three, the duplication: standalone security add ons duplicated E5 features in four estates out of ten, and voice add ons sat unused on ten to twenty percent of assigned seats. Four, the three routes: step up, fresh licence at the higher tier, or attach the component, which is the same capability at three prices that are rarely quoted together. Five, the crossover: past three or four components the suite usually wins, below that the parts usually do, and finding your own line is a single afternoon of arithmetic.
How add ons actually work, three rules, and these are mechanics rather than pricing. They decide what is possible before price decides what is wise. First, a qualifying base is required. Every add on attaches to a base plan and the terms define which bases qualify, so an add on quoted without an eligible base underneath it is not a cheaper route to the capability, it is a line that cannot be assigned to anybody. You met that in session ten as a mismatch on a price sheet. Second, same user, same seat. The add on and its base sit on one person, and you cannot buy a hundred components and spread them across a pool of people who share the workload. That is the counting discipline from session eight arriving in a new place. Third, some add ons require a specific tier underneath, which means the cheap looking component route can quietly imply a base plan upgrade, and at that point it is no longer the cheap route. Check the prerequisites in the Product Terms before you model any piecemeal option.
The add on families, five of them, and the third column is the one to read as a checklist. Security: Defender components, Entra premium. Often overlaps E5, and this is the single largest source of duplicate spend in the estates we have reviewed. Compliance: Purview, eDiscovery, insider risk. Often overlaps too, bundled inside E5 and then bought again on E5 seats. Voice: Teams Phone and calling plans, which does not overlap E5 at all. That is a genuine separate purchase, and frequently an idle one. Analytics: Viva components and Power BI Pro, partly overlapping, because Power BI Pro is in E5 while the Viva set varies. And AI: Microsoft 365 Copilot, which does not overlap, is priced separately on top of E3 or E5, and is never bundled into either. Two of these five overlap heavily, one does not overlap at all, and the mistake that costs the most is a security or compliance add on bought for a seat that already holds E5.
First check. Your estate has four thousand E5 seats and nine hundred standalone security add ons. Where should you look first? A, nowhere, more security is always better. B, at whether those nine hundred add ons sit on E5 seats, because standalone security add ons duplicated E5 features in four estates out of ten and the duplication is invisible until somebody joins the two lists. C, at whether the add ons are being used. D, at the contract, to see if they can be cancelled. Pause it. C and D are both reasonable second steps, so as you think, ask yourself what has to be established before either of them makes sense.
The answer is B, and the reason C and D are premature is that a duplicated add on looks completely healthy on its own terms. It is assigned. It is deployed. It may well be generating alerts. So a usage review passes it, and a contract review finds a live service being paid for as agreed. The problem only appears when you put the add on assignment list beside the base plan assignment list and find the same user on both. Across the add on stacks reviewed for this course, standalone security add ons duplicated E5 features in four estates out of ten, and removing that duplication cut add on spend by fifteen to thirty percent where it was tested. A is the belief that produces those numbers, because security spending is treated as beyond question and therefore never reconciled, and I have some sympathy for how organisations get there. The order matters: join the lists, find the overlaps, run usage on what remains, then look at the contract for the ones you intend to stop.
Where the duplication hides, five places. Bought tactically, never reconciled: add ons get purchased in response to a specific incident or project and then never checked against a base plan that changed afterwards. That is the entire mechanism, and notice it is administrative rather than technical. The upgrade that made it redundant: a seat moves from E3 to E5 and the component bought for it eighteen months earlier keeps billing, because the upgrade project owns the licence change and nobody owns the add on. Voice sitting idle: ten to twenty percent of assigned seats, and since voice does not overlap E5 this is not duplication, it is straightforward shelfware, which makes it the easiest of the five to measure. Components on the wrong tier: standalone add ons make sense mainly on E3 seats, so on an E5 seat a component is usually either a duplicate or a specific exception somebody should be able to name. And the reconciliation nobody owns, where the base plans sit with one team and the components with another.
Guest analyst There is a particular kind of finding that I find harder to deliver than a big one, and this is the example. Insurance group, about seven thousand seats, and they brought us in because their Microsoft bill had a category they called other that had grown to a size nobody could explain. So we asked for two exports. Base plan assignments, and add on assignments. They came back as separate files from separate teams, which was the first clue, and when we joined them on the user column we found around two thousand two hundred people holding a standalone security component on top of an E5 base that already included the same capability. Now here is why I say it was hard to deliver. Every one of those had been bought properly. There had been a security incident in twenty twenty two, a component was purchased as part of the response, and it was the right call at the time because those users were on E3. Eighteen months later a separate programme upgraded that population to E5, and the upgrade was also the right call. Nobody made a mistake. The two decisions were correct in isolation and the combination was waste, because the base plan sat with the platform team and the components sat with security, and no single person had ever seen both lists in the same room. What they changed was small. One named owner, one join, once a year, tied to the true up date. The recovered spend was a little over four hundred thousand a year and not one control was removed from anybody.
Two correct decisions, eighteen months apart, and the combination was waste. One join, once a year. Second check.
Check two. A persona needs two E5 capabilities out of the full set. Which route is likely to be cheapest? A, upgrade to E5, the bundle is always better value. B, attach the two components to the E3 base, because below roughly three or four components the parts normally beat the suite, and the calculation is per persona rather than per estate. C, buy E5 for half the persona and E3 for the rest. D, wait for the renewal and decide then. Pause it. The answer here is a calculation rather than a principle, so as you think, work out what you would need in front of you to actually run it.
The answer is B, and what you need in front of you is short: your net E3 rate, your net E5 rate, and the standalone rate for each component at your own discount. Three numbers and a subtraction. Two components is well below the crossover in almost every estate I have seen. A is the bundle reflex, and I want to be careful about it, because it is true often enough to be genuinely dangerous. It is right above the crossover and wrong below it, which is exactly why the arithmetic has to be run rather than assumed. C splits a persona that your own data says is homogeneous, which gives you two populations to administer and no analytical basis for choosing who goes where. D is the answer that quietly costs the most across this entire course, because a decision deferred inside a term is a decision made in favour of the current shape. One thing to verify before committing to the component route: check the prerequisites, because a component requiring a higher base underneath is not the cheap option it appeared to be.
Three ways to buy the same capability, and the point of this slide is that they are rarely quoted together. The step up SKU moves an existing licence up a tier for the remainder of the term. Its own part number, priced against what you already hold, usually the cheapest way up mid term, and the one least often volunteered when the alternative is a fresh licence. A fresh licence at the higher tier means buying E5 outright rather than stepping up from E3: cleaner administratively, normally more expensive mid term, perfectly reasonable at a renewal boundary and hard to justify in year two. And the component: attach only what the persona needs to the base they already hold, cheapest below the crossover, and it keeps the base plan decision separate from the capability decision, which is worth something on its own at the next renewal. The buyer side habit is simply to ask for all three prices in writing, for the same population, on the same sheet, at the same time. The differences are frequently large.
The crossover, worked. One component: the parts win comfortably, so attach it and revisit only if that persona's needs grow. Two: still the parts in most estates, so attach both and diary a check at the next true up. Three: this is the line, and it genuinely depends on your rates, so run the arithmetic properly because both answers are defensible at three. Four or more: the suite usually wins, so step up, and record which components you stop buying, because that record is what stops you paying for them anyway. And the last row, which matters more than it looks: anything plus Copilot. Copilot is priced separately on top of either base and is never bundled into E3 or E5, so it should never pull the base plan decision with it. If a proposal justifies an E5 upgrade using Copilot value, two independent lines have been mixed together and they need separating before anybody approves anything. That is the next check.
Last check. A quote bundles the E5 step up and Copilot as a single per user uplift. What do you ask for? A, nothing, a single uplift is simpler to approve. B, the two lines priced separately, because they are two independent negotiations and a combined uplift hides which part you are paying for and which you may never use. C, a deeper discount on the combined figure. D, a trial period on the whole bundle. Pause it, and as you think, ask which of those two lines you could still change your mind about later.
The answer is B, and separating the lines is the single most reliable move in this part of the stack. It costs nothing to ask for and it changes what you can do afterwards. The E5 step up is a security and compliance decision, tested by the retirement arithmetic from last session. Copilot is an AI adoption decision, tested by measured usage, which is module four. Different owners, different evidence, different timelines. Combine them and the weaker case travels on the stronger one's approval, which is the entire reason bundles are constructed that way. A prefers administrative convenience to knowing what you bought. C negotiates the size of a number whose composition you do not know, which is the session ten error wearing different clothes. D is closer to sensible, and a trial on the Copilot line alone is genuinely a good idea, but a trial on a combined bundle still leaves you unable to say afterwards which half delivered the value.
The piecemeal method, three steps, run once a year. One, join the lists: base plan assignments beside add on assignments, matched by user. Every row where a component sits on a base that already includes it is a candidate for removal, and every row where a component sits without a qualifying base is a correction rather than a negotiation. Two, price the three routes: for each persona needing more than its base, step up, fresh licence, and components, at your own rates, three columns. The winner is frequently not the one that was proposed to you. Three, name the owner: one person accountable for the annual reconciliation, with a date in the calendar tied to the true up. That third step is what stops the same duplication reappearing, and it is the one most often left implicit. Estates that tested this recovered fifteen to thirty percent of their add on spend without removing a control anybody was using, which is unusually clean money.
Session thirteen, three sentences. One: add ons need a qualifying base on the same user, and two of the five families overlap E5 heavily, so a component bought for an E5 seat is usually either a duplicate or an exception somebody should be able to name out loud. Two: there are three routes to the same capability, step up, fresh licence, and component, and asking for all three on one sheet is the habit that keeps the cheapest one visible. Three: below roughly three or four components the parts win and above it the suite does, and Copilot sits outside that arithmetic entirely because it is priced separately on top of either base. Next session takes the question that this one keeps bumping into, which is what sits above E5, and the answer is more interesting than most people expect.
Homework, about an hour, and this week you reconcile your add ons. One, export the add ons: every attached component, the user it sits on, and what you pay for it, and most estates have never had these in one place at one time. Two, join to the base plans, matched by user, and flag every component sitting on a base that already includes the capability. Three, check the orphans: any component without a qualifying base underneath it, which are unusable licences and therefore a correction rather than a negotiation. Four, measure the voice lines: calling add ons with no usage in ninety days, and expect somewhere between ten and twenty percent of the assigned seats. Five, price one persona three ways: pick whichever persona has the most components attached and price step up, fresh licence, and components side by side. Keep that sheet, because it goes straight into the renewal file.
Five reads before next session, all free on redress compliance dot com. First, every Microsoft 365 add on explained, which carries the families, the prerequisites, and the E5 overlap in full. Second, Microsoft 365 add ons and duplicate cost, on the duplication patterns and what removing them actually recovered. Third, maximising security and compliance with E5 add ons, which is the component route for estates where the full suite is not justified. Fourth, the E3 to E5 decision framework again, because the staged path it describes is what the crossover arithmetic supports. And fifth, Microsoft 365 apps standalone licensing, which is the other direction entirely: buying below the suite rather than above it, and relevant for more personas than most estates assume. Next session is E7 and the top of the stack. What is confirmed, what is assumed, and how to plan a tier strategy without betting a three year commitment on a roadmap. See you there.