Standard, capped, hybrid, or perpetual: Oracle will often offer to move you from one structure to another. Each move changes what you can certify and what you can walk away with. Choose it deliberately, not as a convenience.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Converting between ULA structures is a commercial negotiation, not an automatic right, so every move is on the table to be priced and argued. The decisive question in any conversion is what happens to your certification exit. Moving toward a PULA removes it, moving toward a capped structure bounds it, and moving toward a standard ULA preserves it. Model the deployment and the exit before you accept any conversion, because the convenience offered is rarely the value at stake.
Oracle unlimited agreements come in a small family of structures, and conversions usually move you between them. A standard ULA grants unlimited deployment of named products for a fixed term and ends in a certification, where you convert your deployed count into perpetual licenses and exit. A capped ULA does the same but limits the unlimited right to a ceiling, so the most you can certify is bounded. A hybrid ULA folds cloud rights into the agreement, changing how and whether cloud deployments count. A PULA is perpetual, with unlimited deployment and no certification event at all.
The structures differ on many details, but one feature decides the value of any conversion: the exit. Certification is where unlimited deployment becomes owned, finite, vendor independent value. A standard ULA has a full exit, a capped ULA has a bounded one, a hybrid changes what counts toward it, and a PULA has none. Read every conversion through that single lens and the trade becomes clear.
A conversion is a deal Oracle proposes and you accept or decline, not a clause that fires automatically. It typically arrives as an offer: extend the term, lift a cap, add cloud rights, or move to a PULA and stop worrying about certification. Because it is a negotiation, the terms are movable, and because it changes your exit, the stakes are higher than the convenience suggests. The mistake is to treat a conversion as an administrative tidy up. It is a structural decision about how much of your unlimited deployment you will be able to keep.
This is the most consequential conversion, and the one Oracle most often promotes. It is sold as the end of certification deadlines and the work they require. The reality is that you surrender the single most valuable moment in the agreement: the point at which you crystallise your count and own it. Accept this only if your deployment will keep growing hard for a long time and leaving Oracle is genuinely not part of your strategy. For most organisations the missing exit costs more than the convenience saves.
If your deployment is approaching a cap, you can negotiate to raise it or move to an uncapped structure, which increases the count you can ultimately certify. The cap is the ceiling on your eventual entitlement, so the conversion is worth real money where your true deployment exceeds it. Read the cap definition precisely first, because caps are sometimes written in quantities, sometimes in entities, and sometimes in environments, and the right argument depends on which.
Folding cloud rights into a ULA changes whether deployments in cloud environments count toward your certification baseline. Whether this helps depends entirely on your contract language and where your workloads actually run. A hybrid conversion can be valuable if it brings genuine cloud deployments into the count, and a distraction if it does not. This is a contract specific decision, and the only way to judge it is to read the existing cloud terms against your real cloud footprint.
Never accept a conversion for the reason it is offered. The convenience on the label, no more deadlines, more headroom, cloud included, is rarely the value at stake. The value is in the exit, the cap, and what you can certify. Model your deployment and your certification count first, then judge the conversion against the number you would otherwise own.
Consider an anonymized technology firm offered a conversion from its standard ULA to a PULA, presented as removing the upcoming certification work. We measured the estate first. Its deployment was set to plateau within the term, and a certification would have produced a defensible count covering nearly all of its real need, owned outright. The PULA would have replaced that owned entitlement with an indefinite support obligation and no way to step down later. Set against the count it could certify, the conversion gave up far more than the deadline it removed. The firm declined the PULA, certified on schedule, and kept the freedom to manage its footprint afterward. The figures are indicative, and the right call always depends on the specific deployment and contract, but the discipline holds: value the exit before you trade it away.
If Oracle has offered a conversion, or you are weighing one yourself, model the exit before you respond. Understand why a perpetual structure can cost you in when a PULA is a trap, see how to keep any structure under control in governing deployment under a PULA, and ground the decision in our PULA and capped ULA guide.
Book a ULA assessment and we will measure what you could certify today and model each conversion against it, so you trade structures with the number in front of you.