Oracle ULA-to-Cloud Conversion Loss Report 2026

What does converting an Oracle ULA to cloud actually cost?

Every ULA ends with one decision, and Oracle has spent the last three years trying to change what that decision is. A ULA (Unlimited License Agreement) is a fixed-term Oracle contract granting unlimited deployment of a named set of products in exchange for a single upfront fee; at the end of the term the customer either certifies — counts every deployed instance and converts those quantities into perpetual licences owned outright at no further licence cost — or renews for another term. For two decades those were the only two doors. Oracle has now added a third and is steering buyers toward it: ULA-to-cloud conversion, where the customer gives up perpetual certification in exchange for a cloud subscription, typically OCI Universal Credits, license-included PaaS, or Fusion SaaS. The pitch is modernisation. The mechanism is a transfer of an owned asset back into a rental Oracle controls.

The reason this matters is that certification is the single most valuable event in the entire ULA lifecycle. A customer who has deployed aggressively during the term walks away from certification owning perpetual licences worth multiples of the original fee, paying only support thereafter. Conversion erases that. When we rebuild the full position of a converted ULA and set it against what the same estate would have certified — the discipline documented in our companion Oracle ULA certification shortfall report — the gap is not marginal. The customer forfeits a median 43% of the certifiable value before a single subscription invoice is issued, and then pays more every year for the privilege of renting it.

The table below carries a representative $24M-net certifiable Oracle Database ULA across five years under both paths. Certification costs nothing in incremental licence — the ULA fee already paid for unlimited deployment — and leaves the customer paying support on a $24M perpetual asset they continue to own. Conversion replaces that with a cloud subscription Oracle prices to preserve its own revenue, loaded with cloud uplift and a year-three reset, and the perpetual asset disappears from the balance sheet entirely. The cumulative cash figure is $16.6M higher over five years, and that understates the loss, because the convert column ends with nothing owned while the certify column ends still holding the asset.

Read the path year by year and the structure is unmistakable. Conversion never has a good year — it is more expensive from year one and the gap widens as the subscription uplift compounds and the year-three reset lands. There is no break-even point at which the rented model overtakes the owned one, because the owned model has no recurring licence cost to overtake. The only number that ever favours conversion is the one Oracle leads with: a headline "cloud credit" or "investment" presented at signing that obscures the recurring, repriced, asset-stripped reality underneath. The rest of this study takes that reality apart — the conversion ratio, the underdelivery rate, the five-year TCO, and the product-by-product variation — and shows exactly where the 43 cents of every certifiable dollar goes.

Executive summary

Oracle's commercial incentive at a ULA exit is the opposite of the customer's. The customer wants to certify the maximum deployable entitlement and own it; Oracle wants to convert that entitlement into a recurring subscription it can reprice. For most of the ULA's history Oracle could not realistically prevent certification, so it competed on renewal terms. The rise of OCI and Fusion gave it a third option, and it has been pushing it hard: in our engagement base, Oracle now leads with a cloud-conversion proposal in 64% of ULA exits where it controls the certification clock, frequently before the customer has even completed a deployment maximisation exercise.

The economics of accepting that proposal are poor and consistent. Conversion forfeits a median 43% of certifiable perpetual value the moment it is signed, because Oracle credits only a median $0.57 of subscription entitlement per $1.00 of certifiable perpetual licence. The loss then compounds: the subscription recurs where the perpetual licence would have been owned, it carries cloud uplift and a year-three reset, and it strips the perpetual asset that gave the customer leverage at the next negotiation. Across five years the conversion path costs a median 58% more than certifying and then optimising support — and ends with nothing owned. Two-thirds of conversions return less value than a maximised certification would have, and the worst case, an E-Business Suite or PeopleSoft move to Fusion SaaS, runs 88% more expensive.

The defensible position is narrow but real. Conversion makes sense only as an OCI BYOL lift-and-shift — keeping the perpetual licence and applying it to cloud compute — undertaken after the customer has certified every deployable instance to capture the full entitlement. In that configuration the asset is preserved and OCI is simply infrastructure. Every other configuration, and especially any conversion that replaces an owned perpetual licence with a subscription, transfers value from the customer to Oracle. The buyer-side play is to certify first, maximise deployment, refuse to convert the asset itself, and treat any cloud move as a separate, later, fully-modelled infrastructure decision. The sections that follow quantify each step of that argument.

