The Oracle support contract is the most visible recurring instrument in the perpetual position. It runs on an annual index-based escalator. The Admodum read on the escalator, the support-spend map, the repricing levers and the drop-support choice.
Oracle Technical Support is the recurring service that ships product updates, error correction, certification updates and access to support resources. It is a separate contractual instrument from the perpetual licence itself. The licence is a one-time right to use the software at a specific version; support is the annual subscription that keeps the version current and the upgrade right alive.
Support is sold against every perpetual licence at the time of the order, and renews annually on a Customer Support Identifier (CSI). The 22 percent rate is calculated on the net licence fee paid at the original order (after any negotiated discount), not on the list price of the product. The net basis is the load-bearing detail: a deeper discount at the original order produces a lower support floor for the life of the contract.
The wider editorial sits in the Oracle pillar and the renewal-cycle context sits at the Oracle renewal cycle.
Oracle support renewals escalate annually on a contractual index. The most common construction is an inflation-linked clause: the prior year’s support cost multiplied by a published consumer price index, plus or minus a contractual margin. The escalator is therefore both a contractual term and an empirical reading; the index is published independently and the multiplier is fixed at the original order.
The escalator carries two buyer-side reads. The first is the index definition: which CPI, which jurisdiction, which publication month. The second is the cap: many older Oracle contracts carry no cap on the escalator, allowing it to track inflation in full; newer or renegotiated contracts may carry a 3 percent or 4 percent annual cap. The cap, once negotiated, becomes the load-bearing clause in inflationary periods.
The support-spend map is the recurring artefact that surfaces the entire perpetual position by product and by year. The map reads every CSI, every product line, every quantity, every original-order date, every prior-year support amount, and projects the next-year escalator. The output is the support spend by line item.
The map carries three buyer-side uses. As a cost surface, it shows where the support spend sits and where it is escalating fastest. As a compliance check, it surfaces support lines that no longer track to deployed product (a flag for either over-counting or for opportunities to drop). As a negotiating input, it becomes the load-bearing artefact at the renewal table, particularly when a Schedule A repackaging is proposed.
The wider read on the renewal sequence sits at the Oracle renewal cycle; the deeper read on Schedule A sits at Schedule A anatomy.
The support renewal carries four repricing levers. The first is the cap negotiation: where the contract carries no cap, the renewal is the window to introduce one. The second is the repackaging: a Schedule A repackaging that swaps unused products for needed products can be priced to hold the support envelope flat. The third is the multi-year prepay: a two- or three-year support pre-pay typically carries a discount against the annual escalator. The fourth is the termination of unused CSIs: support against shelfware is a recurring cost with no recurring benefit.
Each lever has a constraint. The cap is most effective when offered as part of a larger renewal package. The repackaging is constrained by the publisher’s pricing-policy floor (Matching Service Levels). The multi-year prepay sacrifices flexibility for discount. The termination of unused CSIs is constrained by the Matching Service Levels rule, which is the focus of the next section.
The deeper read on quarter-end timing sits at the Oracle quarter-end and the BATNA position at the Oracle BATNA.
The Matching Service Levels rule (the “pricing-policy floor”) constrains selective drops within a CSI. The rule reads that all licences of a given product family within a CSI must carry the same support level. The buyer cannot, therefore, keep support on half the licences of a product and drop it on the other half.
The rule has a buyer-side response: selective drops require either (a) a clean separation of CSIs at the original order, or (b) a renegotiation of the CSI structure at renewal to split the support population. The renegotiation is non-trivial; it requires publisher consent and typically rides alongside a larger renewal movement. The clean separation at original order is the easier discipline if the buyer reads it before the order is signed.
The wider context on contract structure sits at Schedule A anatomy and the audit-defence context at LMS audit anatomy.
Dropping Oracle support is a contractual right. The perpetual licence survives the drop; the buyer retains the right to use the software at the version owned at the drop date. What the buyer loses is access to updates, error corrections and the upgrade right. Reinstatement is at the publisher’s discretion and typically carries a back-support penalty equal to the support fees that would have been paid during the gap, plus an administrative reinstatement charge.
The drop is most viable on stable perpetual workloads where the buyer-side architectural plan is to run the current version to retirement, with no upgrade dependency on the publisher. Third-party support (Rimini Street, Spinnaker Support, others) provides an alternative service tier that covers stability without the publisher relationship. The deeper read sits at third-party support.
The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; the renewal programme sits at renewal programme.
The publisher’s fiscal calendar and the buyer’s timing leverage.
The buyer-side alternative when the publisher relationship is renegotiated.
A senior Admodum Oracle advisor will read your support-spend map and sequence the repricing levers on a private call. Active renewal events route to the Renewal Programme; active audits route to the Audit Defence programme.