An Oracle cost program is a schedule, not a list of ideas
It is governed by dates you do not control, and by levers that behave very differently once you look at what each one returns, how long the cash takes to arrive, and whether you can undo it. The programs that miss their number rarely pick the wrong levers. They run them in the wrong month, and the most common single loss is a support termination notice date that passed while the business case was still being socialized.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on roughly 60 to 80 Oracle cost programs run 2024 to 2025.
Executive summary
Sequence by expiry, not by size, because the option that disappears first outranks the bigger one with no deadline.
The lever with a notice date 40 days away outranks the larger lever with no deadline at all, so a metric change or platform move with a long lead time can safely start in month three while a support notice date cannot wait.
Missing that date does not delay the saving by a month; it delays it by a year, converting a decision you have already made into another twelve months of fees.
The most common single loss across our programs was exactly that missed notice date, so rank the levers by the date the option disappears, then by yield per week of effort, and treat size as the third criterion, not the first.
Savings percentages do not add, because every lever shrinks the base the next lever applies to.
On a 10 million dollar support line, retiring shelfware worth 10 percent then moving half the remainder to third party support at half the fee reads naively as 35 percent, but the actual sequence takes the base to 9 million, halves 4.5 million to save 2.25, and lands at 3.25 million, not 3.5.
And the gap widens with every added lever.
Time to cash varies by a year: a cloud right-sizing lands in next month's invoice while a shelfware retirement lands at the next support anniversary, which may be eleven months away. So a program reporting only total savings looks like it is failing for its first two quarters.
Promise the CFO a run rate at a date, not a percentage in a year.
Three levers are one-way doors, so model the reversal cost before you serve any notice.
Support termination on a support identifier, a metric or definition change written into an amendment, and a ULA certification cannot be reversed cheaply, or at all: reinstating terminated support is priced at current terms and is usually worse than never having moved.
And a certification fixes the license count from its date permanently.
A product split to third party support reprices what stays, because removing products from a support identifier can recalculate the remaining fee, so model the whole line after the split, not the saving on the products that move.
Read the repricing language in the ordering document before you scope the split, and keep one family you could still move so the lever is not fully spent.
Fix compliance before you reduce support revenue, and never run the two in the same quarter.
Where a compliance gap was remediated in the same window as a support reduction, the estate drew Oracle attention within the following year far more often than where the two were separated, so close the gap first, let at least one quarter pass, then reduce.
Two pairs of moves must not share a quarter: compliance remediation and support reduction, and support reduction and a request for commercial relief, because you would be asking the person whose forecast you just cut to give you something.
And cutting cloud consumption below a fixed commitment saves nothing, because Universal Credits are prepaid and forfeited at term end, so cloud efficiency only converts to cash at the commitment boundary or where you already run over it.
The lever table: yield, time to cash, and reversibility
| Lever | Yield against its line | Time to cash | Reversible | Main risk |
|---|---|---|---|---|
| Cloud waste removal | Low to moderate on the cloud line | Next monthly invoice | Yes | Saves nothing under a fixed commitment |
| Escalator cap on support | Compounding, small in year one | Next anniversary, then yearly | Not needed | Traded for a commitment you did not need |
| Shelfware retirement | Moderate on net license and support | Next support anniversary | No, or expensively | Retiring something quietly in use |
| Product split to third party | Around half the fee on products that move | Day after the current term ends | Rarely, never cheaply | Patch access and repricing of what stays |
| Java estate move | Large where the population is large | Next subscription renewal | Technically yes, commercially no | Runtime validation, unmanaged installs |
| Cloud commitment resizing | Moderate to large where over-committed | Only at the commitment boundary | Once a term | Undersizing, then overage at order rates |
| Metric or definition change | Can be the largest of all | On amendment | No | Accepting a metric that reprices you later |
Two observations from that table matter more than the individual rows: the fastest cash is in the cloud line and the largest cash is in support and licensing.
That is why a program reporting only on total savings looks like it is failing for its first two quarters, and why the reporting has to be run rate at a date rather than a headline percentage.
Premier support runs at 22 percent of net license fees a year with an annual uplift, and five levers sit on that line unequally recoverable: the escalator cap is cheapest and most durable, asked early and treated as a term not a discount.
Co-terming removes optionality so do it only where you would never move one line without the other; the matching-service-levels rebuttal anchors against the support policy in force at the original ordering date; the product split reprices the remainder; and full termination is the one-way door.
The layer-of-the-stack argument sits in the total cost optimization guide, and the support checklist in the support renewal checklist.
Four waves, each with an entry condition and an anchor date
- Wave 1, Map, months 0 to 3: the spend baseline, entitlement, deployment, and every renewal and notice date, entry condition for everything else. Pull three years of invoices, separate net license, support, cloud and Java, and build the date map, the artifact most programs skip.
- Wave 2, Quiet fixes, months 2 to 6: compliance remediation, cloud waste and feature-usage cleanup, which cannot start until the deployment picture is reconciled and owned. Close over-deployment quietly here, before any commercial move is visible to Oracle.
- Wave 3, Structural, months 5 to 10: shelfware retirement, product split, Java estate move and metric work, which cannot start until compliance is clean and at least one quarter has passed. Retiring shelfware before you know what is deployed removes licenses you are actually using.
- Wave 4, Commercial, months 9 to 12: renewal negotiation, escalator cap and cloud commitment resizing, which cannot start until the footprint you are negotiating over has already shrunk.
- The entry conditions are not bureaucracy: they are the difference between a program that delivers and one that generates a compliance claim in year two, because reducing support revenue before compliance is clean invites a review into an estate that is not ready. The date map anchors to the terms in the Oracle licensing guide.
The Oracle CIO complete playbook
The five year plan to control Oracle spend, the operating model, and the levers, worked end to end.
Get the white paper →The last safe date, and the pairs you cannot run together
A last safe date is the final day on which you can still change a renewal without buying another full year, and every support lever has one, sitting earlier than most teams assume because your own approval time has to fit inside it.
Work backward from the anniversary: minus the contractual notice period, commonly 30 days but confirmed per support identifier because it lives in the ordering document rather than a general policy, minus two weeks of legal review for a termination notice.
Minus four to six weeks of internal approval, longer if a board threshold is crossed.
That arithmetic puts the real decision date roughly four months before the anniversary, and a program that reaches the anniversary with the decision unmade has not delayed the saving by a month, it has delayed it by a year.
Two pairs of moves must not share a quarter: compliance remediation and support reduction, so close the gap first, let a quarter pass, then reduce, because running both together points a review at an estate that has just changed.
And support reduction and a request for commercial relief, because you would be asking the person whose forecast you just cut to give you something, so separate them by at least one quarter and preferably by a renewal.
When an audit opens mid-program three workstreams stop, any unserved termination notice, any deployment change that alters the picture under examination, and any commercial ask that depends on the same account team, while two continue, the baseline and date-map work which is now more valuable.
And cloud efficiency which touches nothing under review.
A ULA expiry overrides the program calendar because certification is irreversible and dated, so model the certify-against-renew comparison at least twelve months before the window. The audit track runs in the audit negotiation guide and the certification in the ULA negotiation guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Oracle cost programs, 2024 to 2025
Across roughly 60 to 80 Oracle cost programs Fredrik Filipsson and the Redress team ran between 2024 and 2025, the programs that missed their number rarely picked the wrong levers, they ran them in the wrong month, and the common advice is what leads them there.
The common advice is to start with the biggest lever, on the reasonable theory that the biggest number deserves the most attention. We disagree:
A missed support termination notice date, which converts a decision already taken into another full year of fees, was the single most common single loss.
When business cases that added lever yields together met reality, because each lever had already shrunk the base of the one after it.
Cost programs are governed by expiry, not by size: the largest lever, usually a metric change or a platform move, has a long lead time and no deadline, so it can safely start in month three, while the small lever with a notice date forty days away cannot wait at all.
Nobody loses an Oracle cost program on lever selection; they lose it on a notice date that passed while the business case was still being socialized.
Redress runs the program as a dated plan with an owner per lever, not a workshop series: the date map is built in the first three weeks, Wave 1 is fixed price and short so that if the baseline shows nothing to recover we say so and stop.
Every lever gets a named internal owner because we do not run levers you cannot staff, and reporting is run rate at a date rather than a headline percentage.
Promise the CFO the exit run rate you expect twelve months out, the in-year cash this fiscal year, and the two levers that would change both if they slip, because that framing survives contact with reality and a single headline percentage does not.
Costing the program its credibility exactly when it needs to ask for the hard decisions.
The Java lever detail sits in the Java audit guide, the cloud mechanics in OCI cost optimization, and the operating model that keeps it alive between renewals in the Oracle CIO playbook.
Your first five moves
- Build the date map before the business case: every anniversary, every notice date, every commitment end date, on one page, anchored to the specific ordering documents.
- Mark the last safe date for each support lever, counting notice, legal and internal approval back from the anniversary, which lands the real decision roughly four months out.
- Reconcile deployment against entitlement and close any gap quietly in wave 2, before anything is visible to Oracle, and leave at least one quarter before any support reduction.
- Model the overlap, not the sum: sequence the levers in the model exactly as you intend to run them, because each shrinks the base of the next.
- Check the cloud commitment position before funding efficiency work, because under a fixed commitment it returns nothing, and book the negotiation for wave 4 against a footprint already reduced. The Oracle practice runs the plan with you.
Frequently asked questions
In what order should Oracle cost levers be run?
By expiry first, then by yield per week of effort, and only then by size. The biggest levers, usually a metric change or a platform move, have long lead times and no deadline, while a support notice date forty days away disappears permanently if you miss it.
Sequence by the date the option disappears, not by the size of the number, because size is the third criterion and a missed notice date converts a decision already taken into another full year of fees.
Why do Oracle savings percentages never add up?
Because each lever shrinks the base the next lever applies to.
On a 10 million dollar support line, retiring 10 percent of shelfware then moving half the remainder to third party support at half the fee reads as 35 percent but actually delivers about 32.5, because the shelfware retirement already reduced the base the third party move applies to.
Business cases that add published lever yields together promise a number the program cannot deliver, and the gap surfaces in month nine. Model the levers in the sequence you intend to run them.
How far before a support anniversary is the decision really due?
Roughly four months, once you count the contractual notice period, legal review and internal approval backward from the anniversary.
The notice period sits in your specific ordering document rather than a general policy, commonly 30 days but confirmed per support identifier, then two weeks for legal and four to six weeks for internal approval.
Missing that last safe date does not delay the saving by a month, it delays it by a year, because you have bought another full annual term.
Which Oracle cost levers cannot be reversed?
Three: support termination on a support identifier, a metric or definition change written into an amendment, and a ULA certification.
Reinstating terminated support is priced at current terms and is usually worse than never having moved, a metric change reprices you permanently, and a certification fixes the license count from its date.
A product split to third party support is also effectively irreversible and reprices what stays, so model the reversal cost and the whole remaining line before you serve any notice.
Does cutting Oracle cloud consumption reduce the bill?
Not while you are inside a fixed Universal Credits commitment, because the credits are prepaid and drawn down as you consume, and any not used by the end of the term are forfeited.
Cloud efficiency work therefore only converts into cash at the commitment boundary, where you resize the commitment, or immediately where you are already consuming above it.
Time the work to the commitment date rather than assuming a mid-term reduction lowers the invoice, because below the commitment it saves nothing.
Can compliance remediation and support reduction run together?
They should not. Where a compliance gap was remediated in the same quarter as a support reduction, the estate drew Oracle attention within the following year far more often than where the two were separated. Close the compliance gap first, let at least one quarter pass, then reduce support.
The same separation applies to support reduction and a request for commercial relief, because you would be asking the person whose forecast you just cut to grant you a favor, so space them by at least a quarter and preferably a renewal.
