Oracle BYOL Licensing Explained
Oracle BYOL licensing, or Bring Your Own License, lets you carry an existing on premise Oracle licence into OCI and pay only the reduced infrastructure rate. It saves money only when the carried licence is genuinely spare and you keep paying its support, and it moves the full burden of proving entitlement onto the customer.
What is Oracle BYOL licensing?
Oracle BYOL licensing, short for Bring Your Own License, is the model that lets a customer carry an existing on premise Oracle licence into Oracle Cloud Infrastructure or an authorized third party cloud and pay only the reduced infrastructure rate for the cloud service. Instead of buying the right to use the software again as part of the cloud price, you apply a licence you already own, and Oracle charges the lower BYOL rate that excludes the software component. It is the cloud equivalent of moving a perpetual licence from one server to another, with a conversion rule layered on top.
BYOL exists because Oracle needs a way to move its large installed base of perpetual licences into the cloud without forcing customers to repurchase. For the customer, it is the mechanism that protects sunk licence investment. For Oracle, it is a retention tool that keeps the support stream alive while moving the workload onto consumption. Both readings are correct, which is why BYOL must be assessed on its arithmetic rather than accepted as an obvious saving. The decision that actually matters is the comparison with License Included, and this article covers the BYOL side of it in the context of the Oracle OCI licensing pillar.
How BYOL works on OCI
Operationally, BYOL is a billing election. When you provision an OCI database or service, you choose the BYOL rate rather than the License Included rate, and you assert that you hold sufficient on premise licences to cover the deployment. Oracle does not verify this at provisioning time; the obligation to hold the entitlement is yours, and the gap between what you provision and what you own is exactly what an audit later examines. This is the central discipline of BYOL: the cloud will happily let you deploy more than you are licensed for, and it will not warn you when you do.
The licences carried must match the program and the metric precisely. A processor licence on Database Enterprise Edition carries into a database service; it does not silently cover options such as Partitioning, Advanced Security, or Real Application Clusters unless those options are separately owned. The same applies to management packs. Carrying a base Enterprise Edition licence and enabling the Diagnostics Pack in the cloud creates a shortfall on the pack, a frequent and avoidable finding examined in database options on OCI. Standard Edition 2 follows different rules again, because it is licensed by socket on premise and mapped to OCPUs in the cloud.
Because BYOL is self asserted, the discipline that protects you is documentation. The carried entitlement, the deployment it covers, and the conversion arithmetic should be recorded at the moment of provisioning, not reconstructed during an audit. A standing record reads as governance; a reconstruction produced under an Oracle data request reads as a defensive guess, and Oracle treats the two very differently.
The BYOL conversion ratio
The number that determines whether BYOL is economic is the conversion ratio between the on premise licence and the cloud capacity it covers. Under Oracle's cloud policy, one processor licence of a program licensed by core factor generally covers a defined number of OCPUs, and the mapping depends on whether you are on OCI or an authorized cloud and on the edition.
| On premise licence | Covers on OCI | Counting note |
|---|---|---|
| 1 processor, Enterprise Edition | 2 OCPUs | Hyper threading on; two vCPU rule applied |
| 1 processor, Standard Edition 2 | 4 OCPUs | SE2 socket based on premise, mapped to OCPUs in cloud |
| Options and packs | Must be owned separately | Base licence does not carry options |
| Named User Plus | Minimums still apply | Per OCPU NUP minimums follow the program |
The conversion is where the on premise core factor table stops governing. As set out in OCPU versus vCPU, the cloud policy substitutes its own counting, and a processor that carried a favourable 0.5 core factor on premise may be counted less favourably in the cloud, or vice versa. Modelling the conversion for your specific processors before committing the architecture is the difference between BYOL saving money and quietly costing more than License Included. The detail of how the multiplier is applied lives in core factor in the cloud.
What happens to support under BYOL?
BYOL only works if you keep paying support on the on premise licences you are carrying. The reduced BYOL infrastructure rate assumes you continue to fund the software through your existing support contract; you cannot carry an unsupported licence into the cloud and pay only infrastructure. This is the hidden cost that flips many BYOL business cases: the apparent saving on the cloud rate is offset by the on premise support you must keep alive, and that support is typically twenty two per cent of the original licence list price every year.
This is also where Oracle Support Rewards enters. Oracle rebates a portion of OCI consumption against that on premise support bill, partly offsetting the cost of keeping the carried licences supported. For a standard customer the rebate is modest; for a customer with an Unlimited License Agreement it is larger. The reward improves the BYOL case but ties you to continued OCI spend, so it should be modelled as a conditional discount rather than a clean saving, consistent with the wider analysis in the Oracle OCI licensing pillar.
BYOL across AWS and Azure
BYOL is not exclusive to OCI. The same perpetual licence can be carried into Amazon Web Services or Microsoft Azure, which Oracle designates as Authorized Cloud Environments. The counting rule there is the two vCPU per processor rule with no core factor applied, set out in the same policy document. The practical consequence is that the same licence covers a different amount of capacity depending on which cloud it lands in, and the comparison is not always intuitive.
The deployment specifics differ by platform: see Oracle Database on AWS and Oracle Database on Azure. The strategic point is that BYOL portability gives the customer leverage. A licence that can run economically on three clouds is harder for Oracle to lock to one, and that optionality is worth preserving when negotiating cloud commitments.
When does BYOL actually save money?
BYOL saves money in one clear case: you hold perpetual licences you are already paying support on, those licences are not fully deployed on premise, and you can redeploy the idle portion into the cloud at the infrastructure rate. In that case the cloud workload costs only infrastructure plus support you were paying anyway, and BYOL is decisively cheaper than buying the software again through License Included.
BYOL stops saving money when any of those conditions fails. If you would have to buy the licence to carry it, License Included is usually cheaper because it avoids a perpetual purchase. If you could terminate the on premise support to save cash but BYOL forces you to keep it, the retained support is a real and recurring cost. And if the conversion ratio for your processors is unfavourable, the infrastructure saving is eroded. The BYOL versus License Included article works the break even, and the cloud and OCI practice models it per workload.
The BYOL audit risks
BYOL carries every on premise audit risk into the cloud and adds new ones. The deployment can exceed the licences carried, especially after an elastic scaling event that nobody reconciled. Options and packs can be enabled in the cloud without the matching entitlement. The conversion can have been calculated against a policy Oracle later disputes. And because OCI provisioning does not enforce entitlement, the gap accumulates silently until an audit surfaces it, by which point it spans months of consumption.
The defensive posture is to baseline the carried entitlement before migration, document the conversion against the current policy, and govern scaling so the deployment never exceeds what is owned. Autoscaling in particular should be capped at the licensed OCPU count or moved to a License Included service where elasticity is the point. If a claim does land, the audit defence practice handles it. Either way, BYOL is safe only when it is documented.
Modelling the business case
A defensible BYOL business case has four lines: the infrastructure rate for the chosen OCI shape, the retained on premise support on the carried licences, any Support Rewards rebate against that support, and the conversion ratio that determines how many OCPUs the licence covers. The comparison case is the License Included rate for the same shape, which bundles software and support into one number. BYOL wins when its infrastructure plus net support is below the License Included rate over the planning horizon.
The horizon matters because the two models age differently. License Included is pure consumption that stops when you stop using it. BYOL front loads a sunk licence and a continuing support obligation, so it rewards long, stable workloads and penalises short or shrinking ones. A workload you expect to retire in eighteen months rarely justifies BYOL; a stable production database you will run for years usually does. This time dimension is why the model decision is made per workload rather than as a blanket policy across the estate.
The buyer side view
BYOL is the right model for an existing Oracle estate with idle, supported licences and stable, long lived workloads, and the wrong model for net new or short lived workloads with no spare entitlement. The discipline is to treat it as the redeployment of a sunk cost, not as a discount, and to prove the arithmetic per workload before committing. Carry only what you own, count it against the policy that applies, keep the support funded, model the rewards as conditional, and document the position so an audit finds governance rather than a reconstruction. To model a BYOL business case across your estate, request a consultation.
Common questions.
What is Oracle BYOL licensing?
Oracle BYOL, or Bring Your Own License, lets a customer carry an existing on premise Oracle licence into OCI or an authorized cloud and pay only the reduced infrastructure rate, rather than repurchasing the software as part of the cloud price. The customer must hold sufficient entitlement to cover the deployment.
Does BYOL require keeping on premise support?
Yes. The reduced BYOL rate assumes you continue paying support on the carried licences through your existing contract. You cannot carry an unsupported licence and pay only infrastructure, which is the hidden cost that flips many BYOL business cases.
How many OCPUs does one processor licence cover under BYOL?
Under Oracle's cloud policy, one Enterprise Edition processor licence generally covers two OCPUs where hyper threading is enabled, applying the two vCPU rule rather than the on premise core factor table. Standard Edition 2 and options follow different mappings.
Can I use BYOL on AWS and Azure?
Yes. AWS and Azure are Authorized Cloud Environments where the same licence can be carried under a two vCPU per processor rule with no core factor. The same licence covers different capacity on different clouds, which gives the customer useful negotiating optionality.
When does BYOL save money?
BYOL saves money when you hold supported perpetual licences that are not fully deployed on premise and can redeploy the idle portion into the cloud at the infrastructure rate, especially for stable long lived workloads. It stops saving when you would have to buy the licence anyway or for short lived workloads.
Does BYOL remove audit risk?
No. BYOL carries every on premise audit risk into the cloud and adds over deployment, unlicensed options, and reliance on a revisable policy. OCI does not enforce entitlement at provisioning, so gaps accumulate until an audit surfaces them.