Most Oracle support decisions are made one renewal at a time, against this year's invoice. That framing is the problem. Support is a compounding cost, and a charge that looks tolerable in a single year becomes the dominant line in the Oracle relationship when you stretch the view to five. Modelling the bill across a five year horizon is the single most clarifying thing a buyer can do, because it reveals the true cost of doing nothing and the true value of acting early.
What does Oracle support cost over five years?
Over five years Oracle support costs far more than five times the first year fee, because the roughly 22 percent base escalates by a fixed annual uplift that compounds. Each year's fee is calculated on the prior year plus the uplift, so the curve bends upward rather than running flat. By year five the annual charge is meaningfully higher than year one, and the cumulative total across the five years often approaches or passes the original license fee itself. Seen this way, support is not a maintenance line. It is a second purchase of the software, paid in instalments, with the price rising as it goes.
| Year | What happens | Effect on the curve |
|---|---|---|
| Year 1 | Base fee at roughly 22 percent | The starting point |
| Years 2 to 4 | Annual uplift applied each renewal | The fee bends upward |
| Year 5 | Compounded fee, well above year 1 | Cumulative nears the license fee |
Why does the five year view change the decision?
The five year view changes the decision because it reprices the cost of inaction. A partial termination, a set restructuring, or a move to third party support all look like effort for a modest single year saving when viewed against one invoice. Viewed against the five year curve, the same move saves a compounding amount, because every pound or dollar taken out of the base is a pound or dollar that does not escalate for the remaining years. The long view turns small annual savings into large lifetime ones, and it turns the decision to defer into a decision with a measurable price.
What should you model before a renewal?
Before a renewal you should model the full five year trajectory of the current bill, then the same trajectory under each lever you are considering, so the comparison is lifetime against lifetime rather than year against year. The base case is doing nothing, with escalation running unchecked. Against it, model partial termination net of any matching service level repricing, set restructuring at the renewal window, and offsets such as Support Rewards through OCI. The gap between the base case and the best structured case, summed across five years, is the real prize, and it is almost always larger than a single renewal suggests.
What is the buyer move?
The buyer move is to make every renewal a five year decision, not a one year one, and to act on the lever while the contract is at a window where it flexes. The mistakes that lock in cost, a blunt partial cut or a mistimed reduction, are mistakes precisely because their consequences compound across the same five year curve. Building the model once, and revisiting it at each renewal, keeps the escalation visible and the decisions honest. Where the sets are tangled or the trajectory is unclear, the model is worth building before the renewal lands, because the window to act is short.
What does the curve look like under each lever?
Under each lever the curve bends differently, and seeing the shapes side by side is what makes the decision. The base case rises steepest, because escalation compounds on the full fee every year. A partial termination that survives repricing lowers the whole curve from the point it lands, so the saving widens with each subsequent year. A renewal restructuring resets the slope as well as the level. An OCI offset shaves the top without changing the slope. Modelling all of them on one view, summed across five years, turns an abstract argument about percentages into a concrete comparison of lifetime totals, and the gaps between the curves are usually larger than any single renewal hints.
How often should the model be refreshed?
The model should be refreshed at every renewal and whenever the estate changes materially, because the inputs move: licenses retire, sets restructure, OCI commitments shift, and the escalation marches on regardless. A five year model built once and forgotten drifts out of date and stops guiding decisions. Revisited each cycle, it keeps the compounding visible and the next move honest, so the buyer is always deciding against the real trajectory rather than a stale snapshot.
For the compounding mechanism in detail, see the 22 percent and the annual escalation. For the errors that lock the curve in place, see the support mistakes that lock in cost. The full method sits in the Oracle negotiation guide.