Hyperion on Third-Party Support: When Leaving Oracle Support Actually Makes Sense

A stable Hyperion estate on 11.1.2.x is paying roughly 22% of net license fees for a service Oracle has contractually gutted, which is the strongest third-party support case in the Oracle portfolio. This page quantifies the saving, prices the exit door, and names the three contract clauses that decide whether the business case survives contact with your CSI.

The Deadline You Think You Have Does Not Exist

Every Hyperion conversation I have joined in the last three years opens with a date the customer believes is fixed and the account team has never actually put in writing. Read Oracle's own Continuous Innovation document for Hyperion EPM 11.2. It was revised to state that Oracle Premier Support is available "through at least 2033," which was itself an extension of earlier commitments of 2030 and 2031, and Continuous Innovation releases are supported on-premises through at least 2037. The operative words are "through at least." That is a floor, not a cliff. A floor that has moved outward twice already is not a migration trigger, it is an open-ended commitment that Oracle has repeatedly chosen to lengthen because on-premises EPM customers keep paying. There is no hard cut-off forcing a cloud move in 2026 or 2027, and no clause in your support policy that converts 2033 into a termination event. That absence is the single most valuable asset a Hyperion buyer holds. It means every EPM Cloud proposal you receive is a discretionary purchase, not a compliance response, and it means a third-party support decision can be taken on pure economics rather than under duress. Practical instruction: before you take any renewal or cloud call, extract the sales team's stated end-of-support date in email, then put the current Continuous Innovation PDF next to it. When the two disagree, and they usually do by five to eleven years, you have established that the urgency is manufactured. Log that exchange. It is the first exhibit in both your EPM Cloud cost defence and your third-party business case.

A floor that has already moved outward twice is not a migration trigger, it is a commitment Oracle keeps lengthening because you keep paying.

Two Populations, Two Completely Different Business Cases

Hyperion buyers are not one market. They are two, split by release, and conflating them is how good business cases get killed in finance review. Population one runs 11.1.2.x. Premier Support ended in December 2021 with no Extended Support option offered, so these estates sit in Sustaining Support: no new fixes, no security alerts, no Critical Patch Updates created after the Premier window closed, and Oracle's own policy warns that "information and skills regarding those releases may be limited." Market Driven Support covered only 2022 and 2023 and there is no published 2026 equivalent. These customers pay roughly 22 percent of net license fees for problem diagnosis against a frozen code line. Population two runs 11.2.x and is buying something tangible. Oracle shipped 11.2.24 in January 2026, 11.2.25 in April 2026, and 11.2.26 in August 2026, each a cumulative OPatch update that includes everything from 11.2.15 and can be applied on top of any release from 11.2.15 onward. That cadence carries the Critical Patch Update binaries no third-party provider can legally ship.

The instruction differs by population. If you are on 11.1.2.x, you are already living the third-party service level while paying Oracle's price, so the burden of proof sits with anyone arguing to stay, and the sustaining support end-of-life analysis should drive your renewal position. If you are on 11.2.x, do not model the 50 percent saving until you have costed compensating controls for the security patches you will stop receiving. In my experience, that control cost consumes a meaningful slice of the saving on internet-facing or heavily integrated estates, and almost none of it on air-gapped finance-only deployments. Establish which you are before you build the model.

What Sustaining Support Actually Excludes, Clause by Clause

