Not one perpetual agreement carried a termination right, so every reduction came from a trade

A perpetual unlimited agreement has no certification, no term end and no renewal, so nothing will ever force Oracle to renegotiate it. Exiting one is not an event you schedule. It is a program run against the support annuity, using leverage you have to manufacture yourself.

Prepared by Redress Compliance · August 15, 2026 · Oracle advisory. Based on 20 to 30 perpetual unlimited agreements reviewed, 2024 to 2025.

The licence fee was paid once and is gone. The annuity compounds every year for as long as the company exists, which is why it is the only part of the deal still moving.

• Years one to three: you are still paying off the licence value, and the deal looks like the thing you bought.
• Years four to seven: the licence value is fully recovered, so every payment from here is annuity.
• Years eight and beyond: you are funding a deployment right most estates have stopped exercising.
• The uplift does more damage than the base, because it compounds. A cap negotiated once is worth more than a discount taken once.

The repricing rule bites harder here than anywhere else. Support has to be held across a licence set, and dropping part of it reprices the remainder. On ordinary licences that is painful but navigable. On a perpetual unlimited agreement there is no counted subset to drop, because you hold a right rather than a quantity, so partial reduction has nothing to attach to.

Support is not one product. Each release moves through Premier, then Extended, then Sustaining Support, and the entitlement narrows at every step. Once a release reaches Sustaining Support there are no new updates, no new fixes and no certification with new third party products. The invoice does not narrow with it.

• Run the release inventory first, listing every Oracle release in the estate against its current support stage.
• Weight the annuity by stage, working out what share of the bill is attached to releases already receiving the narrowest entitlement.
• Decide whether the gap is real, because if most of the estate sits in Sustaining Support, the technical argument against a third party alternative is much weaker than the incumbent will claim.
• Separate the security question, since patch availability rather than general support is usually the genuine blocker, and it applies to a narrower set of systems than people assume.

This analysis converts a cost debate into a technical one you can win. It is also the fastest way to discover that a significant share of the annuity is buying very little. Note that leaving support is close to a one way door: a reinstatement fee applies if you return, so the option to come back is what you are really giving up.

You attach the request to something Oracle wants on a date Oracle cares about. A perpetual agreement removes your deadline, so you borrow one.

• A purchase Oracle needs to book. Any new order gives the account team a number to hit and a reason to concede elsewhere.
• A cloud commitment, which carries internal weight. If a migration is genuinely happening, it should never be sold to Oracle as a standalone deal.
• A corporate event with an external clock, a divestiture, a carve out, or a regulatory separation.
• Fiscal timing as an amplifier. Oracle's year ends on 31 May and the fourth quarter behaves differently, but timing amplifies leverage that already exists and does nothing for a request with no trade behind it.

What destroys leverage before you start: a voluntary deployment census no clause required, announcing the objective early, carrying a single option into the room, and leaving the request with the account team alone. Support economics are decided above the account team, so the request has to be visible above it.

In most perpetual agreements the unlimited right is granted to named entities, so a business that leaves the group leaves the agreement, usually on the day it stops being a subsidiary. The buyer of your business then needs its own Oracle licences at completion, and if nobody priced that during the transaction the cost lands on whichever party the sale agreement made responsible.

Raised after the sale agreement is signed you have no leverage, only a deadline, and Oracle prices accordingly. This is the single most expensive timing error on perpetual agreements.

The common advice is to open a negotiation with Oracle, explain that the perpetual agreement no longer fits, and ask for a conversion or a reduced stream. The ask itself is not unreasonable. The problem is what a cold ask hands over: notice of your intent, an invitation to request deployment data, and a deadline that belongs to you rather than to Oracle. Every reduction we have seen achieved was attached to something Oracle wanted, on a date Oracle cared about, raised by someone above the account team. Build the trade first.

