On stable estates the ULA beat the perpetual model by 20 to 35 percent over ten years
A ULA and a PULA promise the same unlimited deployment of the same named programs, then split on four axes: term, certification, support, and audit. One word, perpetual, is the whole difference, and it decides the lifetime bill rather than the signing fee.
Prepared by Redress Compliance · August 15, 2026 · Oracle advisory. Based on 30 to 40 deals where both models were on the table, 2024 to 2025.
Executive summary
The trajectory decides the model, not the framing. Where the estate was growing, the perpetual model saved 12 to 22 percent of lifetime cost. Where it was stable, a ULA with a disciplined certification beat it by 20 to 35 percent.
Four axes separate them: term, certification, support, and audit. Get those clear and the choice is straightforward.
The support reset is the ULA's hidden value. After certification you can review the certified estate and drop support on unused options. A perpetual agreement has no reset point at all.
Neither model covers anything outside the named scope. Unnamed options, adjacent products, and entities outside the schedule are ordinary audit exposure on either route.
In 6 of 10 dual model deals, Oracle proposed the model that favored its support annuity rather than the buyer's trajectory. The buyer chose correctly only where an independent lifetime model was built first.
The four axes, compared
| Axis | ULA | PULA |
|---|---|---|
| Term | Defined period, commonly three years | No closing date, ever |
| Certification | Declares a count that becomes perpetual | No equivalent event exists |
| Support | Reviewable after certification, options can be dropped | Runs indefinitely, with no reset point |
| Audit | Attention concentrates at the certification event | Lower routine friction, same scope exposure |
Where the money actually sits. Support, not the licence fee, produces the lifetime difference. After certification you hold discrete licences, so you can examine what you actually run and stop paying for what you do not. A perpetual stream has no such moment, and over a decade a perpetual support obligation on a stable estate can dwarf the saving of never certifying again. Compare both models across ten years including escalation, because the model that wins on the signing fee frequently loses once the annuity is summed.
What happens at certification, and why the PULA has no equivalent
Certification is the single most consequential event in a ULA lifecycle, because it converts unlimited usage into a fixed perpetual entitlement. You measure deployed quantities of the named programs, declare them, and Oracle converts the declared count into perpetual licences. That number becomes your support base from then on.
- Measure early, starting the count two years before expiry rather than in the final quarter.
- Certify on production reality, not on peak deployment or on a partitioning assumption, per the counting standard.
- Document everything, keeping the evidence Oracle will ask to see before it asks for it.
- Expect virtualized estates to need care, because processor and core rules decide how much of a cluster you are deemed to run.
Because a perpetual agreement never certifies, there is no moment to lock a number and no moment to reset support. The deal you signed is the deal you keep paying, which is exactly why the entry terms on a perpetual agreement carry so much more weight than they do on a timed one.
The Oracle cost optimization playbook
Where Oracle spend accumulates across support, licensing and cloud, and the buyer side moves that reduce it.
Get the playbook →Audit exposure is about friction, not immunity
Both models protect the named programs inside scope and nothing beyond it. Programs not named, options not listed, and entities not covered are normal exposure under either agreement, and those edges are exactly where a review probes first.
The difference is where the attention lands. A perpetual agreement lowers routine measurement friction on the named programs, because there is no certification to defend. A ULA concentrates attention at the certification event, where the count is fixed and both sides know it matters. Neither model changes what happens outside the list, and both raise cloud counting questions as workloads move to authorized cloud environments, so confirm in writing whether cloud deployments count toward the right before you sign either one.
The trajectory chooses the model, and the framing hides it
The standard line is that a perpetual agreement is the premium, worry free option and a ULA is the budget choice you will regret at renewal. In roughly six of ten comparisons we have run with both models properly priced, the deciding factor was not comfort at all. It was the deployment trajectory, and the ULA won clearly whenever the estate was stable or heading to cloud. Ignore the framing, build a ten year lifetime model for both options from your own capacity plan, and let the trajectory choose.
The reason the framing works is that it substitutes one true statement for the relevant one. It is true that a perpetual agreement removes certification work, and certification work is genuinely tedious. What the framing omits is that the same event is the only scheduled point in the relationship where your support base can go down. Buyers hear that they are avoiding an obligation. What they are actually declining is the one reset the agreement offers.
The two models diverge most in years six through ten, which is precisely the window vendor proposals rarely chart and buyers rarely model. In the first three to five years the perpetual route often looks cheaper, because a growing estate is consuming a right it has already paid for. What changes after that is not the price but the estate: deployment flattens, applications are retired, workloads move, and the annuity keeps compounding against a footprint that has stopped expanding. Cloud migration sharpens this, because a perpetual on premises unlimited right becomes a stranded cost the moment workloads leave, while a ULA lets you certify a smaller production footprint and reduce support as the data center shrinks.
So the practical test is not which model is better. It is whether your Oracle footprint on these specific named programs will still be growing in year eight. If yes, the perpetual model may genuinely be the cheaper instrument. If no, or if you cannot answer with funded plans, the ULA and its reset is worth considerably more than the discount you are being offered to give it up. The ten year price of that option is worked through in the PULA versus ULA pillar, the instrument itself on the Oracle PULA page, and the exit route in the exit playbook.
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.
- Scenario simulation before the call: growing, stable and cloud bound trajectories priced on both models
- Every risky clause flagged with the exact quote, the page, and the replacement language
- A negotiation playbook, talking points, and a two page executive brief on day one
What the comparison file shows
Across roughly 30 to 40 deals where both unlimited models were on the table in 2024 and 2025, the outcome split cleanly by trajectory:
Across ten years, driven almost entirely by the support reset that follows a disciplined certification.
Where deployment on the named programs genuinely kept compounding against repeated ULA cycles and repeated fees.
The patterns: comparisons run on the signing fee, trajectories taken from ambition, and the support reset left out of the model entirely.
The buyer chose correctly only where an independent lifetime model was built first. The wider library sits in the Oracle practice.
Your first five moves
- Write a ten year deployment trajectory for the named Oracle programs, sourced from the capacity plan rather than from the proposal.
- Price both models across the full horizon, including support escalation, and label your estate growing, stable, or cloud bound.
- Confirm named programs, entity scope and cloud counting in writing in both draft agreements, since neither model covers anything outside the list.
- If a ULA fits, schedule certification two years before expiry so the count is defensible rather than hurried.
- If a perpetual agreement fits, negotiate a defined conversion path at entry, because there will be no natural moment later. The Oracle practice builds the comparison with you.
Frequently asked questions
What does PULA stand for in Oracle licensing?
Perpetual Unlimited License Agreement. It carries the same unlimited deployment right as a ULA for a named set of Oracle programs, but it never expires and never certifies, so the count and the support stream both continue indefinitely.
On which four axes do the models actually differ?
Term, certification, support, and audit. The ULA runs for a defined period and closes with a certification that fixes a perpetual count. The perpetual model has no closing date, no certification, and therefore no support reset. Audit exposure differs in friction rather than in immunity, because neither model covers anything outside the named scope.
Which model is cheaper over ten years?
It depends on trajectory. Where the estate was growing, the perpetual model saved 12 to 22 percent of lifetime cost against repeated ULA cycles. Where the estate was stable, a ULA with a disciplined certification beat it by 20 to 35 percent. The signing fee is a poor guide to either answer.
Can you reset Oracle support under a PULA?
No. There is no certification event and no reset point, so the support stream runs indefinitely. A ULA lets you certify, freeze the count, review the certified estate and drop support on unused options afterwards, which is the largest part of its lifetime value and the part most comparisons leave out.
How is the certified count calculated in a ULA?
It is the measured deployment of the named programs at expiry, converted to perpetual licenses using Oracle's processor and core rules. Virtualized estates need careful measurement, because a partitioning assumption can inflate the count well above the production footprint you can defend.
Does a PULA protect you in an audit?
Only on the named programs within the agreed scope. It lowers routine measurement friction because there is no certification to defend, but unnamed options, products outside the list, and entities outside scope remain ordinary exposure under either model. Both raise cloud counting questions as workloads move.
Why does Oracle often propose the perpetual model?
Because it secures a perpetual support annuity. In roughly six of ten dual model deals, Oracle proposed the model that favored its own recurring revenue rather than the buyer's deployment trajectory. That is not a reason to reject it, but it is a reason to build your own lifetime model before responding.
How does cloud migration change the comparison?
It favors the ULA. A perpetual on premises unlimited right becomes a stranded cost when workloads move, while a ULA lets you certify a smaller production footprint and reduce support as the data center shrinks. Confirm in writing whether cloud deployments count toward the right before signing either model.
How to Negotiate an Oracle ULA: No Price List, Just Your Business Case
There is no price list: the ULA fee is a story built from your estate and your growth. Give conservative growth answers, keep the product list narrow, model the breakeven yourself, and negotiate the certification exit before you sign.