Read the Oracle Software Technical Support Policies (10-July-2026) and the arithmetic gets uncomfortable fast. Sustaining Support excludes new program updates, fixes, security alerts, critical security patch updates and critical patch updates created after the Premier or Extended Support period ended. That is not a footnote, it is the entire delivery mechanism of Oracle support. The policy then adds its own quiet warning: "As program releases under Sustaining Support are no longer fully supported, information and skills regarding those releases may be limited." Oracle is telling you in writing that the people answering your 11.1.2.4 ticket may not know the product. The second clause buyers routinely miss is the payment condition: technical support may be extended with Sustaining Support "for as long as you continuously maintain and pay the annual fees for technical support." Sustaining Support is neither free nor automatic. Lapse the CSI and it disappears, along with the reinstatement pricing you were relying on. Strip it down and a Hyperion 11.1.2.x estate is paying roughly 22% of net license fees for three things: the right to log a service request, access to the existing patch library published before December 2021, and continued use of the license. No new fixes, no new CPU binaries, no escalation path to development. Compare that against what a third-party provider contracts to deliver and the gap is not marginal. If your estate sits here, work through the Hyperion sustaining support end-of-life decision before you renew another year on autopilot.

You are paying roughly 22% for the right to open a ticket against a product Oracle has contractually agreed not to fix.

Pricing the 50%: What the Savings Number Really Means

The headline is real but it is a percentage, and percentages need a denominator. Rimini Street markets "up to 50% savings off of your annual vendor maintenance fee," which means off your net support fee, not Oracle list. Independent advisory ranges run 50 to 60 percent lower cost across Rimini Street, Spinnaker Support, and Origina. The consequence is counterintuitive: the better your original license discount, the smaller the absolute dollar saving, because your 22% is calculated on an already reduced net license value. An estate that bought at 85% off list has very little support fee left to halve. An estate that bought at 30% off has a large one. Two Hyperion customers with identical user counts can therefore see materially different business cases, and market experience says the spread is wide enough to flip the decision. On the service side, the Hyperion-specific offer is credible: 24/7/365 coverage, custom code fixes (which Oracle never supported at any tier), and 10-minute guaranteed response for P1 and P2 issues. Custom code coverage is the item most Hyperion shops undervalue, because heavily customised HFM consolidation logic is exactly what Oracle Support declines to touch. Model three years of net cash flow, not a single-year headline, and include the transition costs, the knowledge transfer, and the cost of any archived patch harvesting you must complete before the CSI closes.

Before you sign, run the same numbers through the wider Oracle third-party support decision framework so the Hyperion case is tested against your Fusion Middleware and database exposure rather than in isolation. Ask the provider to quote against your actual CSI line items, not an estimate from your renewal total, and insist the quote itemises which Hyperion SKUs and which middleware components are in scope.

Matching Service Levels and the Repricing Clause: Why Partial Exits Fail

This is where most Hyperion third-party business cases die, and it dies quietly, in the finance model, months after the vendor demo. Oracle's Matching Service Levels rule prevents you from de-supporting part of a licence set: you cannot keep support on 60% of your Planning Named User Plus quantities and drop the rest. Termination has to cover all licences of the affected product within the Customer Support Identifier. Then the repricing clause finishes the job. Oracle's policy states that where a subset of licensed software on a single order is terminated, support for the remainder is repriced at Oracle list price less the applicable standard discount. In plain terms: the 70% or 80% discount you negotiated in 2013 was priced against the full order volume. Strip 37.5% of the estate out and Oracle recalculates the surviving lines against a smaller volume tier, which routinely lands the "reduced" support bill at 95% to 99% of what you were paying before. I have seen buyers walk into a steering committee with a modelled 40% reduction and walk out with 3%. The practical consequence is that a Hyperion exit is usually all or nothing per CSI, per product, and the arithmetic only works when the entire affected line item leaves together. Before anyone models a saving, do the unglamorous work: pull every ordering document, map which CSI each Hyperion SKU sits under, identify which orders mix Hyperion with Database, WebLogic, or other products you have no intention of dropping, and confirm whether your Hyperion stack's embedded database and WebLogic entitlements share an order with the EPM SKUs. If they do, the clean exit you sketched does not exist, and the sequencing question becomes a CSI restructuring negotiation with Oracle before any third-party contract is signed.

A Hyperion exit is usually all or nothing per CSI, per product, and the arithmetic only works when the entire affected line item leaves together.

The 150% Reinstatement Penalty: Pricing the Return Ticket

