A perpetual ULA has no certification exit, so a mistake made at signing has no natural moment to correct. The most costly errors are overscoping the agreement, ignoring the support economics, and assuming an exit you do not have. Each one compounds for as long as you hold the deal.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
A PULA is a perpetual unlimited license agreement with no certification exit, so there is no natural moment to fix a poor decision. A term ULA forces a review at the term end, where a buyer can certify, renegotiate, or walk. A PULA has no such boundary; it simply continues. That permanence is the structure's selling point, but it is also why its mistakes are different in kind from a term ULA's. An error in a term deal is bounded by the clock. An error in a PULA runs until someone negotiates it away, and negotiation is harder when there is no deadline forcing the other side to engage. The mistakes below are the ones that compound the longest.
Treat a PULA decision as permanent, because it is. The three mistakes that cost the most are overscoping the products and entities, underestimating the indefinite support stream, and signing on the assumption that an exit exists. None of them corrects itself. Each is far cheaper to avoid at signing than to unwind later through a negotiated conversion.
Because a PULA feels generous, buyers often fold in more products and more entities than the business genuinely needs, reasoning that breadth is free. In a term ULA, an overscoped deal at least reaches a certification where the unused breadth can be left behind. In a PULA there is no such reckoning. You carry the support and the commitment for products you barely deploy, indefinitely. The discipline is to scope a PULA to what you will actually use at scale, and to resist the instinct that more coverage is always better when the coverage never ends.
Underestimating the support economics. Support fees continue against the agreement for as long as you hold it, with no certification event to reset the basis. In a term ULA you eventually certify and hold support flat against a fixed owned count. In a PULA the support obligation simply runs, year after year, against the whole agreement. Over a ten or fifteen year horizon that uncapped, indefinite stream is usually the single largest number in the arrangement, and it is the one a buyer focused on the deployment right at signing is most likely to have discounted. The deployment right is what gets sold; the support stream is what gets paid.
| Mistake | Why it lasts | The fix |
|---|---|---|
| Overscoping products and entities | No exit to leave unused breadth behind | Scope to genuine scaled use |
| Ignoring support economics | Support runs indefinitely with no reset | Model support across the full horizon |
| Assuming an exit exists | There is no built in certification | Negotiate exit terms before signing |
The most fundamental error is treating a PULA like a long ULA, on the belief that there will be a way out when the time comes. There is no built in certification exit. Leaving a PULA means negotiating a conversion of the perpetual right into a fixed owned count, and that is a negotiation rather than a right. A buyer who understood this at signing could have negotiated conversion terms into the original agreement, when leverage was at its highest. A buyer who assumed an exit discovers, often years later, that the off ramp has to be built from nothing. The lesson is to settle how you would leave before you sign, not after.
Consider an organisation, figures indicative only, that signed a broad PULA covering several products it expected to scale. Two of them never grew. A decade on it is still paying support against the full agreement, with no certification to leave the unused products behind, and no conversion terms negotiated at the start. The deployment right it bought was real; the cost it carried was the part it never modelled.
Sometimes. A negotiated conversion can crystallise the perpetual right into a fixed owned count and end the agreement, which addresses the support drift and the overscoping at once. It is not a contractual right, so whether it is achievable depends on the specific contract language and on the leverage available. The earlier a problem is identified, the more room there usually is to address it, because more options remain open. The routes are covered in negotiating out of a PULA. The honest summary is that prevention is far cheaper than cure: the mistakes here cost a fraction to avoid at signing compared with what it takes to unwind them later.
If you hold a PULA or are weighing one, the first step is to understand the instrument and the exit. Read what a PULA is and how it differs from a ULA for the structure, and negotiating out of a PULA for the routes to a conversion. Our PULA guide is the pillar that frames perpetual agreements end to end. When you want a read on your own agreement, the next step is a confidential assessment.
A PULA is a perpetual unlimited license agreement with no certification exit, so there is no natural moment to correct a poor decision. A term ULA forces a review at the term end; a PULA simply continues. Without that deadline, an overscoped agreement or an unfavourable support basis carries on indefinitely unless you negotiate a change.
Underestimating the support economics. Support fees continue against the agreement for as long as you hold it, with no certification event to reset the basis. Over a long horizon that uncapped, indefinite support stream is usually the largest cost, and a buyer who focused only on the deployment right at signing often misses it.
Sometimes, through a negotiated conversion that crystallises the perpetual right into a fixed owned count and ends the agreement. It is not a contractual right, so the outcome depends on the specific contract language and on leverage. The sooner a problem is identified, the more room there usually is to address it.