Third-party support is the alternative service tier for the Oracle perpetual position. The buyer drops Oracle support, retains the perpetual licence and contracts with an alternative provider. The Admodum read on the cost arithmetic, the scope limits and the return path.
Third-party support is a service tier provided by independent firms for software the buyer owns under perpetual licence. The buyer ends the publisher support relationship, retains the perpetual licence (which is a one-time right and survives the support drop), and contracts with the third-party provider for the ongoing service.
The mature third-party support market for Oracle is dominated by two providers: Rimini Street (NASDAQ-listed, multi-publisher) and Spinnaker Support (private, multi-publisher). Both have well-documented service portfolios and thousands of executed migrations across Oracle Database, Oracle Applications (E-Business Suite, JD Edwards, PeopleSoft, Siebel) and the wider Oracle Fusion Middleware estate.
The wider editorial context sits in the Oracle pillar and in the BATNA reading at the Oracle BATNA.
The cost arithmetic of third-party support compares the Oracle support fee (typically 22 percent of the net licence fee, escalated annually) with the third-party fee (typically 50 to 60 percent of the Oracle support fee). The buyer saves roughly the difference, with adjustments for transition costs and any additional internal capability investment.
On a US$10m annual Oracle support spend, the indicative third-party position is US$5m to US$6m, with a one-time transition cost of US$0.5m to US$1m for the first-year migration (including documentation transfer, knowledge handover and process change). The recurring saving is therefore US$4m to US$5m, compounding against the publisher escalator the buyer would otherwise carry.
The arithmetic is sharper where the perpetual base is large and the publisher escalator is uncapped. The arithmetic narrows where the publisher escalator is capped (3 or 4 percent annually) or where the third-party scope is constrained by the technical environment.
Third-party support covers three service lines. Break-fix is the operational support for production issues against the version the buyer owns at the drop date. Tax-and-regulatory updates are the localised changes to applications (payroll, tax tables, statutory reporting) the buyer needs to remain compliant in operating jurisdictions. Technical assistance is the advisory layer covering configuration, performance and migration questions.
What third-party support does not cover is access to new Oracle product versions. The perpetual licence is frozen at the version owned at the drop date; the buyer does not receive subsequent major-version uplift, new optional modules or new platform certifications. The trade-off is therefore service cost versus upgrade-right; buyers who plan to run the current version to retirement carry no upgrade-right loss.
Oracle’s pricing policy applies the Matching Service Levels rule across the Customer Support Identifier (CSI). The rule constrains the buyer from selectively dropping support on part of a CSI; all licences of a product family within a CSI must carry the same support level.
The buyer-side response is to plan the drop at the CSI boundary. Where the population is split across multiple CSIs, the drop can target a complete CSI. Where the population is consolidated into a single CSI, the drop is either all-or-nothing for the CSI, or it triggers a CSI-restructure renegotiation with the publisher (which is non-trivial and typically rides alongside a larger renewal event).
The deeper read sits at support renewal mechanics and the wider renewal context at the Oracle renewal cycle.
The migration to third-party support runs as a three-phase choreography. Phase one is the documentation transfer: the buyer captures the operational state, the configuration baseline, the active support tickets and the knowledge base. Phase two is the transition: the new provider takes operational responsibility while the old provider winds down. Phase three is the steady-state: the new provider is the primary support contact and the buyer’s internal team is trained on the changed interface.
Each phase has a buyer-side discipline. Phase one needs documentation completeness and ticket-resolution before transition. Phase two needs parallel-running coverage so that no production support gap appears. Phase three needs internal-team capability so that the new interface is used effectively. The well-executed migration runs four to six months from decision to steady-state.
Return to Oracle support is at the publisher’s discretion. The publisher will typically permit reinstatement, but at a cost: a back-support charge for the gap period (often equal to the support fees that would have been paid during the gap), plus an administrative reinstatement charge, plus a potential repricing of the support floor to current list rather than the historical net.
The repricing risk is the load-bearing detail. A buyer that dropped support against a deeply-discounted historical net is reinstated against the current list, which can be materially higher. The return-to-Oracle option is therefore expensive to exercise and is the load-bearing reason buyers commit to third-party support as a multi-year position rather than a tactical experiment.
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-side support contract the drop is exiting from.
The four alternative-position families third-party support is the first of.
A senior Admodum Oracle advisor will read your CSI structure and model the third-party support arithmetic on a private call. Active renewal events route to the Renewal Programme.