This is why a perpetual agreement is structurally different from a ULA. A timed agreement supplies an expiry, and an expiry is a negotiation whether either side wants one. The perpetual instrument deletes that moment deliberately, which is the feature it is sold on and the reason it is difficult to unwind. Nothing in the contract will ever bring Oracle to the table, so the buyer has to import a reason from somewhere else in the business: a purchase, a migration, a transaction. The exit conversation is therefore a procurement program with a licensing component, not a licensing conversation with a procurement component.

Recognizing Oracle's standard responses saves a quarter of wasted meetings. The compliance pivot turns a cost conversation into a question about what you are running, which is exactly why the voluntary census is so damaging. The bundling response offers a reduction contingent on a purchase larger than the saving. The delay response is simply time, which costs Oracle nothing and costs you another year of annuity. Each has an answer, and each answer depends on having a second live option.

Start with the path that needs no permission. A credible third party support evaluation costs nothing and changes the tone of every other conversation, because it is the one move that does not require Oracle to agree to anything. Only then approach Oracle, and approach with a trade already identified. Conversion to a counted entitlement is the path buyers ask for most and the one that most often goes wrong, since it surrenders the unlimited right permanently for a reduction that is only real if deployment has genuinely stopped. Test it against three years of actual growth rather than the plan. The instrument itself is described on the Oracle PULA page, the settlement mechanics in the exit strategies brief, and the instrument choice in the PULA versus ULA pillar.

Watch the briefing · 4:30How to Negotiate an Oracle ULA: No Price List, Just Your Business CaseThere is no price list: the fee is a story built from your estate and your growth, so give conservative answers and keep the product list narrow.

Across 20 to 30 Oracle perpetual unlimited agreements reviewed in 2024 and 2025, two numbers frame the whole program:

The patterns: voluntary censuses that handed over the only missing fact, objectives announced before a trade existed, and requests that never rose above the account team.

The buyer side move is to build the trade, then ask. The wider library sits in the Oracle practice.

Can you terminate an Oracle PULA?

Not under the contract. Across the perpetual unlimited agreements reviewed in 2024 and 2025, not one carried a customer side termination right. What buyers call an exit is one of four end states, and every reduction achieved came from a trade rather than from a clause.

Why is the support annuity the target rather than the agreement?

Because the licence fee is sunk by roughly year three to five and the annuity keeps compounding for as long as the company exists. A support stream of four million dollars at a four percent uplift is about five point seven million in year ten and roughly forty eight million cumulatively across the decade. That number is the negotiation.

What are the four end states?

Leave Oracle support while keeping the deployment right, convert to a counted entitlement, reduce the base at a divestiture, and terminate the agreement outright. The first three are achievable. The fourth effectively never happens, because no clause supports it.

How do you create leverage when there is no renewal date?

You borrow a deadline. Attach the request to something Oracle wants on a date Oracle cares about: a purchase it needs to book, a cloud commitment carrying internal weight, or a corporate event with an external clock. Oracle's fiscal year ends on 31 May, and timing amplifies leverage that already exists but creates none on its own.

Why does a divestiture matter so much?

It is the only hard deadline in the relationship that Oracle cannot move and you cannot postpone, because the completion date is set by a sale agreement. The conversation is worth several million dollars nine months before completion and almost nothing four weeks before, which makes late escalation the most expensive timing error on these agreements.

Is leaving Oracle support reversible?

Close to a one way door. If you leave and later want to return, a reinstatement fee applies under the same support policies, so the option to come back is what you are really giving up. Model the return trip before taking the first step, and check what share of the estate already sits in Sustaining Support.

What destroys leverage before the negotiation starts?

A voluntary deployment census that no clause required, announcing the objective early, carrying a single option into the room, and leaving the request with the account team alone. Support economics are decided above the account team, so the request has to be visible above it.

What does conversion to a counted entitlement really cost?

It permanently surrenders the unlimited right in exchange for a reduction that is only real if deployment has genuinely stopped. Test it against three years of actual growth rather than against the plan, because on an estate still adding capacity, conversion transfers value to Oracle and is presented as a saving.