How Oracle BYOL to OCI Actually Works

When you BYOL Oracle Database to OCI, you apply your existing perpetual Oracle Database licences (Enterprise Edition, Standard Edition 2, or SE) to OCI VM or Bare Metal compute shapes. Oracle's BYOL model for OCI applies the same core factor table as on-premises, but only counts the OCPUs in the specific OCI shape you provision — not the physical host cores beneath it.

For a VM.Standard.E4.Flex shape with 8 OCPUs running Oracle Database EE, you need 4 processor licences (8 OCPUs x 0.5 core factor). On-premises, if those same 8 cores were running on a server with 64 physical cores, you would need 32 processor licences without hard partitioning. The BYOL sub-capacity model on OCI is a genuine and significant licence reduction. This is why Oracle OCI licensing and pricing has become so commercially attractive for Oracle Database migrations — the cost advantage compounds quickly when you move a large database estate from physical infrastructure to virtual shapes. Most organisations discover their BYOL position is incomplete only when Oracle's licensing audit team arrives.

Which Licences Are Eligible for OCI BYOL

Enterprise Edition, Standard Edition 2, and Standard Edition licences are all eligible for BYOL. This includes Oracle Database Options as well — Multitenant, Real Application Clusters (RAC), Partitioning, Advanced Compression, Advanced Security, and others. Each option requires separate BYOL licence application, and many organisations miss this critical rule. You cannot BYOL Oracle Database EE with RAC unless you separately licence RAC; applying only the EE licence leaves you non-compliant on the RAC component.

On-premises licences must be on active support (Premier Support or Sustaining Support) to apply as BYOL to OCI. Licences with lapsed support cannot be BYOL'd to OCI. Oracle will validate support status during LMS reviews and audit cycles. You must maintain support on the on-premises licences even while applying them to OCI — this is a common misunderstanding. Buyers assume BYOL means they can drop on-premises support; it does not. The Oracle support costs reduction guide explains the mechanics of restructuring your support footprint when you BYOL, so you are paying only for what you actually need.

The BYOL Counting Methodology: Shapes, OCPUs, and Core Factors

OCI BYOL counting uses a specific methodology that trips up most buyers. For bare metal shapes (BM.DenseIO, BM.Standard, etc.), all physical cores count — there is no sub-capacity benefit on bare metal. This is critical: buyers who select bare metal for performance reasons and expect BYOL sub-capacity counting will find their licence requirements identical to on-premises. A BM.Standard.E4 shape with 128 physical cores requires licences for all 128 cores, just as it would in your data centre. No core factor reduction applies to bare metal BYOL.

For VM shapes, only the OCPUs provisioned in the shape count. Standard Intel x86 shapes use the 0.5 core factor. AMD shapes also use 0.5. Ampere (ARM) shapes use 0.5. The core factor is applied per OCPU — multiply your provisioned OCPU count by 0.5 to get your processor licence requirement. With Flex shapes, you can dynamically increase OCPUs — but each OCPU increase requires additional BYOL licence coverage. If you provision a shape with 4 OCPUs and scale to 16 OCPUs, you need 8 processor licences, not 2. The scaling is where many organisations discover gaps in their entitlements.

BYOL Traps: What Goes Wrong in Practice

We have completed over 500 Oracle engagements. The three most common BYOL errors we encounter are not subtle: they cost millions.

First: mixing bare metal and VM in the same cluster and applying VM counting to bare metal instances. A customer migrates their primary database to a bare metal shape and their standby to a VM shape. They calculate the standby licence requirement using the 0.5 core factor on 8 provisioned OCPUs, arriving at 4 processor licences. Correct. But then they also have 64 physical cores on the bare metal, which they think they can licence at 0.5 because it is running the same database software. Incorrect. The bare metal requires 64 processor licences, not 32. The Oracle OCI Dedicated Region licensing rules are even stricter: Dedicated Region hardware inside your facility is subject to on-premises counting, not BYOL.

Second: forgetting to licence Oracle Database Options separately when using BYOL. A customer applies BYOL for Oracle Database EE across their OCI estate. But they are running RAC on three of their shapes. RAC is an option and must be licensed separately. If you have 8 processor licences for EE, but 12 cores across your RAC cluster, you are unlicensed on RAC. Oracle's LMS team flags this on every single audit. The cost of remediation is always higher than the cost of getting it right before the audit.

Third: assuming BYOL covers Oracle Database Cloud Service (DBCS) and Autonomous Database. BYOL applies only to Oracle Database software running on IaaS compute shapes — VM or bare metal. PaaS services like Oracle Database Cloud Service and Autonomous Database have their own pricing models and cannot be covered by BYOL. You either consume these services at Oracle's published per-service pricing, or you do not use them. There is no licence-swap mechanism. Organisations that migrate a development database to Autonomous Database and expect BYOL coverage to apply will be billed as PaaS consumers, not as BYOL users.

Optimising Your BYOL Position Before the Next Oracle Review

Best practice in BYOL governance means conducting an annual licence reconciliation against your OCI shape inventory. Use the OCI Cost and Usage reports to identify every shape running Oracle Database, and map each one against your licence entitlements. This exercise should happen before every renewal negotiation and before every audit, not during it. Organisations that wait until an audit letter arrives have lost their negotiating position.

Ensure your Oracle support renewal covers all licences applied to OCI, not just the on-premises deployment count. Many organisations restructure their support footprint when they migrate to OCI, reducing support on the on-premises hardware that is no longer running the workload. But they forget to add support to the OCI shape. This creates a compliance gap: you cannot BYOL without active support. Consider repatriating workloads from OCI back to on-premises for database instances that require rare or expensive Options, if the BYOL licence cost exceeds the infrastructure savings. Some customers discover mid-migration that running Multitenant plus RAC plus Advanced Security on OCI via BYOL is more expensive than keeping those instances on-premises, especially when you factor in support costs.

The Oracle total cost of ownership optimisation guide walks through the full methodology for comparing on-premises vs OCI BYOL vs cloud-native alternatives. When you model the decision properly — including every Database Option, every support cost, and every infrastructure cost — the answer becomes obvious. And the answer is different for every workload.