A capped ULA gives you unlimited deployment only up to a ceiling. Below the cap you certify for free. Above it, the unlimited right stops and a true up applies. Knowing exactly where the cap sits, and managing the count against it before certification, is what keeps a capped agreement from turning into an unplanned bill.
A capped ULA grants unlimited deployment of named Oracle products only up to a defined quantity ceiling, called the cap. Below the cap you deploy freely and certify those quantities into perpetual licenses at no extra fee, exactly as in a standard ULA. Above the cap the unlimited right stops, so deployment beyond it is not automatically converted and usually requires a true up purchase to license. The cap converts an unlimited right into a bounded one, which changes how you should plan deployment across the term and how you should approach certification at the end.
In a standard ULA, more defensible deployment is free value. In a capped ULA, that is true right up to the cap and reverses past it. The whole game is knowing where the line sits and steering the count toward it, not over it by accident.
The cap is a quantity, but agreements express it in different units, and the unit matters. Some caps are stated in processor licenses, sometimes after core factor, sometimes before. Some are stated in Named User Plus. Some apply per product, so each Oracle product in the agreement carries its own ceiling, while others apply a single combined cap across a basket of products. A cap of a given size means something very different depending on whether it counts raw cores, core factor adjusted processors, or named users. The first task with any capped agreement is to read the cap clause precisely and translate it into the same unit you use to measure live deployment, so you are comparing like with like.
If your certified deployment exceeds the cap, the excess is not free. The contract requires you to true up, which means buying licenses for the quantity above the ceiling, frequently at price and discount terms fixed in the original agreement. Those pre agreed terms can be favourable or punitive, so they are worth reading before you ever approach the cap. A capped ULA therefore rewards deploying up to the cap, where conversion is free, and penalises deploying past it without a plan, where every unit costs. The discipline is to measure live deployment against the cap throughout the term, not to discover the overage in the final weeks when there is no time to adjust.
The table below shows the same product certified at three deployment levels against a cap. Figures are indicative and exist only to show the mechanics. The actual unit, core factor treatment, and true up terms are set by your specific agreement.
The middle row is the target. Certifying exactly at the cap captures the full value of the agreement with no true up. The top row leaves value unused, which in a capped deal is a missed opportunity rather than a saving. The bottom row is the avoidable cost: the overage exists, it has to be licensed, and the only question is whether you planned for it or were surprised by it.
No, and confusing the two leads to bad decisions. A capped ULA limits the unlimited right to a quantity ceiling but still certifies at the end of its term, converting deployment up to the cap into perpetual licenses. A PULA is perpetual with no certification exit at all. One bounds the quantity and keeps the exit. The other bounds the time to never and removes the exit. They behave like opposites at the end of the agreement: the capped ULA holder has a certification to plan and optimize, while the PULA holder has a support stream that simply continues. If you are unsure which you hold, that uncertainty is itself a reason to read the agreement carefully, because the strategy differs completely.
The approach mirrors a standard certification with one added discipline: the cap. You still build a complete, defensible deployment inventory across production, test, disaster recovery, and eligible cloud and virtual environments, and you still document the evidence behind every number. The difference is that you measure that inventory against the cap continuously, so you know well before the window whether you are heading under, at, or over the ceiling. If you are heading under, there may be legitimate deployment you have not counted that brings you closer to full value. If you are heading over, you have time to decide whether the overage is worth a planned true up or whether workloads can be arranged so the certified number lands at the cap. Both decisions need months, which is why a capped agreement should be measured early.
A logistics group held a capped ULA on a core database product. An early baseline showed live deployment running roughly fifteen percent above the cap, with several non production environments driving the overage. Because the gap was found with a year of term remaining, the group consolidated test estates and confirmed which environments genuinely needed to persist, bringing the certified count back to the cap and avoiding a true up it had not budgeted. Had the same overage been found at certification, the true up would have been the only option. Figures are indicative and depend on the specific contract language and cap definition.
If you hold a capped ULA, translate the cap into your measurement unit and baseline against it now, while there is still time to steer. Start with the PULA and capped agreements pillar guide, then read the economics of a perpetual ULA and the PULA customer definition risk.
A capped ULA grants unlimited deployment of named Oracle products only up to a defined quantity ceiling, called the cap. Below the cap you deploy freely and certify those quantities into perpetual licenses at no extra fee. Above the cap the unlimited right stops, so deployment beyond it is not automatically converted and usually requires a true up purchase to license. The cap turns an unlimited right into a bounded one.
If certified deployment exceeds the cap, the excess is not free. The contract requires you to true up, meaning buy licenses for the quantity above the ceiling, often at terms set in the original agreement. So a capped ULA rewards deploying up to the cap and penalises deploying past it without planning. Managing the count against the cap before certification is what keeps a true up from becoming an unbudgeted bill.
No. A capped ULA limits the unlimited right to a quantity ceiling but still certifies at the end of its term, converting deployment up to the cap into perpetual licenses. A PULA is perpetual with no certification exit at all. They sit at opposite ends: the capped ULA bounds the quantity, the PULA bounds the time to never. Read your agreement to see which structure you actually hold.
Book a confidential assessment and we will translate your cap into your measurement unit, baseline against it, and plan certification so you capture full value without an unplanned true up.