The decision rule is structural, not financial: a ULA is unlimited deployment for a fixed term that ends in a scheduled choice — certify out into a fixed license count or renew — while a PULA is unlimited deployment with no end date, no scheduled certification, and a support stream that runs for as long as the rights do. Choose the ULA when you want a costed exit on the calendar; consider the PULA only when the estate is so large, stable and long-horizon that the exit you are giving up has no realistic value.
Published 3 February 2026 · Last reviewed 18 March 2026
| MECHANIC | ULA (TERM) | PULA (PERPETUAL) |
|---|---|---|
| Duration | Fixed term, typically 3–5 years | No end date; runs while the agreement and support stand |
| End-of-term event | Scheduled: certify deployments into fixed perpetual licenses, or renew | None scheduled; certification only on contract-defined termination triggers |
| Product scope | Defined list per term; renegotiable at each renewal | Defined at signature; effectively fixed for the life of the agreement |
| Commitment shape | Term fee plus annual support through the term | Larger upfront commitment plus a support stream that continues indefinitely |
| Support economics | Escalation exposure bounded by the term; reset point at certification or renewal | Escalation compounds with no natural reset; reductions impractical under repricing policies |
| Exit mechanics | Certification converts usage into a perpetual license count you keep | Exit is a termination event; rights and any count-and-convert path depend on drafted terms |
| Negotiation cadence | Built-in leverage point every term end | No recurring leverage point after signature |
| Availability | Standard Oracle commercial structure | Offered selectively, generally to the largest Oracle customers |
Everything that follows is an unpacking of one row: the end-of-term event. A ULA forces a decision onto the calendar; a PULA removes the calendar. Whether that removal is a feature or a defect depends entirely on what your Oracle estate will look like in ten years — which is why this comparison is really a forecasting exercise wearing a contracting question's clothes.
This guide is general information about Oracle commercial structures, not legal or licensing advice for your situation; unlimited agreements are individually drafted and your contract governs. It names no firms; the firm directory lists Oracle-capable advisors with balanced pros and cons, listed, not ranked.
An Oracle ULA grants unlimited deployment of a negotiated list of products — commonly Database, options and packs, middleware, sometimes more — for a fixed term. During the term you deploy freely within the contract's scope: the named legal entities, the agreed territory, and whatever the agreement says about public cloud. At the end you face the fork this site covers in its own guide, certify out or renew: count everything deployed, declare it to Oracle, and walk away with that count as fixed perpetual licenses — or sign another term.
A PULA takes the same unlimited grant and removes the term. There is no expiry date, no scheduled count, no renewal negotiation. The rights persist for as long as the agreement stands, which in practice means for as long as the support relationship stands: support under a PULA is not optional maintenance but the thread the unlimited rights hang on. Certification exists only as a termination mechanism, triggered by events the contract defines — ending support, a change of control, mutual agreement to wind up — and the quality of that exit depends entirely on language negotiated before signature, at the one moment you had leverage.
The scope mechanics differ in a way that matters more than it first appears. A ULA's product list is revisited every renewal; products that no longer fit the architecture can drop out of the next term's list, and new ones can be added against a new fee. A PULA's list is set once. Architecture moves — estates re-platform, workloads containerize, analytics move to other stacks — but the agreement and its support stream do not move with them. Ten years in, many PULA holders are paying a support stream sized for an estate they no longer run.
Neither structure's headline fee is where the money is. In both, the dominant long-run cost is the annual support stream, calculated as a contractual percentage of the license fee and subject to annual escalation. The structural difference is duration of exposure. A ULA's support commitment runs to the end of the term: escalation bites for three to five years, and then certification or renewal creates a natural reset point where the whole position can be renegotiated. A PULA's support stream has no reset point. It escalates year over year for the life of the agreement — and recent escalation rates across the industry have been materially higher than the historical norm, which compounds dramatically over a fifteen- or twenty-year horizon.
Two policies sharpen the point. First, support reductions are constrained by Oracle's repricing rules: dropping part of a support contract typically triggers repricing of what remains, which is why partial reductions rarely save what they appear to. Second, under a PULA the support base cannot meaningfully shrink at all without threatening the unlimited rights themselves — the structure is binary, supported-and-unlimited or terminated. A buyer evaluating a PULA should therefore model the support stream to a twenty-year horizon at realistic escalation rates, and ask whether unlimited rights to today's product list will still be worth that stream when the architecture has moved twice.
This is also the honest way to read Oracle's side of the trade. A PULA converts a customer's license relationship into a predictable, escalating, very-long-duration annuity — a perfectly rational thing for a vendor to want, and described here factually rather than critically. The buyer's question is symmetric: is the certainty you are buying worth the annuity you are granting?
The ULA is a strong fit for organisations in a defined growth phase: a migration consolidating onto Oracle Database, an M&A integration multiplying deployments, a platform build-out where counting licenses deployment-by-deployment would cost more than the unlimited grant. The term structure matches the project structure — deploy hard during the window, then certify a high-water mark into perpetual licenses and step off the unlimited treadmill. The scheduled exit is the product.
The PULA has a plausible fit in a much narrower band: very large estates, stable or growing on a decade-plus horizon, where Oracle is a permanent layer of the architecture and successive ULA renewals have become a ritual that consumes negotiation effort without changing the outcome. For that buyer, the PULA trades away an exit that was never going to be used in exchange for never having to negotiate the renewal again. The honest test: if there is any realistic scenario in which the estate shrinks, re-platforms, or partially leaves Oracle within ten years, the scheduled exit has value and the PULA surrenders it.
Trajectory, not size, is the discriminator. A large but plateauing estate is better served by a final ULA term and a well-prepared certification than by a perpetual agreement. A genuinely compounding estate may be better served by the PULA — provided the termination and certification language is negotiated as carefully as the fee, because that language is the only exit the structure has. Modelling this fork honestly is precisely the work of an independent Oracle licensing advisory engagement, done before the vendor's own proposal frames the choice.
Certification and termination language. In a ULA, the certification clause defines how deployments are counted at exit — including whether and how public cloud deployments count, a question on which contract language varies widely and on which Oracle's cloud counting policies have changed several times. In a PULA, the termination clause is the exit: what triggers it, what happens to the rights, whether a count-and-convert path exists. In both cases the clause is negotiated at signature and tested years later, under conditions nobody predicted.
Entity, territory and M&A scope. Unlimited agreements bind named legal entities in defined territories. Acquisitions are commonly excluded or capped; divestitures can strand deployments outside the agreement overnight. A PULA compounds the stakes because the language must survive decades of corporate change rather than one term — change-of-control wording deserves particular scrutiny, since it can convert a routine transaction into a termination event.
Compliance posture during the unlimited period. Unlimited does not mean unmonitored. Products outside the agreement's list remain ordinary compliance exposure, and estates under unlimited agreements habitually drift into using options and packs that were never in scope — precisely because nobody is counting. A periodic internal effective license position against the agreement's actual scope is cheap insurance under either structure, and under a ULA it doubles as early certification rehearsal.
The conversion pitch. A maturing ULA often attracts a PULA proposal — framed, reasonably enough, as removing renewal friction. Price it as what it is: the purchase of your scheduled exit. The counterparty across the table negotiates unlimited agreements every week; most buyers see one a decade, which is the asymmetry that makes independent negotiation support worth its fee on this specific decision.
Signing the PULA for prestige rather than trajectory. The perpetual structure flatters the buyer — it is selective, senior-sponsored, framed as a partnership milestone. None of that changes the arithmetic of an escalating perpetual support stream against a flat deployment curve.
Treating the PULA's exit as theoretical. Because no calendar forces the question, PULA termination language gets less negotiation attention than ULA certification language — exactly backwards, since the PULA's exit terms must work decades later with zero leverage remaining.
Letting the product list fossilize. Under both structures, paying unlimited-agreement support for products the architecture abandoned is pure waste; under a PULA there is no renewal at which the list naturally gets pruned. Inventory scope against actual usage annually.
Ignoring cloud counting language at signature. Whether AWS, Azure and OCI deployments count toward a ULA certification — and on what counting rule — is contract-specific and has been a moving target across policy revisions. The time to lock the rule is signature, not certification eve.
Assuming unlimited means everything. The grant covers the listed products for the named entities in the agreed territory — nothing else. Options, packs and products outside the list remain countable, auditable exposure throughout.
Negotiating the fork inside the vendor's timeline. Both the ULA-end decision and a PULA proposal arrive on Oracle's calendar, attached to Oracle's framing. The counter is to model certification value, support trajectory and architectural forecast before the conversation starts — and choosing who does that modelling is its own decision.
The fork at the end of every term →
The metric your certification lands on →
The support stream question itself →
How to pick the firm for this work →
Firms that negotiate unlimited agreements →
Every field guide on the site →
A ULA (Unlimited License Agreement) grants unlimited deployment rights for a defined set of Oracle products for a fixed term, usually three to five years, and ends in a scheduled event: certify your deployments into a fixed number of perpetual licenses, or renew for another term. A PULA (Perpetual Unlimited License Agreement) grants the same unlimited rights with no end date and no scheduled certification — the unlimited rights continue for as long as the agreement and its support stream stay in place.
Not on a schedule. Certification under a PULA is triggered only by termination events defined in the contract — typically ending the support relationship, a change of control, or mutual agreement to wind the agreement up. What happens at that point depends entirely on the drafted terms; some agreements provide a count-and-convert path similar to ULA certification, others are far less generous. The trigger language is therefore one of the most important clauses in the document.
In practice, no — in both structures the support stream is tied to the agreement as a whole, and Oracle’s repricing policies make partial reductions economically unattractive. The difference is duration: a ULA’s support commitment runs to the end of the term, where renegotiation is possible, while a PULA’s runs indefinitely. Product scope and support terms should be treated as fixed for the life of whichever agreement you sign.
PULAs are not a catalogue item; Oracle offers them selectively, generally to its largest customers — organisations with very large, stable, long-horizon Oracle estates for which repeated ULA renewal cycles add negotiation overhead without changing the outcome. For an estate that may shrink, re-platform, or move workloads off Oracle within a decade, the absence of a scheduled exit usually weighs against the perpetual structure.
It depends on trajectory, not list price. A ULA prices unlimited rights for a term and gives you a costed exit; its long-run economics depend on what you certify and what support you carry afterwards. A PULA front-loads a larger commitment and attaches a support stream that continues — and typically escalates — for as long as you keep the rights. Growing estates can amortize a PULA well; flat or shrinking estates usually cannot. Model both against a realistic ten-year deployment forecast before deciding.
Oracle does periodically propose converting a maturing ULA into a PULA, particularly where the customer has renewed more than once. The reverse — converting a PULA back into a fixed-term ULA or a certified license position — is a termination event governed by the contract’s exit language, not a routine commercial motion. Treat any conversion proposal as a full renegotiation and price the loss of the scheduled exit explicitly.
Deciding between a term with an exit and unlimited forever is exactly what an Oracle licensing advisor is for. The directory lists the firms that do this work, with balanced pros and cons, listed, not ranked.
Tell us the vendor, the service you need and where things stand, and we will route your brief to firms that genuinely cover that combination. The directory and matching are free for buyers, no vendor ever sees your brief, and we add no markup.
Our weekly dispatch on vendor audit programs, regional developments and one buyer move. Subscribe to The Licensing Radar.