A PULA is a perpetual ULA, and its unlimited grant has no fixed end date. Because nothing expires, there is no certification event to convert deployment into a fixed entitlement and stop the unlimited fee. Exit becomes a negotiation, not a right, so the time to govern a PULA is before you sign and every day after.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
A PULA is a perpetual ULA. Its grant of unlimited deployment has no fixed end date, so there is no certification event that converts deployment into a fixed entitlement and stops the unlimited fee. In a standard ULA the term expires, and that expiry forces the certify or renew decision. The perpetual structure removes the expiry, and with it the trigger. There is no clock running down to a moment when you declare your deployed quantities and walk away with a permanent entitlement, because the agreement was written never to reach that moment.
A PULA is a perpetual ULA with no certification exit. The unlimited right continues, and so does the fee that supports it, until you negotiate a different arrangement.
A standard ULA grants unlimited deployment of named Oracle products for a fixed term, usually three to five years, for a fixed fee. At the end you certify, converting your deployed quantities into a perpetual entitlement, or you renew. The term is the engine of the whole arrangement, because the expiry is what gives the customer its one chance to convert unlimited use into permanent value. A PULA keeps the unlimited grant but strips out the term. The deployment right is genuinely perpetual, which sounds generous and sometimes is, but the cost is the loss of the exit that makes a standard ULA valuable to the buyer.
The upside of a PULA is real for the right organisation. Unlimited deployment that never expires removes the pressure of the ULA clock, suits an estate that will keep growing indefinitely, and avoids the cost and effort of repeated certifications and renewals. For an organisation that is certain it will deploy heavily and forever, that can be a rational trade.
The downside is the missing exit. You can never convert the deployment into a fixed, owned entitlement on your own initiative, and you can never stop the perpetual fee by certifying. The support obligation continues, and it continues at the PULA level. If your deployment ever shrinks, or your strategy changes, the perpetual fee keeps buying a right you may no longer need.
Yes, but not by certifying. Exit from a PULA is a negotiated event, not a contractual right. Because the agreement does not provide a mechanism, any exit has to be agreed with Oracle, and that means it happens on commercial terms rather than as a clause you can simply invoke. The realistic routes are a negotiated conversion to fixed entitlements, a broader restructuring of the agreement, or a deliberate reduction of the estate so that the perpetual fee buys less than it costs. Every one of these depends on the specific contract language, and in PULA work it usually does, so the wording of your own agreement is where any plan has to start.
The cleanest exit is to agree with Oracle a conversion of the perpetual right into fixed, owned licenses, after which the PULA fee ends and you hold a defined entitlement. This is a negotiation, so it requires leverage, and the leverage comes from a measured, defensible deployment baseline and a credible reason for Oracle to agree. Approaching it from strength is the difference between a clean conversion and a stalled conversation.
Sometimes the better move is not a full exit but a restructuring, for example folding the PULA products into a different commercial arrangement that suits the estate as it now stands. This is contract specific and commercially complex, but it can release value where a straight conversion is not on offer.
Where neither conversion nor restructuring is available, the remaining lever is the estate itself. If the perpetual fee is buying far more than you use, decommissioning or migrating workloads changes the economics of staying in the PULA and strengthens the case for a negotiated change. This is slow and deliberate work, not a quick exit, but it is sometimes the only honest path.
Take an indicative organisation that signed a PULA expecting indefinite growth, then changed strategy and began consolidating its Oracle estate. The deployment falls, but the perpetual fee and the support that sits on top of it do not. Year after year the organisation pays the PULA level for a right it uses less and less. The figures are indicative and every situation depends on the contract, but the pattern is the trap of the structure: a PULA priced for endless growth becomes expensive the moment growth stops, and the absence of a certification exit means the cost cannot be switched off without a negotiation.
| Feature | Standard ULA | PULA |
|---|---|---|
| Term | Fixed, usually three to five years | Perpetual, no end date |
| Certification exit | Yes, at term end | None |
| How the fee stops | By certifying out | Only by negotiation |
| Best fit | Defined growth then exit | Indefinite heavy growth |
If you already hold a PULA, the work shifts from exiting to governing. Because there is no certification, the customer definition, the entity list, and the territory clauses matter throughout the life of the agreement rather than only at an exit, and corporate change can either dilute or concentrate the value of the perpetual right. The discipline is to keep a clear, current record of deployment and scope, so that if a conversion or restructuring ever becomes possible you can negotiate from a measured position. The same scope risks that bite a standard ULA at exit are live in a PULA every day, and they are at their sharpest during M&A, which we cover in M&A under a PULA.
The PULA and the capped ULA sit at opposite ends of the unlimited spectrum. A capped ULA bounds the unlimited right and ends in a certification, giving a defined exit, while a PULA removes the boundary and the exit alike. Understanding where each fits is part of choosing a structure deliberately rather than accepting the one Oracle proposes, and the trade offs are set out in capped ULA versus standard ULA.
The defining fact of a PULA is the missing certification exit, and that single feature reshapes every decision around it. Before signing, weigh the perpetual fee against a realistic forecast of growth, not a hopeful one. After signing, govern scope and deployment continuously, and keep a measured baseline ready in case a negotiated conversion ever becomes possible. The full treatment of perpetual agreements, including when one is the right choice, lives in our pillar, the PULA guide.
A PULA is a perpetual ULA with no certification exit, so the unlimited fee and the support on top of it never stop on their own. Exit is a negotiation, not a right, reachable only through a conversion to fixed entitlements, a restructuring, or a deliberate reduction of the estate, and every route depends on the contract. Treat the perpetual grant as a long term commitment to govern, and keep a measured baseline ready for the day a conversation becomes possible.
A PULA is a perpetual ULA. Its grant of unlimited deployment has no fixed end date, so there is no certification event that converts deployment into a fixed entitlement and stops the unlimited fee. Without a term that expires, the trigger that forces a certify or renew decision in a standard ULA simply does not exist.
Yes, but not by certifying. Exit from a PULA is a negotiated event, not a contractual right. The realistic routes are agreeing a conversion to fixed entitlements with Oracle, restructuring the agreement, or reducing the estate so the perpetual fee buys less than it costs. Each depends entirely on the specific contract language.
Book a confidential assessment and we will read your perpetual agreement, measure your real deployment, and map the routes to a negotiated exit or restructuring.