Treat the exit as one-way. Oracle's published support policies price reinstatement at 150% of the last annual technical support fee paid, prorated across every month support was lapsed, and that penalty sits on top of the current period's support fee at then-current rates. The arithmetic is brutal and deliberate. Take an estate paying $500,000 a year in Hyperion support that moves to third-party support and, three years later, decides it needs Oracle patches back, perhaps because a cloud migration slipped or an acquisition changed the roadmap. The back-support penalty is three years at $500,000, uplifted 150%, which is $2.25m, plus roughly $500,000 for the forward year, totalling about $2.75m. Against that, three years of third-party savings at 50% is roughly $750,000. You would be paying nearly four times your accumulated savings for the privilege of returning, and that assumes Oracle agrees to reinstate at all rather than requiring a fresh licence purchase for a version that has since fallen out of scope.

Reinstatement is therefore not a fallback plan, it is a deterrent, and you should model it as unusable. In 25 years of these negotiations I have almost never seen Oracle waive the multiplier outside a large concurrent cloud commitment, and when it is discounted it is because the customer is signing an EPM Cloud subscription that dwarfs the penalty. That reframes the decision entirely: the third-party case is only underwritable if you have a credible terminal endpoint, either a funded migration to Oracle EPM Cloud with a dated business case, or a genuine replatform to a non-Oracle EPM tool. If the honest answer is "we will run Hyperion until something forces our hand," you are betting that nothing over the next five to seven years, a merger, an auditor's finding, a regulatory reporting change, sends you back to Oracle's door. Price that bet before you sign, and get the third-party contract's own exit terms, notice periods, and data return obligations reviewed at the same time.

Residual Risks: Security Exposure, Middleware Scope, and the Legal Position

Be honest with your board about the one thing no third-party provider can hand you: Oracle-signed Critical Patch Update binaries. Oracle's April 2026 CPU shipped security fixes spanning Hyperion, Fusion Middleware, WebLogic, Oracle HTTP Server, and Java components, and those fixes are distributed only to customers with an entitled CSI under Premier Support. A third-party vendor responds with compensating controls: virtual patching at the network and WAF layer, configuration hardening, IPS signatures, and code-level workarounds. In my experience that is a genuinely defensible posture for an internal-facing consolidation system behind SSO and a segmented network, and a poor one for anything internet-exposed or handling regulated data with a hard patch-currency covenant. Test the position with your CISO before you test it with procurement, and get the answer in writing.

The scoping error I see most often is treating this as an EPM decision. HFM, Planning, Essbase, and FDMEE sit on a substrate that is where most of the CVEs actually land. Rimini Street's published Fusion Middleware coverage spans WebLogic Server, SOA Suite, Service Bus, Forms and Reports, ADF, and Identity and Access Management, but published coverage is not your contract. Force each bidder to schedule your exact components, versions, and the embedded database, since the database and WebLogic licensing buried in your Hyperion stack is routinely omitted from both the incumbent's and the challenger's scope until something breaks.

• Enumerate every WebLogic domain, OHS instance, JDK, and repository database version supporting EPM, then require named coverage per item in the MSA schedule, not a generic "middleware" line.
• Ask each provider, in writing, for mean time to compensating control after a CPU release, and for the escalation path when the only real fix is an Oracle binary.
• Document the residual risk formally, with CISO sign-off and a named accepting executive, so the decision survives an auditor or a cyber insurer asking the question three years out.

On the legal question, the decade of Rimini-related litigation risk is now largely priced out. Following the 2025 settlement, Rimini Street's Oracle support services, excluding the PeopleSoft wind-down, are not subject to any active injunction or proceeding. If your estate is mixed EPM and PeopleSoft, treat that carve-out as a live constraint and read the buyer-side case on PeopleSoft third-party support before you bundle the two into one tender.

What To Do First: A Four-Week Decision Sequence

Four weeks of disciplined work decides this. It is not a strategy exercise; it is a document-retrieval exercise followed by arithmetic.