One pattern deserves emphasis up front because it shapes every number that follows: the conversion decision is almost never a like-for-like swap, even though Oracle presents it as one. A perpetual licence and a cloud subscription are different financial instruments — one is a capital asset with a residual value and a fixed support cost, the other is an operating liability that recurs and reprices. Treating them as interchangeable, which the conversion proposal implicitly does, is the error that costs ULA holders the most. The benchmark figures below are best read as the price of that error, quantified across product families, conversion targets, and deal sizes, so a buyer can see exactly where on the curve their own situation sits before Oracle's clock forces the decision.

Methodology & data set

This benchmark is built from Oracle Licensing Experts advisory engagement experience across more than 600 enterprise Oracle licensing reviews, with the ULA-specific figures drawn from the subset of those engagements involving an active or recently completed Unlimited License Agreement and a cloud-conversion proposal. The observation window covers ULA exits and conversion proposals reviewed in advisory work over the 36 months to Q2 2026. Where a customer received both a certification path and a conversion proposal, the two were modelled side by side on identical deployment data so the delta reflects the commercial structure, not differences in scope.

Figures are segmented four ways: by Oracle product family (Database and options, middleware and WebLogic, applications such as E-Business Suite/PeopleSoft/Siebel); by conversion target (OCI IaaS under BYOL, Autonomous Database and license-included PaaS, Fusion SaaS); by ULA size band (under $5M, $5M–$15M, over $15M of original fee); and by region (North America, EMEA, APAC). Conversion ratios are expressed as the dollar of cloud-subscription entitlement Oracle credits per dollar of certifiable perpetual licence value, valued at consistent net (post-discount) licence pricing. Five-year TCO figures hold support uplift, cloud uplift, and the typical year-three subscription reset constant across paths so the comparison is like-for-like.

Two methodological choices are worth stating plainly because they shape the results. First, the certify path is always modelled as a maximised certification — the full deployable entitlement under the unlimited term — rather than the current snapshot, because the maximised figure is what the customer is contractually entitled to and what any honest comparison must use; modelling against the snapshot would flatter conversion and understate the loss. Second, the retained perpetual asset is carried at conservative net licence value with no appreciation assumed, even though in practice an owned Oracle entitlement frequently rises in replacement value as list prices climb. Both choices are deliberately unfavourable to the certify path, so the reported gaps should be read as a floor on the conversion loss, not a ceiling. Where the engagement base showed wide dispersion — most notably in the conversion ratio, which is the single most negotiated number — the published figure is the median, with the inter-quartile spread captured in the segment tables rather than the headline.

How much certifiable value does ULA-to-cloud conversion forfeit?

The forfeit is best understood as a value waterfall that starts at the entitlement the customer is contractually allowed to certify and ends at what conversion actually delivers. The first leak is the conversion ratio: Oracle does not credit a dollar of subscription for a dollar of perpetual licence, it credits a median $0.57, so 43% of nominal value evaporates at the point of signing. The second leak is structural and usually invisible. Customers who certify properly run a deployment maximisation exercise first — deploying additional instances they are entitled to under the unlimited term, so the certified count reflects the maximum allowable, not the current snapshot. Conversion almost always freezes the current snapshot, so the customer forfeits the median 31% uplift that maximisation would have captured. These two leaks compound.

The table puts dollar figures against the waterfall on the representative $24M certifiable ULA. Note that the maximisation line works in the customer's favour on the certify path and against them on the convert path: a properly run certification would have lifted the certifiable base above $24M, while conversion locks the lower snapshot in. The realised conversion value — what the subscription is actually worth to the customer over its life once the recurring, repricing nature is netted against an owned asset — lands at a median 57% of the certifiable figure, which is the 43% forfeit stated as retention.

*The maximisation upside is shown as forfeited opportunity rather than a deduction from the $24M base, which is already stated at the un-maximised snapshot; a fully maximised certify path would raise the certifiable base a median 31% above this figure, widening the gap further.

