A ULA gives you unlimited deployment of named Oracle products for a fixed term — usually three years — after which you certify your usage into a perpetual license count. A PULA (Perpetual ULA) gives the same unlimited deployment with no end date and no certification event: you never have to count, but you can also never certify out and stop paying for growth. In short, a ULA is a sprint with a finish line where you bank what you built; a PULA is unlimited use forever, at the price of never being able to exit and recover value. The comparison table below maps the decision, and the rest of this article covers certification risk, cost, and when each fits.
The defining difference is the certification event. Under a standard ULA you deploy without counting for the term, then at expiry you declare ("certify") the quantity in use, and that number becomes your perpetual entitlement — you keep it and pay only support thereafter. A PULA removes that event entirely: the unlimited grant is perpetual, so there is nothing to certify and nothing to walk away with. You hold unlimited deployment rights for as long as you pay support, but you can never convert the agreement into a fixed count you own outright and renegotiate around.
That single structural difference cascades into everything else — exit options, certification risk, cloud and virtualization treatment, and price. For the foundational mechanics of the standard ULA, see our Oracle ULA restructuring practice page and the Oracle ULA guide; this article focuses on how the perpetual variant changes the calculus.
The table below is the one-page summary we put in front of clients weighing the two structures. Read it as a decision aid, not a verdict — the right answer depends on your deployment trajectory and your appetite for the certification cliff.
| Dimension | ULA (term) | PULA (perpetual) |
|---|---|---|
| Term | Fixed, usually 3 years | Perpetual — no end date |
| Certification event | Yes, at expiry | None |
| Exit / value recovery | Certify a count and stop paying for growth | No exit; unlimited use only while you pay support |
| Best when | Aggressive deployment over a fixed window | Permanent, steadily growing Oracle estate |
| Main risk | Certification under- or mis-count | Locked in; support fee perpetual |
| Cloud / virtualization | Counted at certification — high scrutiny | Unlimited, but exit complexity if you migrate off Oracle |
| Relative price | Lower up-front | Premium over comparable ULA |
Indicative comparison from buyer-side Oracle engagements. Every PULA/ULA is bespoke; terms vary by negotiation.
We model both structures against your deployment trajectory and certify ULAs for a living. Scoping calls are no-obligation.
Certification risk is the danger that the count you declare at ULA expiry is wrong in a way that costs you. Under-count and you forfeit entitlement you paid three years of support to build. Mis-count virtualized or cloud deployments and Oracle may dispute the certification, turning the moment that should bank your value into the opening of an audit. We have seen certifications swing seven figures on how a single VMware cluster or OCI deployment is treated. A PULA removes this specific risk because there is no certification — but it replaces it with a different one: you are locked into a perpetual support stream with no clean mechanism to right-size or exit if your Oracle footprint later shrinks.
So the question is not "which is safer" but "which risk do you prefer to carry": the one-time certification cliff of a ULA, or the permanent lock-in of a PULA. Buyers planning to migrate workloads to other databases or to the cloud over the next five years should be especially wary of the PULA's missing exit. The certification mechanics and how we defend them are covered in Oracle ULA exit strategy.
Our framework for ULA structuring, certification and exit negotiations.
A ULA fits when you have a defined window of aggressive Oracle growth — a major migration, an acquisition to integrate, a new platform rollout — and you intend to deploy hard, certify a large count, and then stop paying for further growth. The economics work when your certified count at expiry materially exceeds what you would have bought à la carte, and when you have the discipline and tooling to maximise and accurately certify deployment. The danger is the opposite: signing a ULA, under-deploying, and certifying a count barely above where you started, having paid a premium for unlimited rights you never used.
A PULA fits organisations with a permanent, steadily growing Oracle estate and no realistic intention of leaving the platform — large enterprises where Oracle is structurally embedded, where certification would be a perennial headache, and where the predictability of unlimited use outweighs the loss of an exit. For these buyers the PULA removes a recurring compliance burden: no three-yearly certification scramble, no audit exposure on deployment counts, no renegotiation cliff. The price is permanence — you are committing to Oracle, and to its support stream, effectively forever. That is a strategic decision, not just a procurement one, and it should be made with eyes open to the long-run Oracle cost it locks in.
If you are also evaluating restricted-use options as a cheaper alternative to unlimited rights, compare against Oracle ASFU licensing before committing. And as with SAP's unlimited and conversion structures, the unlimited agreement only pays off if your real deployment trajectory justifies it.
A ULA (Unlimited License Agreement) grants unlimited deployment of named products for a fixed term, usually 3 years, after which you certify usage into a perpetual count. A PULA (Perpetual ULA) grants the same unlimited deployment with no end date and no certification event — you never have to count, but you can also never exit and recover value.
Neither is universally better. A PULA removes certification risk and suits organisations with permanent, growing Oracle estates. A ULA suits buyers planning aggressive deployment over a fixed window who intend to certify a large count and then stop paying for growth. The PULA's lack of an exit is its main drawback.
At the end of a ULA term you must certify the quantity deployed, which becomes your perpetual entitlement. Certification risk is the danger of under-counting (losing entitlement you paid to build) or mis-counting virtualized and cloud deployments in ways Oracle later disputes. A botched certification can erase the ULA's value.
Not in the way you exit a ULA. A PULA has no certification event, so there is no moment where deployment converts to a perpetual count you keep. You retain unlimited use as long as you pay support, but you cannot certify and walk away. Exit generally means negotiating a conversion or migration, which is complex.
Both are priced as a large up-front fee plus annual support (typically 22% of an agreed base). PULAs command a premium over comparable ULAs because they remove the certification cliff for Oracle. Pricing is entirely negotiated — there is no list price — so benchmarking against comparable deals is essential.
Weekly compliance intelligence for IT leaders.
