A PULA sounds like the ultimate convenience: unlimited Oracle, forever, no certification deadline. The absence of that deadline is exactly what can turn it into a permanent liability. Here is how to tell.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
A PULA is a perpetual ULA with no certification exit. It becomes a trap when your deployment stops growing, when you want the freedom to leave Oracle, or when corporate change is likely, because you can never crystallise your count into a finite entitlement and walk away. You hold unlimited rights forever, but you also hold an indefinite support obligation and lose the single most valuable moment a normal ULA gives you. Assess that permanence carefully before you sign.
A standard ULA grants unlimited deployment of named Oracle products for a fixed term, usually three to five years, and then ends. At that ending you certify, declaring how many processors you have deployed, and that declaration becomes your perpetual entitlement. The unlimited right stops, but you walk away owning a finite, defensible number of licenses that no longer depend on a fresh agreement with Oracle. That certification event is the most valuable moment in the whole arrangement, because it is where unlimited deployment converts into permanent, owned value.
A PULA removes that moment entirely. The unlimited right is perpetual, so there is never a term end and never a certification. You can deploy without limit for as long as you keep paying support, but you can never convert those deployments into a counted, owned entitlement and exit. The permanence that is sold as freedom is the same feature that locks the door behind you.
A PULA works against you whenever the value of unlimited deployment has peaked and the cost of permanence keeps running. The clearest signals are a deployment that has stabilised, a desire to reduce your Oracle footprint, and any prospect of corporate change. In each case the missing certification exit is the thing that hurts.
Unlimited deployment is only worth a premium while you are deploying a lot. Once your estate has matured and your processor count is stable, you are paying for headroom you no longer use. With a normal ULA you would certify the stable count and own it. With a PULA you keep paying for the unlimited right indefinitely while gaining little from it, and there is no event at which you can stop and lock in what you have.
Strategies change. You may move workloads to other databases, consolidate, or repatriate. A certified ULA gives you a finite entitlement you can shrink around over time. A PULA keeps you tied to the Oracle support stream with no clean way to crystallise your position and step down, because the count is never fixed and the agreement never ends. The exit you would eventually want simply does not exist in the contract.
Mergers, acquisitions, and divestitures are where the customer definition and the absence of an exit bite hardest. A normal ULA has a term end you can plan around. A PULA carries its scope and its support obligation perpetually, and disentangling it during a transaction is far harder when there is no certification point at which to draw a line. If your organisation is a plausible buyer, seller, or target, the permanence becomes a complication rather than a convenience.
The value of a ULA lives in its exit. The certification event is where unlimited deployment becomes owned, finite, vendor independent value. A PULA sells you the unlimited part and quietly removes the exit. Before you accept that trade, be sure the permanence genuinely serves a long, unbounded growth plan, because once signed it is very hard to undo.
The structure is not always wrong. A PULA can suit an organisation with genuinely unbounded, long term expansion across the licensed products, where the unlimited right will be used heavily and continuously for many years and where leaving Oracle is not part of the strategy. For a fast growing enterprise standardising deeply on Oracle, the certainty of never recounting and never renegotiating can have real value. The point is not that a PULA is always a trap. It is that the trap is invisible at signing and only appears later, so the decision deserves the same rigour you would give an acquisition.
Consider an anonymized manufacturer weighing a PULA against a standard ULA it could certify in three years. Under the PULA, it pays the unlimited fee and an indefinite support stream, and its deployment is expected to plateau within two years. Under the ULA, it deploys hard for the term, certifies a count that reflects that peak deployment, and then owns those licenses outright while support continues at the existing level. Modelled over ten years, the certified path left the manufacturer with a finite entitlement it controlled and the freedom to shrink support around unused licenses later, while the PULA left it paying perpetually for headroom it had stopped using. The figures are indicative and the right answer depends on the specific deployment trajectory, but the structural difference is the point: only one path has an exit.
Before accepting a PULA, ask what your deployment will realistically look like in five and ten years, whether you might want to reduce your Oracle footprint, whether corporate change is plausible, and what the perpetual support obligation totals over a long horizon. Then compare that honestly against a standard ULA you could certify. If the unlimited right will not be used hard and continuously for a long time, the missing exit is likely to cost you more than the convenience is worth.
If a PULA is on the table, or you already hold one and want to understand your options, model the permanence before you commit to it. See how to run an estate you cannot certify in governing deployment under a PULA, understand the paths between structures in converting between ULA structures, and ground the decision in our PULA and capped ULA guide.
Book a ULA assessment and we will model a PULA against a certifiable ULA on your real deployment trajectory, so you understand what the missing exit costs before you sign anything.