Support renews annually, automatically, and without a meeting, and over a decade it usually outgrows the licenses that created it. Module 4 opens by taking the machine apart: the 22 percent base set at purchase, the uplift that doubles bills across a decade, the license sets and policies that stop the number ever falling on its own, the honest value question as products age into sustaining support, and the baseline audit that sorts a real $1.2M bill into value, shelf, ghosts, and frozen versions.
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.
A taught session with three knowledge checks: the flat 22 percent budgeting error, the partial termination that repricing quietly defeats, and the $180K of ghost support found billing on systems decommissioned two years ago. It closes by dissecting a $1.2M support bill into $700K of value and a $500K gap that is the module's syllabus.
The full narration of this session, section by section, for reading and reference.
Welcome back, session sixteen of forty, and welcome to module four. For fifteen sessions, one number has appeared in nearly every worked example, every knowledge check, every decade total: twenty two percent. The support annuity. It shadowed the discount in session nine, it shaped the ULA fee in module three, it's been quietly compounding in the background of every deal we've priced. Today it stops being background. Module four is five sessions on support and renewals: today the economics, then the two policies that lock the bill in place, then the real reduction options, then third party support, and finally the renewal negotiation itself. And here's why this module may be the most valuable one in the course, in pure dollar terms: support is where Oracle makes its margin, it renews automatically every year without a meeting, and in most estates nobody, literally nobody, owns the number. By the end of today you'll understand the machine completely, and you'll have dissected your own bill into what's real, what's shelf, and what's ghost. Let's open the invoice.
Five takeaways. One, you'll explain the machine: exactly how the twenty two percent annuity gets set, uplifted, folded, and protected, five moving parts, most of which you've already met in disguise. Two, you'll price the compounding, projecting any support stream a decade forward at real uplift rates, and the numbers are bigger than almost anyone budgets. Three, you'll name the one way valves, the specific mechanisms that stop the bill from ever falling on its own, because you can't defeat a design you haven't diagrammed. Four, you'll judge the value side honestly, what support actually buys, and how that changes as products age through premier, extended, and sustaining tiers, because the invoice stays flat while the value curve falls. And five, you'll audit the baseline: your own support bill, sorted into needed, shelf, ghost, and frozen, the one honest page that every later move in this module prices from. A quiet promise about this module: nothing in it requires a lawsuit, a fight, or a bluff. It requires reading, sorting, and showing up on the one day a year the number can be challenged. That's it.
Four numbers. Twenty two percent of net license fees, every year, set at purchase. You know this one; session nine taught that every discount point cuts this base forever, which means your support negotiation actually started years ago, whether anyone attended it or not. Three to eight percent, the annual uplift range in recent years, and the top of that range is new: uplift used to hug the low single digits, and the recent inflation era pushed it to levels that change the arithmetic materially. Roughly ten years: at high single digit uplift, that's about how long a support stream takes to double. Quietly, automatically, invoice by invoice, while attention is elsewhere. And one: the number of leverage moments per year, the renewal date. Between renewal dates, support asks receive sympathy; on the date, with notice periods respected and alternatives priced, they receive answers. The note under the tiles explains the whole module in one sentence: support is widely understood to be Oracle's most profitable business, with margins reported above ninety percent. Hold that fact; every policy, every valve, every negotiation behavior in the next five sessions is downstream of it.
How the annuity works, five parts, and watch how many you already know. Part one, the base: twenty two percent of net license fees, fixed at purchase. The discount shadow from session nine, now seen from the other side: the single most effective support negotiation ever available was the license discount, years ago. Part two, the uplift: an annual increase applied at renewal, historically low single digits, recently as high as eight percent, and it compounds, next slide makes that visceral. Part three, the license set: support doesn't really attach to individual licenses, it attaches to sets of licenses grouped on a customer support identifier, a CSI. The set, not the license, is the unit the policies protect, and that distinction is where next session lives. Part four, the policies: the technical support policies, session six's moving target, incorporated by reference and updated by Oracle, governing what renewal means, what termination costs, and how sets behave. And part five, the autopilot: renewal is annual and administrative by default. The invoice arrives, references last year plus uplift, and pays itself through accounts payable unless somebody deliberately intervenes. Add it up and notice: nothing here is hidden or tricky. The machine is simply built so that doing nothing is always the most expensive option. And doing nothing is the default. Now, the compounding.
One million dollars of net licenses, ten years of support, three uplift scenarios. With no uplift, the fantasy scenario: two hundred twenty thousand a year, two point two million over the decade. Already more than double the license spend, and that's the floor. At four percent uplift, the historical norm: year five reaches two fifty seven, year ten hits three thirteen, and the decade totals two point six four million. And at eight percent, the recent reality for some estates: year five is two ninety nine, year ten is four hundred forty thousand, double the starting stream, and the decade totals three point one nine million. Sit with the shape of that for a second. A one million dollar license purchase commits the company to between two point two and three point two million dollars of support over the following decade, which means the support decision embedded in every purchase is two to three times larger than the license decision everyone spends months negotiating. And in the deal itself, the support line gets, typically, zero minutes of negotiation, because it's just the standard twenty two percent, and the uplift is just the standard uplift. Session eight taught the fix, the cap clause, and session nine taught the base cut, the discount. Today's table is why both of those sessions were worth your time. Knowledge check one.
Knowledge check one. A colleague budgets Oracle support as a flat twenty two percent of what was paid for the licenses, forever. Accurate? A, yes, twenty two percent of net is the formula, permanently. B, no: twenty two percent of net sets year one, and the annual uplift compounds the bill upward from that base indefinitely. C, no, support is renegotiated from scratch each year. Or D, yes, as long as the licenses stay deployed. Pause here. What happens to the number in year two?
The answer is B. The formula sets year one; the uplift owns every year after, and at recent rates it owns them aggressively. The table you just saw turns a two hundred twenty thousand dollar stream into four hundred forty by year ten at eight percent, so the budget built on flat twenty two percent is roughly half a million dollars short across the decade, per million of licenses. Multiply by your estate. A is the single most common budgeting error in Oracle land, and it's why support creep ambushes finance teams every single year, the error isn't dramatic, it's just annual. C describes a world we'd all prefer: renewal as genuine renegotiation. The design is the opposite, administrative continuation plus uplift, and converting it into an actual negotiation requires deliberate effort on a specific date, which is session twenty's entire subject. D adds a condition that has never existed: deployment is irrelevant to the invoice. Support bills on the license set whether the software runs production workloads, idles in a forgotten VM, or was uninstalled during a data center exit three years ago. That last case has a name, ghost support, and we're hunting it later this session. The practical moves: model the uplift in every budget, cap it wherever session eight's clause can reach, and mark the renewal date, because it's the one day the compounding can be interrupted.
Why the bill never goes down on its own, four one way valves. Valve one, the set is protected. The matching service levels and repricing policies work as a pair: drop support on part of a license set, and the remainder reprices upward, typically stripping the discounts off the surviving licenses. The result: partial termination often saves far less than arithmetic suggests, sometimes nothing. That mechanism deserves and gets its own session, next week's session seventeen. Valve two, shelfware bills forever. The unused licenses from session nine's inflated basket, the padding that was effectively free at purchase, they sit inside license sets accruing full support, year after year. The free products have been billing twenty two percent of their net since the day they were bought, exactly as predicted, and the valve means removing them isn't simple. Valve three, fold ins ratchet. Every new purchase, every migration deal, every ULA folds support streams together, and merged streams inherit the highest applicable base. Fold ins are where support quietly steps up during deals everyone celebrates. And valve four, the human one: nobody owns the number. The invoice renews administratively, often split across cost centers, each fragment below anyone's approval threshold. The design assumes inattention, and in most estates, the assumption holds for decades. Let's test valve one properly. Knowledge check two.
Knowledge check two. An estate pays support on three hundred licenses; one hundred are confirmed unused. Terminate support on the hundred, save a third of the bill? A, yes, support is per license, so a third of the licenses is a third of the bill. B, usually not that simply: repricing policies recalculate the remaining two hundred at higher effective rates, often erasing much of the saving. C, no, because support can never be terminated on anything. Or D, yes, provided the hundred licenses are uninstalled first. Pause here. What happens to the price of what remains?
The answer is B, and this mechanism is the single most important fact in module four. Terminate support on part of a license set, and the policies recalculate the remainder: the discount that priced the original set gets stripped from the survivors, whose support reprices toward list. The result is grimly elegant: the bill on two hundred licenses lands remarkably close to the old bill on three hundred, the saving evaporates, and the estate concludes, wrongly, that nothing can ever be done. A is the naive arithmetic the policies were specifically designed to defeat; assume it in a business case and the business case explodes on contact. C draws the wrong conclusion from the right observation: reduction is absolutely possible, full set terminations, license set restructuring, recontracting, third party moves, all real, all practiced, all in session eighteen, but they're engineering projects, not cancellation emails. The difference between C's despair and eighteen's playbook is understanding this one mechanism. D repeats the deployment confusion: uninstalling changes operations, not invoices. So the honest frame for the module: the bill can come down, people cut seven figures from it every year, but it's a designed against activity, and the design is two specific policies with names. Next session is those two policies, read line by line, with the legitimate paths around them. Today, the value question.
What the money actually buys, because honesty cuts both ways, four points. Point one, the real goods: patches, security updates, new versions, and the right to raise service requests. For current products under active development, running production workloads, this is genuine value, and pretending otherwise leads to bad decisions. The module's goal is right sizing, not zealotry. Point two, the aging curve. Products move through support tiers: premier, roughly the first five years, then extended, then sustaining. Sustaining support, and this deserves emphasis, means no new patches, no new security fixes, no new certifications, at an undiminished and still uplifting price. Estates pay full freight for sustaining support on ancient versions constantly, usually without knowing it. Point three, the version question: an estate frozen on an old release for years, no upgrade planned, is buying updates it never takes. The value received curve falls toward zero; the invoice curve continues rising at uplift. Where those curves have crossed, and only you can see it, the renewal is a habit, not a purchase. And point four, the honest inventory, per product: which tier, which version, when was the last patch actually applied, is an upgrade genuinely funded? Four questions that sort every support line into worth it and momentum. This inventory is also, not coincidentally, exactly the groundwork session nineteen's third party conversation requires. The frames, next.
Five frames on the same invoice, and the buyer who can hold all five negotiates differently. Frame one, Oracle's: an annuity at margins reported above ninety percent, contractually protected, compounding annually, the crown jewel of the business model. Nothing in their behavior makes sense until you see the invoice the way they do; once you do, everything does, including why the valves exist. Frame two, the TCO frame, yours: license plus a decade of support is the real price of everything, session nine's lesson graduated into permanent policy. Every purchase decision, every basket item, every ULA fee gets evaluated on the decade number, always. Frame three, the discount shadow: the base is twenty two percent of net, so every point of discount won at purchase cuts the annuity forever. Support negotiation begins years before the first renewal invoice, in the license deal, which is why sessions eight and nine keep paying dividends here. Frame four, the leverage calendar: one renewal date per stream per year. Between dates, nothing moves; on the date, with notice given and alternatives priced, things move. The calendar is the negotiation infrastructure. And frame five, the alternatives horizon: third party support exists, at roughly half price, session nineteen examines it properly. Whether or not you ever use it, its priced existence disciplines every renewal conversation you'll ever have. Five seats, one machine. Now, your own bill.
The support baseline audit, four steps, and this is the operational heart of the session. Step one, reconcile the CSIs. Every support line traced back to its ordering document and its license set: which purchase created this stream, at what base, covering which licenses. This is session six's entitlement library doing support duty, and every line you can't trace is a finding by definition, because you're paying for something nobody can name. Step two, sort the licenses, per set, into four piles: deployed and needed, deployed but replaceable, shelfware, and retired. The four piles price completely differently in every later move, and the sorting is where most of the audit's hours go. Step three, hunt the ghosts: support billing on licenses whose systems were decommissioned years ago. Data center exits, platform migrations, project cancellations, each one tends to leave support streams running behind it, because the infrastructure team that turned off the servers has never once seen the support invoice. Ghost support is more common than any estate expects and it is pure, recoverable waste. And step four, map the calendar: every renewal date, every stream, twelve months forward, with the notice period each requires and an owner named per date. The leverage calendar from the frames, made real. Four steps, roughly a week of effort for a mid size estate, and the findings fund the week by lunchtime on day two. Ghost hunting practice. Knowledge check three.
Knowledge check three. The baseline audit finds one hundred eighty thousand dollars per year of support billing on licenses whose systems were decommissioned two years ago. What now? A, keep paying, terminating support is impossible anyway. B, stop payment immediately and dispute the old invoices. C, verify the set is genuinely separable, check the repricing effect on anything remaining, then terminate at the renewal date. Or D, redeploy the licenses somewhere to justify the spend. Pause here. What must be checked before the obvious move?
The answer is C. Ghost support is the easiest money in this module, but even easy money follows the process, three checks. First, verify separability: are these licenses their own set, on their own CSI, or entangled with active licenses? Full set terminations are clean and avoid the repricing trap entirely; partial ones walk straight into knowledge check two. Second, model the after: if anything shares the set, price the surviving licenses post repricing before booking the saving, because a hundred eighty thousand recovered that triggers a hundred sixty thousand of repricing elsewhere is a very different project. Third, execute at the renewal date, with the notice period the policies require, in writing, clean and contractual. Done in that order, this is a hundred eighty thousand dollars a year, recovered with a spreadsheet and a letter, and versions of this exact finding exist in most large estates. The wrong answers: A has the helplessness backwards, declining to renew support on a full set at its renewal date is squarely, boringly within your rights. B converts a winnable termination into a payment dispute, breaching your way out of a contract you could simply not renew; never hand them the high ground for free. And D is the sunk cost fallacy wearing a hard hat: deploying unneeded software to justify its support bill spends real engineering effort converting waste into busier waste. Find the ghosts, check the sets, wait for the date, send the letter. Let's see the whole bill.
One support bill, dissected, a composite estate paying one point two million a year, sorted by the audit. Category one: active, current, needed, seven hundred thousand. Real products, current versions, production workloads, patches actually applied. This is genuine value; the play here is capping the uplift and negotiating the renewal properly, session twenty, not cutting coverage. Category two: shelfware sitting in mixed sets, two hundred sixty thousand. The padding from old deals, entangled with active licenses precisely so the repricing valve protects it. This is session eighteen territory: restructuring, recontracting, the engineering paths. Category three: ghost support, one hundred eighty thousand, retired systems, and in this estate the set proved separable, so it terminates at renewal, saved, the audit paying for itself thirty times over. And category four: sustaining support on frozen versions, sixty thousand, full price for no new patches on products that will never be upgraded. That's the third party conversation, session nineteen, waiting to happen. The summary line: one point two million invoiced, roughly seven hundred thousand of genuine value, and the half million gap is module four's syllabus. Here's the uncomfortable part: these proportions, roughly sixty percent real, forty percent gap, show up in estate after estate after estate. Yours is unlikely to be the exception. The audit is how you find out. That's the session.
Session sixteen in three sentences. One, support is twenty two percent of net at purchase and an uplifted, compounding annuity ever after, which makes the decade of support larger than the license deal that created it, and the support decision the biggest unexamined line in most purchases. Two, the bill never falls on its own because the machine has one way valves, protected sets, repricing, fold ins, and administrative autopilot, all engineered around the assumption that nobody is watching, an assumption that holds in most estates for decades. Three, the counter begins with the baseline audit, one honest page sorting the invoice into value, shelf, ghosts, and frozen versions, because every move in the rest of this module prices off that page. Next session goes to the heart of the machine: matching service levels and repricing, the two policies behind the valve, read properly, clause by clause, with the legitimate paths around them mapped. If this session explained why the bill behaves as it does, next session explains exactly how, and the how is where the money is. See you in session seventeen.
Homework, about an hour, all of it on your own numbers. One, project your streams: your three largest support lines, ten years forward, at four percent and at eight percent uplift. Put both curves in front of finance and watch the faces; this single chart has funded more licensing programs than any argument ever made. Two, run the four way sort on one CSI: needed, replaceable, shelf, retired. One set, one hour, and the proportions you find are your estate's version of today's dissection. Three, hunt one ghost: cross reference one support renewal against the asset register or the decommissioning records. Systems that were switched off with support streams still running are worth real, recoverable money, and the first one usually isn't the last. Four, check the tiers: which of your products sit in premier, extended, or sustaining support? Any sustaining line is full price for no new patches, write those down for session nineteen. And five, build the calendar: every Oracle support renewal date in the next twelve months, each with its notice period and an owner's name. That calendar is the negotiation infrastructure for the entire module, and most estates have never had one. That's the hour. See you in session seventeen, where we read the two policies.
Five reads, all free on redress compliance dot com. First, optimizing your Oracle license footprint before renewal, the baseline audit extended into a full cost reduction program, today's step four with teeth. Second, the Oracle support renewal contract checklist, key clauses and best practices, the paper side of every renewal line you just audited. Third, Oracle renewal negotiation strategy, the leverage calendar worked into an actual strategy, preparation for session twenty. Fourth, the Oracle vendor management guide, which answers the organizational question this session kept raising: who owns the number, and what does owning it look like as a discipline. And fifth, the Oracle renewal negotiation checklist, session twenty's playbook in checklist form, worth reading early so the next four sessions land on prepared ground. That's session sixteen. An annuity set at purchase, compounding on autopilot, protected by valves, renewed by inattention, and countered by one honest page and one date a year. Module four is underway. Next session: the two policies at the heart of the machine. See you there.