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. It is a program run against the support annuity, using leverage you have to manufacture.
A perpetual unlimited agreement has no end date, no certification and no renewal, so nothing will ever force Oracle to renegotiate it. Exiting one is not an event you schedule. It is a program you run against the support annuity, using leverage you have to manufacture yourself.
Most perpetual unlimited agreements were signed to solve a problem that had a date on it. An audit, an acquisition, a support bill that had become indefensible.
The problem got solved. The annuity did not, and five years later it is the largest uncontested line in the Oracle relationship. This playbook is how you contest it.
It means one of four end states, and you should decide which one you are pursuing before you speak to Oracle. Buyers who have not chosen tend to pursue all four badly.
What buyers mean when they say they want out of a PULA
| End state | What you keep | What you stop paying | Realistically available? |
|---|---|---|---|
| Leave Oracle support, keep deploying | The unlimited deployment right | The Oracle annuity, in full | Yes, and it is the largest single lever |
| Convert to a counted entitlement | A fixed perpetual quantity | The premium over what you run | Occasionally, and only as a trade |
| Carve a business out | Coverage for what remains | The divested share of the base | Yes, if raised before the sale agreement |
| Terminate the agreement | Nothing | Everything | Effectively never. No clause supports it |
Pick one primary end state and one fallback. Oracle will read an unfocused request as a fishing expedition and will answer it with a discovery request of its own.
The instrument itself is described in full on the Oracle PULA page. This playbook assumes you already have one and now want the cost down.
Because it is the only part of the deal that is still moving. The license fee was paid once and is gone, while the annuity compounds every year for as long as the company exists.
Take a support stream of four million dollars with a four percent annual uplift. It is roughly five point seven million in year ten and about forty eight million dollars cumulatively across the decade.
Oracle's technical support policies require support to be held across a license set and reprice the remainder if you drop part of it. On ordinary licenses that rule is painful but navigable.
On a perpetual unlimited agreement it is worse, because there is no counted subset to drop. You hold a right, not a quantity, so partial reduction has nothing to attach to.
Support is not one product. Oracle's Lifetime Support Policy moves each release 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.
This is the analysis that converts a cost debate into a technical one you can win. It is also the fastest way to find out that a significant share of the annuity is buying very little.
If you stop Oracle support and later want it back, Oracle charges a reinstatement fee under the same policies. Model the return trip before you take the first step, because the option to come back is what you are really giving up.
White Paper · Oracle
How to Exit an Oracle ULA Without Overpaying
The certification trap, the support reset, and the timing that protects your leverage. Read it free.
You attach your request to something Oracle wants on a date Oracle cares about. A perpetual agreement removes your deadline, so you have to borrow one.
Oracle's fiscal year ends on 31 May, and the fourth quarter behaves differently from the rest of the year. A request that has been sitting for two quarters can move in three weeks in May.
Do not treat that as a strategy on its own. Timing amplifies leverage that already exists and does nothing for a request with no trade behind it.
Because it is the one date in the whole relationship that Oracle cannot move and you cannot postpone. A completion date is set by a sale agreement, not by a licensing conversation.
In most perpetual agreements the unlimited right is granted to named entities. A business that leaves the group leaves the agreement, usually on the day it stops being a subsidiary.
That means the buyer of your business needs its own Oracle licenses at completion. If nobody priced that during the transaction, the cost lands on whichever party the sale agreement made responsible.
After the sale agreement is signed you have no leverage, only a deadline. Oracle knows the completion date is fixed and prices accordingly.
This is the single most expensive timing error we see on perpetual agreements. The conversation is worth several million dollars nine months out and almost nothing four weeks out.
Four paths deliver a real reduction, and they combine. Each has a precondition, and pursuing one without its precondition is how buyers spend a year achieving nothing.
The four paths, their preconditions, and what they typically return
| Path | Precondition | Typical return on the annuity | What you give up |
|---|---|---|---|
| Third party support | Stable releases, low patch dependency | Roughly half the annual line | Patches, upgrades, easy return |
| Renegotiate the stream against a trade | Something Oracle wants, on a date | 15 to 30 percent, in our files | The commitment you traded |
| Convert to a counted entitlement | A settled, stable deployment count | Varies widely, occasionally large | The unlimited right, permanently |
| Carve out at divestiture | Raised before the sale agreement | The divested share of the base | Coverage for the departing entity |
Start with the path that needs no permission. A credible third party support evaluation costs you nothing and changes the tone of every other conversation.
Only then approach Oracle, and approach it with a trade already identified. Details of the alternatives sit on the Oracle third party support page and the transition service.
Conversion to a counted entitlement is the path buyers ask for and the one that most often goes wrong. You give up an unlimited right permanently in exchange for a reduction that is only real if deployment has genuinely stopped.
Test it against three years of actual growth, not against the plan. If the estate is still adding capacity, conversion transfers value to Oracle and calls it a saving.
The common advice is to open a negotiation with Oracle, explain that the perpetual agreement no longer fits, and ask for a conversion to a counted entitlement or a reduced stream. We disagree, and not because the ask is unreasonable. It is that the request, made cold, gives Oracle three things at once: notice of your intent, an invitation to ask for deployment data, and a deadline that belongs to you rather than to them. 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. The ask is the last step, not the first.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
You are not trying to leave a contract. You are trying to stop an annuity, and the annuity has no expiry date to wait for.
It runs a small number of well practiced responses, and each one has an answer. Recognizing them saves a quarter of wasted meetings.
Anything you run that is not in the schedule is ordinary unlicensed use, and the unlimited right does not reach it. Options and packs, unlisted entities and cloud deployments counted the wrong way are the three recurring findings.
Cloud counting in particular follows Oracle's published policy for authorized cloud environments. Resolve that thread on its own facts, and do not let it become the price of the cost conversation.
Group structures change constantly and schedules rarely keep up. A business acquired three years ago and quietly migrated onto the estate is not covered by an unlimited right granted to entities named at signature.
Reconcile the schedule against the current group structure before Oracle does. The contract documents that govern this are published on Oracle's contracts page.
Twenty four months, three phases, and the first eighteen happen without Oracle in the room. The preparation is most of the work and all of the leverage.
Sometimes there is no trade available and Oracle simply declines. That is a normal outcome and it is not the end of the program.
The position you built does not expire. Keep it current and wait for the window, because on a long enough horizon one of the three windows always opens.
Buyers who hold this posture tend to get their reduction in year two or three rather than never. Buyers who stand down after one refusal start again from nothing.
Effectively no. In the perpetual agreements we have reviewed, none contained a customer side termination right, so the realistic objective is to reduce or stop the support annuity rather than to end the contract.
Moving off Oracle support, which typically removes about half of the annual line. It is available without Oracle's permission, which is exactly why it changes the tone of every other conversation you have.
Not in the way buyers expect. Oracle's support policies reprice the remainder when part of a license set is dropped, and a perpetual unlimited agreement gives you a right rather than a counted quantity, so there is no subset to reduce.
Before the sale agreement is signed, ideally six to nine months before completion. Once the completion date is fixed and Oracle knows it, you have a deadline instead of leverage and the conversation gets materially more expensive.
Usually not. The right is granted to named entities, so a business that leaves the group leaves the agreement, and the acquirer needs its own licenses at completion unless a transition period was negotiated in advance.
Only where a clause or a formal audit requires it. A voluntary census supplies the one fact Oracle does not have, and in our files it is the most expensive unforced error buyers make on perpetual agreements.
Only when deployment has genuinely stopped growing. You surrender the unlimited right permanently, so test the decision against three years of actual capacity data rather than against the current plan.
Plan for about twenty four months, with the first eighteen spent building your position and your alternatives. Programs that open with Oracle rather than with preparation are the ones that produce a courteous meeting and no movement.
