The one way valve on the support bill has two named parts: matching service levels, which forces all or nothing within a license set, and repricing, which recalculates the survivors of any partial termination. This session reads both policies in plain language, runs the repricing table that kills naive business cases, maps the set boundary where the policies' reach ends, previews the five legitimate paths around them, and teaches the order structure discipline that buys termination freedom for free.
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 support-production-only plan that matching service levels blocks, the separate set termination that repricing cannot touch, and the one-order-or-two purchasing decision that decides a decade of freedom. It closes with two estates, identically discounted, ten years and $310K a year apart on order structure alone.
The full narration of this session, section by section, for reading and reference.
Welcome back, session seventeen of forty. Last session ended with a promise: the one way valve on the support bill has two named parts, and today we take them apart. The names are matching service levels and repricing, they live in the technical support policies, session six's incorporated by reference document, and between them they explain nearly every failed attempt to reduce an Oracle support bill in the last two decades. Here's why this session matters more than its dry title suggests: most estates believe support reduction is impossible, and they believe it because someone once tried the obvious move, got quoted these policies, watched the saving evaporate, and gave up. The policies are real. But they have boundaries, precise ones, and everything on the right side of those boundaries works. Today: both policies in plain language, the repricing arithmetic run live, the boundary where their reach ends, the legitimate paths around them, and the set architecture discipline that keeps future purchases out of their grip entirely. Twenty minutes of policy reading, worth six figures a year to most estates. Let's read.
Five takeaways. One, you'll read both policies, what matching service levels and repricing actually say, as opposed to the folklore versions that circulate in most IT departments. Two, you'll model a termination: the repricing table gets built for every reduction candidate before anyone writes to Oracle, because the naive arithmetic and the real arithmetic differ by eighty percent. Three, you'll see the pincer, how the two policies mesh so that within a set, the only clean moves are full support or full termination. Four, you'll know the paths, the five legitimate routes around the pincer, previewed today and worked in depth next session. And five, the sleeper takeaway, you'll architect the sets: every future purchase structured so the policies have less to grip, a discipline that costs minutes at signature and buys termination freedom for a decade. One reframe before we start: these policies are not traps in the paper you signed. They're published, knowable, and mechanical. An estate that reads them plans around them; an estate that doesn't funds them. Reading is the whole advantage.
Four numbers. Two, the policies with names: matching service levels and repricing. Session sixteen's valve, disassembled into its parts, and each part is a page of published text, not a secret. One, the license set, the unit both policies operate on, and the most underappreciated concept in Oracle cost management. Your freedom to reduce, restructure, or exit support is decided almost entirely by where your set boundaries fall, and those boundaries were drawn by purchase orders, some of them a decade old, signed by people thinking about discounts, not architecture. Approximately zero, the typical net saving from a naive partial termination once repricing recalculates the survivors, we'll run that table live in a few minutes, and it's the single most clarifying piece of arithmetic in the module. And one hundred fifty percent, the reinstatement mathematics if support lapses and is wanted back, the number that makes most reduction moves effectively one way, next session works it fully. The homework this session is unusually literal: read your current technical support policies, the actual document, twenty minutes. Every plan in the rest of this module stands on those pages. Policy one, first.
Matching service levels, in plain language, four points. The rule: all licenses in a license set must be supported at the same service level. One set, one level, no mixing. The intent it blocks, and be honest, you've thought of this one: support production, drop support on dev and test. It's the first idea every cost reviewer has, it would cut bills by half across the industry, and it is precisely the move this policy exists to prevent. The set boundary: a license set generally spans the licenses of a program and its related options acquired together, and here's the practitioner's warning, Oracle construes relatedness broadly when broad helps them. Options bought with a database, licenses merged through migrations, streams folded together at renewals, all of it tends to agglomerate into larger sets over time, and larger sets mean less freedom. And the practical test, the question that starts every reduction conversation from now on: what exactly is the set? Not what do we want to drop, but what is the contractual unit we'd be dropping from. The answer comes from orders and CSIs, not from intuition, and it decides whether a plan is possible before anyone prices it. Policy two is the enforcement mechanism.
Repricing, in plain language, four points. The rule: terminate support on part of a license set, and the support fee for the remaining licenses gets recalculated, at current pricing, which typically means the discount that priced the original deal gets stripped from the survivors. The effect: the per license cost of what remains rises to fill most of the gap the termination created. You dropped a third of the licenses; the bill dropped a fifteenth. The design, and it deserves admiration as engineering even while you're planning around it: repricing converts every partial reduction into a pricing event that favors Oracle. The estate that tries to shrink politely ends up roughly where it started, minus the goodwill, which teaches most estates to stop trying, which is the point. But the fourth point is where your strategy lives: the boundary. Repricing operates on the set being modified. A genuinely separate set, from a separate order, on its own support stream, is a separate question entirely, and terminating it whole triggers nothing anywhere else. The policies grip within sets. They do not reach across them. Hold that sentence; the entire reduction playbook hangs from it. First knowledge check.
Knowledge check one. An estate wants to keep full support on its production licenses and drop support entirely on identical dev and test licenses that came from the same purchase. Allowed? A, yes, support is per license, and you choose which licenses to cover. B, generally no: matching service levels requires the whole license set at one level, and same purchase licenses are one set. C, yes, if the dev and test servers are physically separate. Or D, no, because dev and test licenses can never be terminated. Pause here. What is the unit the policy operates on?
The answer is B. The set is the unit, and these licenses share a set because they shared an order. Matching service levels is precisely the rule the obvious economy violates: one set, one level, all or nothing, and production plus dev from the same purchase is one set. Proposing the split to Oracle doesn't open a negotiation; it invites a policies citation and a polite no. The wrong answers each teach something. A describes how everyone assumes support works before reading the policy, per license choice is exactly the freedom the policy removes, and the gap between assumption and text is where budgets get surprised. C is the hardware fallacy, appearance number six in this course, physical separation has never been the test of anything, and it isn't starting today. D overshoots in an instructive way: the licenses absolutely can be terminated, support and license are different things, and here's the twist worth savoring, if dev and test had been bought on their own order, their own set, dropping their support whole would be clean and legitimate. Which means this estate's real problem isn't the policy. It's a purchase order from years ago that fused production and dev into one contractual unit, signed in thirty seconds, priced across a decade. The last section of today exists so you never sign that order again. Now, the arithmetic.
Repricing, priced live, and this table is the module's most important thirty seconds. The before: one license set, three hundred licenses, bought years ago at a sixty percent discount, currently paying three hundred thousand a year in support. The plan: the audit found a hundred of those licenses unused, so terminate them, and the naive arithmetic says the bill drops to two hundred thousand. A hundred thousand saved, the business case writes itself, someone drafts the letter. Now the after, with the policy applied: the termination is partial, so the surviving two hundred licenses reprice. At current pricing. Which means the sixty percent discount that priced the original set gets stripped, and the survivors recalculate toward list rates. New bill: two hundred eighty one thousand. Actual saving: nineteen thousand dollars. Not a hundred thousand, nineteen, the saving shrank by more than eighty percent, and the business case that wrote itself just died in its first meeting with reality. The numbers are illustrative; the mechanism is exact, and it's why the standing rule of this module is: every reduction plan gets this table built, with your real numbers, before anyone writes to Oracle. Plans that survive the table are real. Plans that don't were always mirages. Now, the boundary where the mirage machine stops working.
Knowledge check two. An estate holds two CSIs from two separate purchases, three years apart: database licenses on one, a retired middleware platform on the other. Does terminating the middleware set reprice the database set? A, yes, all Oracle support reprices together. B, generally no: repricing operates on the set being modified, and a full termination of a genuinely separate set leaves other sets untouched. C, yes, unless Oracle grants an exception. Or D, no, but only if the middleware was never installed. Pause here. Where does the policy's reach actually end?
The answer is B, and this boundary is the most valuable fact in the entire support module. The policies grip within a license set. They do not reach across sets. The middleware platform, bought separately, on its own order and CSI, is its own contractual unit: terminate it whole, at its renewal date, with proper notice, and the database set never hears about it, no repricing, no recalculation, nothing. This is why session sixteen's ghost hunt asked about separability before celebrating, and why next session's playbook starts every move with set mapping. The wrong answers: A is the folklore version of the policies, grimmer than the real ones, and it's the belief that keeps overpaying estates paying, the policies are tough but bounded, and knowing the bounds is the difference between despair and a program. C inverts the mechanics, you don't need an exception to make a move the policies permit; asking for permission you don't need teaches the other side you don't know your rights. D drags deployment back in, installation status remains irrelevant to billing, as it has been all module. One field caution, because it matters: verify set boundaries from the paper, the orders, the CSIs, the migration history, never from assumption. Sets merged by past fold ins can be larger than they look, and the time to discover that is before the notice, not after. The paper decides. It always has. Now watch the two policies mesh.
How the two policies mesh into the pincer, four movements. Movement one: matching service levels blocks the level cut. Within a set, no supporting half, no mixed tiers, no production only economy. The support-less-of-it option, removed. Movement two: repricing punishes the count cut. Within a set, terminating some licenses reprices the rest, the support-fewer-of-them option, neutralized, as the table showed, to about nineteen cents on the dollar. Movement three, the combination: within any single set, the only clean moves left are full support or full termination. Everything between the two extremes is designed to disappoint, and does. Once you see it, you stop proposing intermediate moves and start engineering around sets, which is exactly the shift this session exists to cause. And movement four, the ratchet that completes the machine: session sixteen's fold ins. Every consolidation, every migration, every helpful merge at renewal time makes sets larger, and larger sets put more licenses behind the same all or nothing door. The pincer tightens by default, over years, without anyone deciding anything. Which is why the counter isn't a tactic, it's an architecture, and it's coming two slides from now. First, the paths that work despite everything.
The legitimate paths, five of them, previewed today, worked fully next session. Path one, full set termination, the clean kill: a complete, separable set nobody needs, terminated whole at its renewal date. No survivors, so nothing reprices. Ghost support dies here. Path two, restructure and repurchase, the engineering route: buy a right sized new set at negotiated prices, then terminate the old bloated set entirely. The shelfware trapped in mixed sets escapes this way, and only this way. Path three, the ULA reset: module three's machinery, entry and certification events restructure support streams wholesale, one of the quiet reasons ULAs get signed at all. Path four, third party support: move whole sets to an independent provider at roughly half cost, session nineteen's entire subject, with tradeoffs that deserve their own hour. And path five, the negotiated reduction: Oracle concedes support relief at leverage moments rather than lose a stream entirely, real, recurring, and never once offered unprompted, you'll see the mechanism next session, and it looks exactly like a termination notice followed by a phone call. Notice what all five share: they work at the set level, on renewal dates, with notice, inside the rules. The pincer channels; it doesn't imprison. Now, the prevention.
Set architecture, the discipline that starts today, four practices. Practice one, map what you have: every CSI, every set boundary, verified from the orders, annotated onto session sixteen's audit. You cannot plan around walls you haven't drawn, and most estates have never drawn them. Practice two, and this is the money practice: separate the separable. From now on, new purchases for unrelated platforms go on separate orders, deliberately, creating separate sets. It costs nothing, literally nothing, at purchase, the discounts negotiate the same, and it buys clean termination rights for the life of the licenses. There is no better return on thirty seconds of procurement discipline anywhere in this course. Practice three, resist the merge. At renewals, Oracle periodically offers to consolidate streams, tidy the CSIs, simplify the billing. Read those offers through today's lens: a merged set is a bigger hostage, and the simplification mostly simplifies the pincer's grip. Decline politely. And practice four, write it into the deal: session eight's markup gains a standing line, orders structured per workload, and where the leverage allows, termination and repricing carve outs negotiated at signature, when they cost a sentence. Some buyers get them; all buyers should ask. Final check, and it's a purchasing decision.
Knowledge check three. A two million dollar purchase covers two unrelated platforms: a core ERP database that will run forever, and an analytics experiment. One order or two? A, one order, bigger baskets negotiate better discounts. B, two orders: the experiment may die, and a separate set can be terminated cleanly without repricing the ERP estate. C, one order, but with the platforms listed on separate lines. Or D, it makes no difference to anything downstream. Pause here. Which platform might you want to stop paying for someday?
The answer is B, and the reasoning is a rehearsal for every purchase you'll ever influence. Run the futures: the ERP database is permanent; the analytics experiment is, by its own name, an experiment. If it dies in year two, and experiments die, that's what makes them experiments, a separate order means its licenses are a separate set, terminated whole at renewal, clean, final, with the ERP stream untouched. One combined order means the dead experiment's licenses live inside the ERP set forever, where matching service levels forbids dropping their level and repricing devours any attempt to remove them. A hostage situation, constructed voluntarily, at signature, for zero benefit. And A's benefit really is zero: discount tiers don't turn on whether one order or two arrive in the same deal, session nine's negotiation covers the combined basket either way, closed the same week, at the same numbers. You give up nothing and gain a decade of freedom. C is cosmetic, line items don't create set boundaries, orders do, the structure is contractual, not typographic. D is what everyone believed before this session, and it's the belief that built every mega set currently holding an estate hostage somewhere. The rule, permanently: structure orders by workload lifecycle. Termination freedom is free at signature and unaffordable ever after. Let's watch ten years of that rule.
Two estates, same products, same discounts, same decade, different order structure. The mega order estate bought the way the paperwork suggests: everything consolidated, big orders, streams merged at renewals whenever offered, tidy and simple. Ten years later it holds one giant license set, and inside that set sit two retired platforms, still billing three hundred forty thousand a year, untouchable, because extracting them means partial termination, and partial termination means repricing the entire estate. The licenses are dead; the support is immortal; the pincer holds. The structured estate bought the same things with thirty seconds more thought: orders per workload, merges declined with thanks, a carve out negotiated where leverage allowed. Ten years later it holds six clean sets, and when two platforms retired, their sets terminated whole, at renewal, with notice, no repricing, nothing touched elsewhere. Three hundred ten thousand a year, recovered, boring, permanent. The difference between these two estates was never negotiation skill or discounts or luck. It was order structure, decided in minutes at each signature, by whoever in the room understood sets. After today, in your company, that's you. That's the session.
Session seventeen in three sentences. One, matching service levels forces all or nothing within a license set, and repricing punishes partial terminations by recalculating the survivors toward list, together forming the one way valve session sixteen diagnosed. Two, the policies grip within sets and stop at set boundaries, so separability is everything: full terminations of complete, separate sets are clean, and all five paths around the pincer work at the set level, on renewal dates, with notice. Three, set architecture is the prevention: orders structured per workload lifecycle, merges declined, carve outs asked for at signature, because termination freedom costs nothing today and everything tomorrow. Next session, the playbook proper: all five reduction paths worked in depth, termination analysis, restructure and repurchase mechanics, the unsupported deployment decision with its one way door, the business case that survives review, and the retention counter offer read correctly, as the mechanism working. The policies were the walls. Next session is the doors. See you in session eighteen.
Homework, about an hour, and item one is the whole point. One, read your policies: the current technical support policies document, the matching service levels and repricing sections specifically. Twenty minutes of actual reading, once, and every reduction conversation you ever join gets sharper. Two, map one set boundary: pick a CSI, trace exactly which licenses share its set, from the orders, not from memory. The answer is usually broader than anyone expects, and the surprise is the lesson. Three, reprice one plan: take any support reduction idea currently circulating in your company and build today's table for it, real numbers, net of repricing. Most ideas die honestly at this step, and the survivors become next session's program. Four, audit the mixed sets: from session sixteen's four way sort, which shelfware sits in sets shared with active licenses? List them; they're the restructuring candidates next session prices. And five, fix the next order: whatever Oracle purchase is next in your pipeline, check whether it should be two orders instead of one, this week, before it signs. That single intervention may be worth more than the rest of the module combined. See you in session eighteen.
Five reads, all free on redress compliance dot com. First, the Oracle support renewal contract checklist, the policies and clauses line by line, today's two policies in their full context. Second, optimizing your Oracle license footprint before renewal, set aware reduction planning in program form, the bridge to next session. Third, Oracle renewal negotiation strategy, where the pincer meets the negotiation calendar, and how prepared buyers time their moves. Fourth, how to check your Oracle license position, the tracing techniques for connecting sets and CSIs back to their orders, today's mapping homework with tooling. And fifth, the Oracle vendor management guide, set architecture as a standing procurement discipline rather than a one time fix. That's session seventeen. Two policies, one pincer, a boundary where their reach ends, five paths through, and an architecture rule that costs thirty seconds per purchase. The walls are mapped. Next session, the doors: the reduction playbook in full. See you there.