• Week one, CSI archaeology. Pull every CSI, ordering document, and support renewal quote covering EPM and its middleware. Map which products sit on which support line and which CSI. Matching Service Levels blocks de-supporting part of a licence set, so establish before you model anything whether a partial drop is contractually possible at all.
• Week two, release level. Confirm whether you are on 11.1.2.x (already in Sustaining Support since December 2021) or 11.2.x, and whether 11.2.26, the August 2026 cumulative update, has been applied. An estate that is current on 11.2 is buying Premier Support that Oracle is still actively delivering; an 11.1.2.4 estate is paying roughly 22% for a service Oracle has already gutted. See the sustaining support end-of-life decision for how that split changes the answer.
• Week three, five-year net cash. Model the repricing outcome explicitly, because dropping a subset can reprice the remainder and yield zero saving. Assume reinstatement at the 150% penalty is unusable, so the model must stand on the assumption you never come back.
• Week four, tender. Go to at least two providers with an explicit middleware and database scope schedule attached to the RFP, plus tax, regulatory, and custom-code fix commitments. Compare on scoped coverage, not on headline discount.

Then use the timing. There is no hard cut-off forcing migration in 2026 or 2027; Premier Support for 11.2 runs through at least 2031, with Continuous Innovation releases supported on-premises through at least 2037. Say that out loud in your parallel EPM Cloud conversation, and price the alternative properly using what a Hyperion to EPM Cloud migration really costs. A credible third-party bid on the table is the single strongest lever you will have in that negotiation, whether or not you ultimately sign it.

Related advisory: the full topic guide.

Frequently asked questions

When does Oracle support for Hyperion EPM 11.2 actually end?

Oracle's own Continuous Innovation documentation was revised to state Premier Support for EPM 11.2 is available through at least 2033, having previously said 2030 and then 2031. Continuous Innovation releases are supported on-premises through at least 2037. The phrase 'through at least' is a commitment floor, not an end date, and there is no hard cut-off forcing a cloud migration in 2026 or 2027.

How much does third-party Hyperion support actually save?

Rimini Street markets up to 50% off your annual vendor maintenance fee, and independent advisory ranges across Rimini Street, Spinnaker Support, and Origina run 50 to 60 percent lower cost. Critically, the saving is measured against your net support fee, not Oracle list, so a well-discounted estate saves less in absolute dollars. Model three to five years of net cash flow, not a single-year headline.

Can I move only part of my Hyperion estate to third-party support?

Rarely, and usually not economically. Oracle's Matching Service Levels rule blocks de-supporting part of a license set, and termination must cover all licenses of the affected product within a CSI. The repricing clause then reprices the remaining licenses at list minus your standard discount, which can mean dropping 50% of an estate reduces the bill by almost nothing.

What does it cost to go back to Oracle support after leaving?

Reinstatement is 150% of the last annual technical support fee you paid, prorated from the lapse date to the date support is reordered, plus the fee for the current support period. On a $500,000 annual fee, a three-year absence costs roughly $2.75m to reverse. Treat reinstatement as unavailable and build the exit around a credible replatform or cloud endpoint instead.

Is third-party Oracle support legal after the Rimini Street litigation?

Yes. Following the 2025 settlement, Rimini Street's Oracle support services, excluding the PeopleSoft wind-down, are not subject to any active injunction or legal proceeding. If your estate mixes Hyperion with PeopleSoft, treat the PeopleSoft carve-out as a separate scoping question and confirm it in writing before you sign.

What is the biggest risk of leaving Oracle support for Hyperion?

Losing access to Oracle's Critical Patch Update binaries. Oracle's April 2026 CPU included fixes across Hyperion, Fusion Middleware, WebLogic, OHS, and Java components, and no third-party provider can ship Oracle-signed patches. You get compensating controls and virtual patching instead, which is a security architecture decision your CISO must sign off on, not a procurement decision.