BYOL is the Oracle programme that allows existing perpetual licences to be deployed in cloud environments. It is the practical bridge between on premises Oracle investments and a cloud target architecture. The economic value is real. The compliance rules are stricter than most customers expect and the audit posture is unforgiving.
This article is a companion to our licensing compliance pillar and supports our cloud migration advisory service.
What BYOL Allows
BYOL allows the customer to deploy an Oracle product on a supported cloud platform using an existing perpetual licence. The licence does not need to be repurchased. The support is maintained through the existing support agreement. The deployment is licensed against the cloud capacity in accordance with Oracle's published cloud licensing policy.
The supported cloud platforms include Oracle Cloud Infrastructure, Amazon Web Services, Microsoft Azure, and Google Cloud Platform. The rules vary by platform. The conversion ratio between on premises licences and cloud capacity varies as well. OCI is treated most favourably. The hyperscaler clouds are treated less favourably under Oracle's policy.
The Cloud Policy Document
Oracle's cloud licensing policy is published as a non contractual document. It is not part of the customer's contract. It can be modified by Oracle at any time. The policy nevertheless governs the practical interpretation of BYOL because Oracle's audit team applies it as if it were contractual.
The non contractual status of the policy is a defensive lever. Customers with older agreements can sometimes hold that their contractual rights are governed by the contract, not by the policy. The argument is strongest where the contract predates the policy. Customers signing new agreements that explicitly incorporate the policy lose this lever.
The defensive posture is to negotiate the cloud policy into the contract on terms that are favourable to the customer rather than to accept the policy as it is published. Customers who succeed in this negotiation gain a stable cloud licensing position. Customers who accept the policy as published face exposure to future policy changes.
The Conversion Ratios
The conversion ratio determines how many cloud vCPUs are licensed by each on premises processor licence. On OCI the ratio is generally one perpetual processor licence to one OCPU. On the hyperscaler clouds the ratio is generally one perpetual processor licence to two vCPUs for processors with hyperthreading enabled.
The ratio difference produces a structural cost advantage for OCI. The same on premises licence covers more cloud capacity on OCI than on AWS, Azure, or GCP. Oracle has used this differential as part of its cloud sales strategy. Customers evaluating cloud platforms should incorporate the differential into the total cost comparison.
The conversion ratio is also a moving target. Oracle has adjusted the ratios over time. The current ratios are not guaranteed to apply at the next renewal. Customers with material cloud deployments should consider locking the ratios into a contract amendment rather than relying on the published policy.
The Authorised Cloud Environments
The list of authorised cloud environments is also a published policy item. Some clouds are listed. Others are not. Customers who deploy on an unauthorised cloud face a compliance position that is impossible to defend even if the technical deployment is identical to an authorised cloud.
The unauthorised cloud problem is most acute for smaller cloud providers and for private cloud platforms operated by managed services partners. Customers who consider these options for Oracle workloads need to validate the cloud's authorised status before deployment. Deployment on an unauthorised cloud almost always triggers a full price licence demand at audit.
Cloud BYOL deployments are the single largest source of new audit findings we have defended in the last three years. The pattern is consistent. The customer migrates to AWS or Azure under BYOL, the deployment is sized using on premises assumptions, the cloud capacity is licensed at the wrong ratio, and the audit finds a shortfall that often runs into the millions.
The Sizing Discipline
BYOL sizing requires more discipline than on premises sizing. The cloud deployment can be scaled up and down dynamically. The licence position must cover the maximum capacity ever deployed, not the average capacity over time. Customers who size to the average find that the audit identifies the peak as the licensable count.
The sizing discipline involves three controls. The maximum vCPU configuration should be capped at a level that matches the available licences. The autoscaling rules should be limited to within the licensed envelope. The deployment monitoring should detect any breach and trigger remediation before the audit window.
Customers who manage these controls consistently maintain a defensible BYOL position. Customers who delegate cloud sizing to operations teams without licensing context typically accumulate exposure.
The Disaster Recovery Rules
BYOL disaster recovery follows the same rules as on premises disaster recovery. The standby capacity must be licensed unless it qualifies for the limited DR exemption. The exemption applies only to cold standby environments where the system is not running and not consuming compute capacity.
Cloud disaster recovery often relies on warm standby or active active configurations. These do not qualify for the exemption. The standby capacity must be fully licensed. Customers who design cloud DR without licensing context often find that the DR capacity doubles the required licence count.
The design discipline here is to either accept the doubled licensing or to design true cold standby. The cold standby design has operational consequences and may not meet recovery time objectives. The customer should make the design choice with full awareness of the licensing cost.
The Audit Visibility
Cloud deployments are easier for Oracle to audit than on premises deployments. The cloud providers publish APIs that show capacity, runtime, and configuration. Oracle's audit team can request the customer to extract data from these APIs. The data is precise and difficult to dispute.
The audit visibility makes preparation more important than dispute resolution. Customers who audit their own cloud deployments quarterly and remediate findings before the formal audit window typically pass cloud BYOL audits without significant findings. Customers who only respond when Oracle initiates an audit face precise findings that are hard to challenge.
The internal audit discipline should mirror Oracle's methodology. The same API extracts should be run. The same conversion ratios should be applied. The same licence position calculation should be performed. The customer's internal number should match the customer's licensed position before any external audit begins.
The OCI Credits Question
Oracle's cloud credit programmes interact with BYOL in ways that are not always obvious. Customers with OCI universal credits sometimes assume that the credits cover their Oracle workload deployment. The credits cover the infrastructure capacity. The Oracle workload still requires either a separate Oracle PaaS subscription or a BYOL position.
The distinction matters at audit. Customers who deployed Oracle workloads on OCI under the assumption that universal credits provided full coverage often find at audit that the deployment is unlicensed. The remediation requires either a retroactive PaaS subscription or a BYOL conversion.
Where to Read Next
For the EBS user compliance see our EBS article. For the broader compliance posture see our licensing compliance pillar. The Oracle Audit Defense Handbook covers the full methodology. The BYOL deal page covers the contractual framing. The Oracle Database product page covers the product family that drives most BYOL deployments.