The practical consequence is that the conversion decision should never be evaluated against the customer's current deployment snapshot, because that snapshot is the worst possible starting point. The correct comparison is against a maximised certification — what the customer could own if they deployed to the full extent of their unlimited rights before the term ends. Oracle's proposals are always framed against the snapshot, never the maximum, because the snapshot makes conversion look least bad. A buyer who reframes the comparison against the maximised certifiable entitlement sees the true 43% forfeit immediately, and the conversion pitch rarely survives the reframing.

What conversion ratio does Oracle apply to perpetual licences?

The conversion ratio is the cleanest single measure of the loss, because it captures what Oracle is prepared to give back for what the customer gives up, before any of the downstream recurring-cost effects. The pattern across the engagement base is consistent: the ratio is highest where the customer keeps the most. A BYOL (Bring Your Own License) move — applying existing or certified perpetual licences to OCI compute rather than buying license-included cloud — preserves the perpetual asset almost entirely, so the "conversion" is barely a conversion at all and the effective ratio is high. The ratio collapses where the perpetual licence is replaced outright by a subscription, as in a Fusion SaaS conversion, because the customer surrenders an owned asset for a rented one and Oracle prices the credit to its own advantage.

The table adds the product-family dimension, and the interaction is informative. Database carries the strongest ratios across every target because Database perpetual licences are the most fungible — they can run anywhere, including non-Oracle clouds, so the customer's BATNA is credible and Oracle has to credit more. Applications carry the weakest ratios because Fusion is the only sanctioned cloud destination Oracle offers and the perpetual application licence has no comparable resale or redeployment value, so the customer's leverage is thin. Middleware sits between the two, with WebLogic and SOA Suite converting to Oracle Integration Cloud at ratios that reflect moderate lock-in.

The rule that falls out of the ratio table is to anchor every conversion conversation in the perpetual asset's portability. Where the perpetual licence can run on infrastructure Oracle does not control — Database on a third-party cloud, middleware on commodity compute — the customer's exit is credible and the ratio Oracle must offer is higher; where it cannot, the ratio collapses and the customer should refuse to convert at all. The worst conversions in the data set share one trait: they replace a portable perpetual licence with a non-portable subscription, converting a strong BATNA into a weak one in a single signature.

What share of ULA-to-cloud conversions underdeliver versus certification?

"Underdeliver" here has a precise meaning: a conversion underdelivers when the five-year value it returns to the customer — the realised entitlement plus any genuine cloud benefit, net of the recurring subscription cost — is lower than the value a maximised perpetual certification of the same estate would have produced over the same five years. It is the honest test, because it compares the conversion not to doing nothing but to the customer's best available alternative, which is always certification. By that test, conversion loses about two times in three across the whole base, and the losing rate is almost entirely predictable from the conversion target.

The table breaks the underdelivery rate down by both target and ULA size, and a second pattern appears: larger ULAs underdeliver more often, not less. This is counter-intuitive to buyers who assume scale brings better terms, but it follows directly from the conversion ratio. A larger ULA carries more certifiable deployment, so it has more to lose to the ratio haircut and more maximisation upside to forfeit; Oracle's deeper headline credit on a big deal rarely closes that gap. The result is that the biggest ULAs — the ones where the conversion decision matters most in dollar terms — are also the ones most likely to be a mistake.

The conversions that do pay off cluster tightly in one corner of the table: small-to-mid OCI BYOL moves where the customer keeps the perpetual licence, certifies first, and uses OCI purely as compute. That is the configuration to aim for if a cloud move is genuinely required. Everything else is, on the evidence, a coin flip at best and a near-certain loss at worst — and the conversions Oracle pushes most enthusiastically, the SaaS replacements, are exactly the ones that underdeliver most reliably. The enthusiasm and the underdelivery are not unrelated.

How does the five-year TCO compare: convert versus certify?

Five-year TCO is the number that should drive the decision, because it captures both the recurring premium and the timing of Oracle's repricing. On the certify path, the only recurring cost is support — 22% of net licence value, rising at the capped or default uplift documented in our Oracle support renewal uplift tracker — and that support can be reduced further through de-bundling, repricing, or a move to third-party support. On the convert path, the recurring cost is the full cloud subscription, which bundles licence and support into one repriceable line, carries cloud uplift typically steeper than support uplift, and resets at the first post-incentive renewal. The two cost curves diverge from day one and never reconverge.

