The OCI BYOL conversion ratio is the single number that decides whether bringing your existing Oracle licenses to the cloud saves money or quietly creates a back-licence claim. Each on-premises Oracle Processor license converts into a fixed amount of OCI Platform capacity — but the ratio changes by service tier, and Oracle's account team rarely walks you through the version that protects you. Former Oracle insiders give you the full conversion table and the traps to defend against.
Short answer: The OCI BYOL conversion ratio sets how many OCI service units one on-premises Oracle Processor license covers. For Oracle Database Enterprise Edition the standard mapping is 1 Processor license = 4 OCPUs of base Enterprise Edition, 2 OCPUs of High Performance, or 1 OCPU of Extreme Performance — because each higher tier bundles more licensed options per core.
BYOL (Bring Your Own License) on OCI lets you apply Oracle licenses you already own to Oracle Platform (PaaS) services, so you pay only the lower infrastructure rate instead of the higher License-Included rate. The conversion ratio is the rule that translates an on-premises entitlement into cloud capacity: how many OCPUs (or, increasingly, ECPUs) of a given service each Processor license is allowed to run. Get the ratio right and BYOL is one of the few genuinely buyer-favourable mechanisms in Oracle's cloud catalogue. Get it wrong and you either leave entitlement unused or, worse, under-cover a deployment and expose yourself to a back-licence claim at the next review.
The ratio is not a single number. It varies by product (Database Enterprise Edition versus Standard Edition 2), by service tier (base, High Performance, Extreme Performance), and by metric (OCPU versus ECPU). Oracle publishes these mappings in its service descriptions, but they are scattered and easy to misapply — and Oracle's account team has no incentive to point you toward the lowest-cost tier that still meets your need. Reading the conversion correctly is buyer-side work.
Oracle offers Database PaaS in three Enterprise Edition tiers, and each consumes your license entitlement at a different rate. The base Enterprise Edition service includes the EE software only; High Performance adds a substantial set of options and packs; Extreme Performance includes essentially the full option stack plus RAC. The more software bundled into each OCPU, the more of your license it consumes — which is why the conversion runs from generous (1:4) at the base tier to strict (1:1) at the top.
| OCI PaaS Tier | What it bundles | BYOL conversion |
|---|---|---|
| Database Enterprise Edition (base) | EE software only | 1 EE Processor license = up to 4 OCPUs |
| Database EE High Performance | EE + most options & management packs | 1 EE Processor license = up to 2 OCPUs |
| Database EE Extreme Performance | EE + all options + RAC + In-Memory | 1 EE Processor license = up to 1 OCPU |
| Standard Edition 2 (Standard service) | SE2 software (socket-licensed) | 1 SE2 socket license = up to 4 OCPUs |
Read the table as an entitlement budget, not a sizing target. An enterprise with 10 Database EE Processor licenses can run up to 40 OCPUs of base Enterprise Edition, 20 OCPUs of High Performance, or 10 OCPUs of Extreme Performance — or any blend that stays within the total entitlement. The right tier is the lowest one that includes the options your workload actually uses, and confirming which options are genuinely in use is exactly the kind of forensic review that protects against over-provisioning.
The shrinking ratio is not arbitrary — it reflects how much licensed software rides on each core. On-premises, options such as Partitioning, Advanced Security, the Diagnostics and Tuning Packs, In-Memory, Active Data Guard, and RAC are each licensed separately on top of Database Enterprise Edition. OCI's High Performance and Extreme Performance tiers fold those options into the service. So when you run one Extreme Performance OCPU, you are effectively consuming an EE license plus a stack of option licenses, all at once — which is why a single Processor license only stretches to 1 OCPU at that tier.
This is where buyers most often overpay. Oracle's account team frequently proposes Extreme Performance as the default "to be safe," even when the workload uses none of the bundled options. That choice quietly quarters your effective capacity per license and pushes you toward buying more. Push back: insist on a tier mapped to the options the workload actually requires, and treat any proposal to provision the top tier as a claim you can challenge with usage evidence. The on-premises option-usage picture is set out in our Oracle Database licensing guide.
Standard Edition 2 follows a different rule because it is not licensed per Processor on-premises — it is licensed per occupied socket, capped at two sockets per database. On OCI, the BYOL conversion for SE2 is 4 OCPUs per socket license on the Standard Edition database service. An organisation that owns SE2 for a two-socket server can therefore run up to 8 OCPUs of the Standard service under BYOL.
The trap with SE2 is feature creep. SE2 does not permit the Enterprise Edition options, and OCI will happily let you provision an Enterprise tier with an SE2 entitlement applied incorrectly. If a deployment built on SE2 entitlement ends up running EE-only features — even accidentally enabled ones such as the Diagnostics Pack — you have an instant compliance gap that an Oracle review will price aggressively. Keep SE2 BYOL workloads on the Standard service, and verify no Enterprise features are active. This is the same forensic discipline that protects on-premises SE2 estates.
Our Oracle Cloud Advisory and License Optimization teams model the right tier, the right ratio, and the full BYOL-versus-License-Included math before you commit. See our energy-sector case study: $3.5M saved on OCI migration.
Oracle is moving OCI database services from the OCPU metric to the ECPU (Elastic CPU) metric. When a service makes that move, the BYOL entitlement does not disappear — Oracle simply re-expresses it in ECPU terms. The same tier logic holds (base Enterprise Edition stretches further per license than Extreme Performance), but the numbers on the page are now ECPU counts, not OCPU counts, and the per-instance minimums change with the metric.
The danger is continuity. If your compliance position was documented as "X licenses cover Y OCPUs" and the service quietly re-baselines to ECPUs, the entitlement math must be redone or you can drift into under-coverage without changing a single deployment. We treat every metric transition as a trigger to re-validate BYOL coverage and keep the evidence — the mechanics of the metric switch are covered in our ECPU vs OCPU pricing guide, and how the units draw down against a commitment is explained in the OCI Universal Credits article. Never assume a metric change is cost- or compliance-neutral; benchmark it.
Yes — and this is the condition that links BYOL to your wider Oracle cost strategy. To remain eligible for BYOL on OCI, the on-premises licenses you bring must stay on active Oracle Software Update License and Support. Let support lapse, and those licenses are no longer BYOL-eligible; the cloud deployment can fall out of compliance immediately. That makes any support-reduction or third-party-support decision inseparable from the BYOL plan.
The practical implication: do not model BYOL savings in isolation from the 22% annual support cost that keeps the licenses eligible. An enterprise weighing a move to third-party support to cut that 22% must account for the licenses it intends to keep on Oracle support specifically to fund BYOL. Our support reduction practice models these decisions together, because optimising one in isolation can quietly break the other.
Trap 1 — Defaulting to Extreme Performance. Provisioning the top tier "to be safe" quarters your effective capacity per license. Map the tier to the options the workload actually uses, and challenge any proposal to over-provision.
Trap 2 — Mixing BYOL and License-Included in one estate without tracking. OCI lets you toggle BYOL per instance. Untracked toggling produces instances Oracle counts as License-Included that you believed were BYOL — inflating cost — or BYOL instances with no underlying entitlement — creating a compliance gap.
Trap 3 — Forgetting the support condition. Dropping support on licenses you are using for BYOL silently revokes eligibility. Reconcile your BYOL instances against your supported license estate every renewal.
Trap 4 — Ignoring the metric change. A service moving from OCPU to ECPU re-baselines your entitlement. Re-validate coverage at every transition rather than assuming the old OCPU math still holds.
Trap 5 — Accepting Oracle's count without an independent benchmark. Oracle's BYOL position is built to protect Oracle's revenue. An evidence-based, buyer-side reconciliation is the only way to confirm you are neither over-paying nor under-covered. Our Oracle cloud licensing guide and contract negotiation practice exist to give you exactly that position before you respond to Oracle.
It is the number of OCI service units each on-premises Oracle Processor license entitles you to run. For Oracle Database Enterprise Edition the standard mapping is 1 Processor license = 4 OCPUs of base Enterprise Edition, 2 OCPUs of High Performance, or 1 OCPU of Extreme Performance, because higher tiers bundle more database options per core.
One Database Enterprise Edition Processor license covers up to 4 OCPUs on base Enterprise Edition, 2 OCPUs on High Performance, and 1 OCPU on Extreme Performance. Standard Edition 2 is licensed per socket and converts to 4 OCPUs per occupied socket on the Standard Edition service.
Extreme Performance bundles the full option stack — Partitioning, Advanced Security, the Diagnostics and Tuning Packs, In-Memory, Active Data Guard, RAC and more. Because each OCPU includes far more licensed software than base Enterprise Edition, you consume more entitlement per OCPU, so the conversion is 1:1 rather than 1:4.
Yes. When a service moves to ECPU, Oracle re-expresses the same BYOL entitlements in ECPU terms rather than OCPU terms, and the per-instance minimums change. Re-validate coverage after any metric change to avoid an unintended compliance gap, and keep documented evidence of the conversion you applied.
Yes. The licenses you bring must remain on active Oracle Software Update License and Support to stay BYOL-eligible. If support lapses, the licenses are no longer eligible and the deployment can fall out of compliance — so support-reduction decisions must be modelled alongside BYOL, not separately.
BYOL is usually cheaper when you already own enough on-premises licenses and keep them on support, because you pay only the lower infrastructure rate. License-Included is simpler and avoids compliance risk when you lack licenses. The break-even depends on your existing estate, support costs, and planned OCI consumption — model both before committing.
OCI BYOL ratio changes, ECPU/OCPU updates, and Universal Credit negotiation tactics for enterprise Oracle cloud stakeholders.
Former Oracle cloud executives reconcile your BYOL entitlement against your OCI deployment, pick the right PaaS tier, and benchmark the conversion Oracle proposes — giving you the analysis Oracle's account team doesn't volunteer. Not affiliated with Oracle Corporation.