The PULA Decision Brief

Most Oracle Unlimited License Agreements end in a decision. The customer reaches the close of the term and either certifies the deployed quantities into a perpetual entitlement or renews the unlimited right for another term. A perpetual ULA, almost always written as a PULA, removes that ending entirely. There is no term close, no certification letter, and no moment where the unlimited right converts into a fixed and final license count. The agreement simply continues, and so does the support bill that funds it.

That single difference changes the entire commercial picture. With a term ULA, the customer always holds one decisive card, the ability to certify and walk away from the unlimited right. A PULA takes that card off the table. This brief sets out what a perpetual agreement really costs over time, where the hidden scope risk sits, why support behaves the way it does, and the structured review that puts leverage back into the buyer's hands. We are an independent advisory, we hold no Oracle quota, and we sit on the buyer side of the table.

What exactly is a PULA, and why is there no exit?

A PULA grants unlimited deployment of a named set of Oracle products, for the organisations and territories defined in the contract, with no end date. Where a term ULA says the unlimited right lasts three to five years and then ends in certification or renewal, a PULA says the unlimited right is permanent. Because the right never ends, there is no event that triggers a certification. The mechanism that converts deployment into a capped, owned entitlement, the very thing that gives a term ULA its value at exit, does not exist in a PULA.

This is often sold as a benefit, and on paper it reads like one. The customer gains permanent freedom to deploy the covered products without counting, forever, with no renewal negotiation ever again. In practice the permanence cuts the other way. The customer is locked into the support stream that funds the agreement, with no natural moment to reset the relationship, renegotiate the price, or convert to a smaller fixed footprint. The freedom to deploy is real. The freedom to leave is what has been removed.

Organisations usually arrive at a PULA in one of three ways. Some are offered a perpetual agreement as the resolution to a difficult audit, where the unlimited right is presented as a clean line under a compliance problem. Some accept a PULA at the end of a term ULA when the deployment is large, growing, and genuinely suited to permanent unlimited use. And some are sold the perpetual option as a premium upgrade during a renewal, on the promise that they will never have to negotiate again. Each route can be defensible, but each also tends to move quickly, with the long term cost and the loss of leverage given less weight than the immediate relief. Knowing how you arrived helps you judge how well the agreement still fits.

How does a PULA differ from a term ULA?

The two agreements look similar in the first year. Both grant unlimited deployment of named products for a fixed fee, both carry an annual support charge, and both use the same processor and Named User Plus counting rules for the products in scope. The divergence is at the end, and the end is where most of the value in a term ULA is created. The table below sets the two side by side on the points that matter to a buyer.

Read down the right column and the pattern is clear. Every feature that gives a buyer a recurring moment of leverage in a term ULA is absent in a PULA. The perpetual agreement trades the periodic discomfort of a renewal for the permanent comfort of unlimited deployment, and in doing so it hands the structural advantage to the vendor for the life of the relationship.

What does a PULA really cost over time?

The headline price of a PULA is the upfront fee, and that number gets the attention. The number that actually dominates the lifetime cost is support. Support is charged annually, it is set as a percentage of the licensing value baked into the agreement, and it is subject to the standard uplift each year. Over a long horizon the cumulative support outlay dwarfs the upfront fee, and because a PULA has no certification event, there is no natural point at which the support base is reset to reflect what the organisation actually runs.

Consider the arithmetic at a high level. A term ULA holder who certifies converts to a fixed, owned entitlement and continues to pay support on that owned base. If the estate later shrinks, the holder has options to reduce the supported footprint over time. A PULA holder has no such conversion. The support stream continues against the agreement as written, regardless of whether deployment is growing, flat, or falling. The figures below are indicative and illustrate the shape of the cost, not a quote for any specific agreement.

The figures are indicative, but the lesson generalises. In the first five years the upfront fee looks like the main event. By year ten the support stream has become the larger number, and it keeps running. A perpetual agreement is, in cost terms, a support subscription with no off ramp. The discipline for a PULA holder is to manage that subscription as deliberately as any other recurring spend of the same size, because no contract event will do it automatically.

There is a second cost that rarely appears in any model, the opportunity cost of locked attention. A term ULA forces a periodic review of the whole Oracle relationship, and that review often surfaces savings well beyond the agreement itself, in adjacent products, in cloud strategy, and in architecture. A PULA removes the prompt. Years can pass without anyone asking whether the estate still fits the business, whether cheaper deployment patterns are available, or whether the support spend is proportionate to the value delivered. The cost of a perpetual agreement is therefore not only the support invoice but the savings never pursued because nothing ever forced the question. The leverage review exists precisely to put that question back on the calendar.