The table carries the cumulative figures on the representative $24M ULA and adds the asset position, which is the line buyers most often omit from their own models. At the end of five years the certify path has spent $28.6M on support and still owns a $24M perpetual entitlement that continues to have value into years six and beyond; the convert path has spent $45.2M and owns nothing, facing another full subscription cycle. Counting the retained asset, the true economic gap between the paths is far larger than the $16.6M cash delta — on a conservative asset valuation it approaches $40M over the horizon.

The takeaway for any board paper is that the cash comparison alone understates the case against conversion, and Oracle's proposals are always built on the cash comparison alone. A complete model has to carry the retained asset and the year-six-onward cost, because that is where the owned position pulls decisively ahead. A buyer who models only the five-year cash flows will still conclude conversion is more expensive; a buyer who models the asset as well will conclude it is not close.

There is also a discount-rate trap buried in the conversion proposal that procurement teams should be alert to. Oracle's year-one framing front-loads an apparent benefit — a credit, a waived fee, a transition incentive — and pushes the cost into later years, which makes the deal look better under any naïve net-present-value calculation that the buyer has not built carefully. The correct response is to discount both paths consistently and to recognise that the certify path's largest single value, the retained perpetual asset, sits at year zero and is not discounted at all. Once the asset is valued at the present and the subscription's repricing is modelled at its contractual reset rather than its introductory rate, the apparent year-one advantage of conversion disappears entirely. We have never seen a conversion survive a properly discounted, asset-inclusive model in the engagement base — which is precisely why those models are the ones Oracle's proposals omit.

How does the conversion loss vary by product family and deal size?

The segment view confirms the through-line of the whole report: loss tracks lock-in. Where the perpetual licence is portable and the cloud move keeps it under BYOL, the penalty is contained and the conversion can occasionally be defensible. Where the conversion replaces a portable licence with a proprietary subscription, the penalty balloons. The four-row hierarchy below is the one to put in front of any executive sponsor weighing an Oracle cloud-conversion proposal, because it ranks the moves from least to most destructive in a single glance and the ranking is stable across the engagement base.

The table adds deal size and region, and both modulate the headline without changing its direction. Larger deals carry slightly worse penalties because they forfeit more maximisation upside; EMEA penalties run marginally higher than North America, reflecting thinner local competitive alternatives and Oracle's stronger negotiating posture in several European territories. APAC sits close to the global median. None of these second-order effects rescues a SaaS conversion — the EBS-to-Fusion row is the most expensive cell in every region and every size band.

The operating rule is simple and it survives every segment cut: convert for portability or do not convert at all. A Database workload that moves to OCI under BYOL after a maximised certification keeps the asset, contains the penalty, and can be a reasonable infrastructure decision on its merits. A perpetual application licence converted to Fusion SaaS surrenders the asset permanently for the worst penalty in the data set — and it is, not coincidentally, the conversion Oracle's sales motion is most determined to close.

Why does Oracle push cloud conversion at a ULA exit?

Certification is, from Oracle's perspective, the worst outcome of a ULA: the customer ends the term owning perpetual licences, paying only support, holding an asset that strengthens their hand at every future negotiation. Conversion reverses all three. It turns an owned asset into a rented one, replaces a fixed support stream with a subscription Oracle can reprice, and strips the leverage the perpetual asset conferred. None of that is hidden in the proposal, but none of it is stated either; the proposal is framed as cloud modernisation, investment protection, or a "transition" to a supported, current platform. The commercial reality is an annuity replacing a settlement.

The timing of the push is the tell. Oracle's strongest conversion proposals land before the customer has run a deployment maximisation exercise, often months ahead of the certification deadline, when the customer is least prepared and the certifiable entitlement looks smallest. This is deliberate. A customer who has maximised deployment sees a large certifiable asset and is hard to talk out of owning it; a customer who has not sees a modest snapshot and is far more receptive to a conversion that appears to "rescue" value. The 64% proposal rate and the 81% should-have-certified rate are two views of the same dynamic: Oracle proposes conversion broadly and succeeds disproportionately where the customer has not done the certification homework.