Where does the customer definition risk bite?

Every ULA defines who is allowed to use the unlimited right. This customer definition names the legal entities, and often the territories, that the agreement covers. In a term ULA, a mismatch between the definition and reality is surfaced and resolved at certification, when the deployed estate is measured against the entities in scope. A PULA has no certification, so a customer definition problem can sit unexamined for years, growing quietly, until an audit or a corporate event brings it into the open.

The risk is sharpest around corporate change. If the organisation acquires a business and deploys the covered Oracle products into the acquired entity, that entity may sit outside the customer definition. Under a term ULA the customer would address this before exit. Under a PULA the deployment can continue for years in an entity the agreement never covered, accumulating exposure the whole time. The same applies to divestitures, where a sold business may carry deployments it no longer has the right to run, and to expansion into territories the agreement excludes.

Because the answer turns entirely on the words in your specific customer definition, this is one of the places where contract language decides everything. Two PULAs with apparently similar scope can produce very different outcomes after an acquisition, depending on whether the definition is drawn around named entities, around a corporate group with a control test, or around something narrower. Read the definition before you rely on it, and read it again after any change of corporate structure. For a deeper treatment, see the analysis of the perpetual ULA customer definition risk linked at the close.

Does support ever stop or fall under a PULA?

Support does not fall on its own, and that is the central commercial fact of a perpetual agreement. Under Oracle's standard terms, support is sold against the licensing value of the agreement, and the perpetual nature of a PULA means there is no certification event that resets that value to a smaller, owned count. The support base set when the agreement was signed continues, subject to the standard annual uplift, for as long as the agreement stands. Deploying more does not raise it, and deploying less does not lower it.

That last point cuts both ways and is widely misunderstood. The good news is that growth inside a PULA carries no incremental support charge, which is the freedom the agreement was bought for. The hard news is that shrinkage carries no automatic saving. An organisation that decommissions half its Oracle estate under a PULA does not, by that act alone, reduce its support bill. Any reduction has to be engineered deliberately and is constrained by the agreement's terms and by Oracle's repricing rules on partial termination, which often make a partial reduction less attractive than it first appears. Whether and how support can be reduced is, again, contract specific and should be modelled against your own agreement rather than assumed.

Where is the buyer leverage in a perpetual agreement?

A term ULA gives the buyer a recurring moment of leverage at every renewal. A PULA has no such moment, so the leverage has to be created rather than waited for. The good news is that it can be. Leverage in a perpetual agreement comes from knowledge and from credible alternatives, not from a contract date. An organisation that knows exactly what it runs, what it actually needs, and what its realistic options are holds far more power than one that simply pays the annual support invoice without question.

We call the structured way to build that position the leverage review. It is a deliberate exercise, run on a cycle rather than triggered by a contract event, that rebuilds the negotiating position a perpetual deal is designed to remove. It rests on four moves: decommissioning what is no longer needed, optimizing what remains, evaluating the support relationship including third party support, and putting governance around the whole agreement so the position never decays again.

What are the four moves of the leverage review?

The review runs as a sequence. Each move produces an artifact a board will recognise, and the order matters, because you cannot optimize or renegotiate what you have not first measured and decommissioned. The table sets out the four moves and what each one delivers.

The four moves compound. Decommissioning shrinks the picture, optimization sharpens it, the support evaluation turns that clarity into a credible alternative, and governance makes the gains permanent. None of them depends on a contract date, which is exactly why they work for an agreement that has none.

The leverage review checklist

Use this as the cover sheet for your own review. Work it top to bottom and revisit it on a fixed cycle, because in a perpetual agreement the position erodes if it is left alone.

1. Estate measured across production, test, disaster recovery, cloud, and virtualization, with evidence.
2. Customer definition confirmed against current corporate structure, including any acquisitions and divestitures.
3. Decommissioning list built of deployments no longer in real use, with owners and dates.
4. Optimization plan drawn to right size and consolidate the remaining estate.
5. Support cost tested against the third party support alternative and any contract reduction options.
6. Repricing rules read so any partial reduction is modelled before it is attempted.
7. Governance assigned with a named owner, a policy, and a fixed review cycle.
8. Position documented for the board and for any audit that follows.