The gap row is the whole story. Oracle proposes conversion roughly five times more often than it is the right answer for the buyer, and proposes maximised certification roughly four times less often than it should. The corrective is not to distrust every proposal reflexively but to insist on the comparison Oracle omits: a fully maximised certification, modelled on the customer's own deployment data, set against the conversion on a five-year-plus horizon that carries the retained asset. Run that comparison and the 71% / 12% optimal split asserts itself almost every time.

What Oracle doesn't tell you about ULA cloud conversion

The Oracle ULA-to-cloud playbook is consistent enough to name, and naming the moves removes most of their force. The first move is the early proposal, dropped while the customer is unprepared and the snapshot is at its smallest. The second is the framing — cloud conversion presented as the modern, supported, forward path, with certification cast as legacy, on-premises, and somehow risky, even though certification simply means owning what you have already paid for. The third is the conversion ratio itself, denominated against the un-maximised snapshot so the haircut is invisible. The fourth, the one that pays for the others, is the year-three reset, where the subscription Oracle persuaded the customer to accept reprices against a workload that has moved and a perpetual asset that no longer exists to provide leverage.

What Oracle never volunteers is that certification and a cloud move are not mutually exclusive — they are sequential. A customer can certify the maximum deployable entitlement, own it perpetually, and then, separately and later, decide on its own timetable whether to run some of that owned licence on OCI under BYOL. That sequence keeps the asset and gets whatever genuine cloud benefit exists. Oracle bundles the two into a single conversion precisely to prevent it, because the bundle is where the asset is surrendered. The customer is told it is one decision; it is two, and the order matters enormously.

The last unspoken fact is the most important: the perpetual asset is leverage at every future negotiation, and conversion is the only ULA exit that destroys it. A certified perpetual entitlement is a permanent BATNA — the customer can always fall back on running what they own, on infrastructure they choose, supported by whoever they choose. Conversion converts that permanent BATNA into a recurring dependency on Oracle, and it does so at the single moment in the relationship when the customer's leverage is highest. The cloud credit is not a gift and the conversion is not a modernisation; it is the sale of the customer's strongest negotiating asset, at a discount, back to the counterparty who benefits most from owning it.

Recommendations: how to handle the cloud-conversion push at a ULA exit

ULA-to-cloud conversion fails buyers not because OCI is unusable but because the conversion is evaluated against the customer's smallest, worst-prepared position instead of their best alternative. The sequence below is the one we run to disarm the structure and capture the value the customer is entitled to.

1. Run a deployment maximisation exercise before you do anything else. Under the unlimited term you are entitled to deploy aggressively right up to the certification date. Build the certifiable count to the maximum allowable — the median uplift is 31% over a passive snapshot — so any conversion is measured against the full asset, not a fraction of it. This single step changes the entire negotiation.
2. Complete a maximised certification as your baseline, not a fallback. Certify the entitlement and establish what you would own perpetually. Treat that owned position as the default outcome and make Oracle's conversion proposal beat it, rather than treating conversion as the default and certification as the alternative.
3. Model conversion on a five-year-plus horizon that carries the retained asset. Oracle's proposal will be a year-one cash comparison. Reject it. Build the full model: subscription cost with cloud uplift and the year-three reset, against support-only cost on a retained perpetual asset, and include the asset's value into year six and beyond. The cash gap alone understates the case.
4. Refuse to convert the perpetual licence itself. Separate the licence from the infrastructure. There is no version of trading an owned perpetual licence for a SaaS or license-included subscription that benefits the buyer in our data set. If Oracle insists the only path is to surrender the licence, that is the signal to certify and walk.
5. If you move to cloud, move under BYOL, after certifying. Where a genuine cloud case exists, run certified perpetual licences on OCI under BYOL so the asset is preserved and OCI is purely compute. This is the only conversion configuration that consistently holds its value — and it is a later, separate decision, not part of the exit.
6. Control the certification timeline so the proposal cannot pre-empt it. Oracle's conversion push depends on arriving before you have valued the asset. Start the certification process early, on your own clock, with your own deployment data, so any conversion proposal lands against a fully valued position rather than an empty one.
7. Get independent, buyer-side modelling before you sign anything. The conversion ratio, the maximisation upside, and the five-year asset position are all where the value is won or lost, and all three are where Oracle's proposal is silent. Have the comparison built by someone whose only interest is your position — not Oracle's, and not a reseller's.