How do decommissioning and optimization rebuild the position?

Decommissioning and optimization are the foundation, because they replace assumption with fact. Many PULA holders carry deployments that no longer serve a live purpose, retired projects, duplicated environments, oversized non production estates, and forgotten instances spun up years ago. Under a term ULA this matters at certification. Under a PULA it matters because every one of those deployments inflates the perceived requirement and weakens any case to reduce support or to resist an upsell into adjacent products.

Optimization goes further than switching things off. It means right sizing the estate to the real workload, consolidating where consolidation reduces the footprint, and using product editions and options efficiently so the organisation is not running, and being asked to support, capability it does not use. A PULA holder who has done this work knows the true size of its requirement. That number is the anchor for every conversation that follows, and it is almost always smaller than the number Oracle would otherwise assume.

For a mid sized estate, this work commonly reveals a real requirement well below the deployed footprint. A buyer side review of an anonymized professional services group, for example, found a material share of its Oracle database estate running in dormant or duplicated environments that no live service depended on. The figure is indicative and the specifics depend on the estate, but the direction is consistent: the measured requirement is usually smaller than the bill assumes, and that gap is leverage.

Should a PULA holder consider third party support?

Third party support is a legitimate option to evaluate, and for a PULA holder it carries particular weight because support is the dominant lifetime cost and the agreement has no other natural reset. A credible third party support alternative gives the organisation something a perpetual agreement otherwise denies it, a real choice. Even where the organisation ultimately decides to remain on the vendor's support, the existence of a costed, credible alternative changes the tone of every renewal of that support and every adjacent negotiation.

The decision is not simple and should not be taken lightly. Moving support has real consequences for access to updates, security patches, and certain rights, and it interacts with the specific terms of a perpetual agreement in ways that need careful reading. The point of the leverage review is not to assume third party support is the answer. It is to understand the option well enough that it becomes a usable lever, and to make any actual move only on a clear eyed assessment of the trade offs. As with everything in a perpetual agreement, what is and is not possible depends on the contract language.

What governance does a perpetual agreement need?

The defining weakness of a PULA, from a buyer's point of view, is that nothing forces a periodic review. A term ULA has a renewal that compels attention. A PULA can run for a decade without anyone reopening the question of whether the organisation is getting value. Governance is the deliberate substitute for that missing contract event. It means assigning clear ownership of the agreement, setting a policy for how new deployments are tracked and approved, and committing to a fixed review cycle that runs the leverage review whether or not anything appears to be wrong.

Good governance also protects the customer definition. Every acquisition, divestiture, and significant reorganisation should be tested against the agreement's scope before Oracle products are deployed into new entities, not afterward. A simple rule, that no covered product is deployed into an entity until its position under the agreement has been confirmed, prevents the slow accumulation of out of scope exposure that is the most common way a PULA holder is caught out at audit. Governance is unglamorous, but for a perpetual agreement it is the single highest return discipline available.

What questions should the board be asking about a PULA?

Because a perpetual agreement never prompts a review, the board has to supply the prompt itself. A short, recurring set of questions keeps a PULA under the same scrutiny the business applies to any other major recurring commitment. The value is not in any single answer but in asking at all, on a fixed cadence, so the position is examined before it has quietly drifted.

The most useful questions are plain. What is the true requirement, measured rather than assumed, and how does it compare with what we are paying to support? Where has our corporate structure changed since the agreement was signed, and is every deployment still inside the customer definition? What would a credible support alternative cost, and have we actually priced it? Who owns this agreement, and when did we last run a structured review? A board that asks these five questions each year will catch the drift that costs perpetual agreement holders the most, long before it becomes an audit finding or an avoidable renewal of an oversized support base.

One indicative pattern is worth naming. Across buyer side reviews of perpetual agreements in sectors from financial services to manufacturing, the single most common finding is that the supported requirement is materially smaller than the deployed footprint, because retired and duplicated environments were never cleaned up. The exact gap is specific to each estate and the figure is indicative, but the direction is consistent enough that it should be the board's first question, not its last.

The next step

A PULA is not a trap you can exit, but it is an agreement you can manage to your advantage. The leverage review converts a permanent commitment from a passive cost into a position you actively control. If you would like the measurement, the decommissioning case, and the support evaluation run with you on your own agreement, that is the work we do. For the wider context, read the open PULA guide, the deeper analysis of the economics of a perpetual ULA, and the close reading of the PULA customer definition risk.