Oracle BYOL in the cloud. What bringing your own license costs you.

BYOL lowers the cloud infrastructure rate and leaves your Oracle support bill where it was. It pays on workloads that run most hours of the year and often loses to license included on short or seasonal ones.

Bring Your Own License (BYOL) allows you to apply Oracle licenses you already own to a cloud service and pay a reduced rate for the infrastructure. The alternative is license included, where the license is bundled into the hourly price and you own nothing when the subscription ends.

The choice looks like a rate comparison, but BYOL only pays when four conditions hold, and each fails in its own way.

• Eligibility. The licenses are full use, supported and licensed for the territory where the cloud region sits.
• Support. Every license you bring stays under current support, which Oracle requires for BYOL.
• Conversion. The owned licenses are converted into the target cloud's compute unit before anyone sizes an instance.
• Run hours. The workload runs enough hours of the year to absorb that support.

Everything here is checked against Oracle's own documents: the Oracle BYOL program page, the Oracle cloud licensing policy, the OCI price list, the Oracle Technology Global Price List and the Oracle Database Licensing Information manual for 19c. Read those, not a reseller summary, before you sign anything.

What is Oracle BYOL, and which licenses can you bring?

Under BYOL you apply full use licenses you already own to an equivalent cloud service and pay only the reduced BYOL infrastructure rate. The qualifier that matters is full use, because not every Oracle entitlement is one.

Which licenses are eligible?

Start with the license type printed on the ordering document, then look at the product name. Two entitlements for the same database version can behave in opposite ways once you try to move them.

What does BYOL leave unchanged?

BYOL is not a transfer, a trade in or a credit. Your licenses stay yours, your support contract stays live, and Oracle charges less for the infrastructure because you are not buying the license a second time.

It also suspends nothing. The support bill continues at 22 percent of the original net license fee, indexed at renewal, for as long as you hold the entitlement. Oracle's BYOL FAQ confirms that you keep paying annual support on the licenses you bring. Every cost comparison later in this guide rests on that one line.

Why does the territory clause matter?

Oracle licenses are granted for a defined territory, and few buyers check it before a migration. Running a BYOL workload in a cloud region outside that territory is a contract issue rather than a policy issue. Contract issues are settled by amendment, and an amendment takes weeks of negotiation that your migration plan probably did not schedule.

How do Oracle BYOL conversion ratios work on OCI, AWS, Azure and Google Cloud?

They work differently on Oracle's own cloud than on anyone else's, and that difference is the modeling error we correct most often. On Oracle Cloud Infrastructure the unit is the OCPU, or the ECPU on newer database services. On Amazon, Azure and Google Cloud the unit is the vCPU.

Why is an OCPU not the same as a vCPU?

An OCPU is one physical core with hyperthreading enabled, which presents as two vCPUs. One Enterprise Edition Processor license covers two OCPUs on OCI, and the same license covers two vCPUs on an Authorized Cloud Environment.

Those two statements describe different amounts of compute. Two OCPUs is four vCPUs of capacity, so the identical license buys twice as much processing on Oracle's cloud as it does on Amazon's.

On premises, the Processor Core Factor Table produces the same result through a factor of 0.5 on x86, which is why OCI feels familiar to on premises DBAs and the other clouds do not.

Standard Edition 2 has its own ratios on Oracle's cloud. For Autonomous Database, Oracle requires one SE2 Processor license for every 16 ECPUs or four OCPUs, and caps an SE2 BYOL instance at 32 ECPUs. Our Standard Edition 2 licensing guide covers the socket rules in full.

Where does Oracle publish the ratio, and where does it not?

The OCI conversion sits in the Universal Credits service description and the cloud price list, both of which Oracle updates without notice. The third party cloud counting rule sits in the cloud licensing policy, a unilateral document that has been revised several times. The version current as we write is dated September 4, 2026.

Neither is a contract term. The policy itself states that it may not be incorporated into any contract. Capture the version you modeled against, with the date, and keep it. When the policy changes, that snapshot is the only record of what you reasonably relied on. Our note on the 2026 cloud licensing policy tracks what has changed.

How should you size a BYOL workload?

Count the workload in cloud units first and in licenses second. The most common sizing failure is totaling entitlements and assuming the workload fits.

• Take the Processor licenses you own and are willing to commit, which is rarely the total on the contract.
• Convert them to OCPUs, ECPUs or vCPUs using the rule for the target platform.
• Compare the result to the instance shapes you actually need, including every non production copy.
• Repeat the conversion for every option and pack. Partitioning licensed for 8 OCPUs does not cover a database running on 16.
• Leave headroom for an instance rebuild that changes the hyperthreading setting and doubles the count.

Worked example: the same 16 cores on three platforms

Say you run one on premises x86 database server with 16 cores, licensed for Enterprise Edition and Partitioning. At the 0.5 factor that is 8 Processor licenses of each. At list, 8 Enterprise Edition licenses are $380,000 and 8 Partitioning licenses are $92,000, so $472,000 of licenses carrying about $103,840 of annual support.

The example assumes a cloud core does the same work as the on premises core, which you should test. It shows why a migration off favorable hardware can double the license requirement for an unchanged workload.

On AWS, the Optimize CPUs setting allows a large memory instance to run with fewer active cores. Oracle's policy does not mention it, so agree in writing how Oracle will count such an instance before you rely on it.

How do you check what you are actually running?

• Ordering documents and My Oracle Support. Each Customer Support Identifier shows the license type, metric, quantity and support status you are paying for.
• DBA_FEATURE_USAGE_STATISTICS. Run the feature usage report before you convert options, so you convert only what is in use.
• CONTROL_MANAGEMENT_PACK_ACCESS. This database parameter shows which of the Diagnostics and Tuning packs are enabled, whether or not you licensed them.
• lscpu on the guest. The threads per core line tells you whether hyperthreading is on, and so which vCPU rule applies.
• Cloud provider metadata. On AWS, the CpuOptions field for each EC2 instance shows core count and threads per core. On OCI, the shape shows OCPUs or ECPUs.

When does Oracle BYOL beat license included?

BYOL wins when the workload runs enough hours to absorb the support you are paying anyway. The test is arithmetic rather than judgment, and it takes an afternoon with a spreadsheet.

What is the support cost per OCPU hour?

Take 20 Processor licenses of Enterprise Edition. At list that is $950,000 of license and about $209,000 of annual support. Under BYOL those 20 licenses convert to 40 OCPUs on OCI.

Divide the support bill by the OCPU hours you will actually consume. The result is the real cost of the license component of a BYOL instance, a figure the cloud invoice never shows.

Compare the right hand column with the published gap between the license included rate and the BYOL rate for the same service. If the gap is smaller, license included wins. A bursty workload would need a gap of more than $7 per OCPU hour for BYOL to come out ahead, and in our experience the published gap never comes close.

Many OCI database services now bill per ECPU. Convert the test into the unit the service bills in, using the ECPU mapping, before you compare rates.

Why do steady workloads favor BYOL?

A continuously running database spreads the support bill across 8,760 hours, so the effective license cost per hour falls to its lowest point. You are also buying nothing new, which keeps capital spending out of the decision.

Why do bursty workloads favor license included?

1. Count the hours the workload will actually be running, which is fewer than the hours the instance exists.
2. Divide your annual support on the committed licenses by those OCPU hours.
3. Compare that number to the published gap between the license included and BYOL rates.
4. Choose per workload. A single policy across every database has no commercial basis, and adopting one costs money.

What if you would keep paying the support anyway?

The per hour test assumes the licenses could otherwise be retired. If they must stay supported for another reason, because they back other deployments or because dropping them would trigger repricing, the support is already spent. In that case BYOL adds no license cost at all, and the comparison reduces to the infrastructure rates.

Be precise about which licenses fall into which group. A business case that treats all support as sunk flatters BYOL, and one that treats all of it as avoidable flatters license included.

How do Oracle Support Rewards change the comparison?

Oracle Support Rewards credits a share of your OCI spend against your Oracle technical support invoices, at 25 cents per dollar for most customers and 33 cents for those with an unlimited licensing agreement. On $500,000 of annual OCI consumption, the rewards offset is $125,000 against a support bill you were paying regardless, or $165,000 at the higher rate.

Model the rewards explicitly, then rerun the model with the OCI spend stopped. Rewards that disappear leave the full support bill behind them. Our Support Rewards guide covers eligibility in detail, and the OCI and Exadata Cloud@Customer cost comparison applies the test to Exadata shapes.

What have we seen in Oracle cloud migrations in 2024 and 2025?

Across roughly 20 to 30 Oracle cloud migration engagements I ran in 2024 and 2025, BYOL was the right answer about 60 percent of the time. In the rest, either license included was cheaper on the real run hours or too little of the entitlement could move.

The last pattern costs the most when it is found late. By then the business case has been approved on a license count that was never available to move, and the gap has to be bought at short notice.

What breaks an Oracle BYOL position?

Three things break it: paying twice, converting wrong, and assuming support can be trimmed later. None of them shows up on a cloud invoice, and each surfaces at the worst moment, usually an audit or a renewal.

How do you avoid paying twice?

Decide which specific licenses back the cloud workload, then retire the rest properly in line with the Oracle support terms. Supported licenses that back nothing are pure cost with no compliance benefit.

Why can you not simply drop support on what you do not migrate?

The obvious plan is to migrate half the databases to cloud under BYOL and drop support on the other half. Oracle's support policies block that through matching service levels and repricing.

• Matching service levels: all licenses in a support set must carry the same level, so you cannot leave some of them unsupported.
• Repricing: terminate support on part of a set and Oracle recalculates the fee for the remainder, which usually erases the saving.
• Practical effect: the reduction has to be planned into the contract before the migration, because discovering it afterward leaves you with no bargaining position.
• Where it hurts: a BYOL business case that assumed a linear support reduction, presented to a CFO who now expects it.

Can BYOL create a compliance gap?

Yes, through double use. The same Processor license cannot back an on premises deployment and a cloud instance at the same time, however briefly.

1. Keep a written allocation showing which licenses are committed to which cloud deployment.
2. Watch the migration window, when the old and new environments run in parallel for weeks.
3. Include non production copies, since development and test instances consume the same entitlement.
4. Update the allocation whenever an instance is resized, because the vCPU count has changed.
5. Record the date each on premises database was shut down, with evidence, so the overlap has a documented end.

Why the lower hourly rate should not make BYOL your default

The usual advice is that BYOL always beats license included because the hourly rate is lower. We disagree, because that comparison leaves the license out of the BYOL side. The BYOL rate is low only because the license is paid for on the support invoice, which usually sits in a different budget from the cloud bill.

Put the support back in, per consumed hour, and a lower rate on licenses you keep supporting can leave you with two bills for one workload. In a large share of the migrations we ran, license included won for short or bursty workloads. Model both options against real run hours and let each workload take whichever is cheaper for it.

Does an Oracle BYOL right survive a change of hosting model?

Not automatically, and this assumption costs the most when it fails. The counting rule you modeled belongs to a specific platform under a specific Oracle document, and both can change.

What happens when you move off a named cloud?

The vCPU rule applies only to the services Oracle names as Authorized Cloud Environments: Amazon EC2, Amazon RDS, the Microsoft Azure Platform and Google Cloud Platform. Anywhere else, the on premises rules return.

That is a large change. On premises rules count physical cores in the host, which in a multi tenant cloud you neither control nor can measure. Our cloud counting reference works through what that means in practice, and our note on Authorized Cloud Environment core counting covers the edge cases.

What about moving between Oracle's own offerings?

OCI is not governed by the cloud licensing policy at all. It runs under Oracle's own service terms, and the OCPU conversion there is a commercial term Oracle can revise in a future service description. The switch from OCPU to ECPU pricing on Autonomous Database already changed the unit once.

What happens on a shared hypervisor?

A repatriation from cloud to a shared hypervisor is where BYOL gains disappear. The counting boundary changes from a vCPU you chose to a cluster you did not, on Nutanix AHV, on Hyper-V and on VMware alike.

How does an unlimited licensing agreement interact with BYOL?

If an unlimited licensing agreement is running, read its cloud clause before you deploy. Some ULAs exclude public cloud deployments from the certification count, some cap them, and some are silent, which creates its own dispute at exit.

Oracle's BYOL FAQ adds a further limit: ULA customers cannot certify licenses deployed under the BYOL program to Oracle Cloud. Certification is a one time measurement with permanent consequences. Our Oracle ULA guide and the certification guide cover the sequence.

BYOL does not reduce what you owe Oracle. It changes where you pay it, and the support line is the part that never turns off.

What will Oracle's account team say about BYOL, and how should you answer?

Expect four lines in most OCI conversations. Each has a factual reply that keeps the decision on your numbers.

Having sat on Oracle's side of these meetings, I would add one point. The account team is measured on cloud consumption, so a BYOL proposal that raises committed spend is working as intended for them even when it does nothing for you.

Which contract terms should you ask for before a BYOL migration?

Ask for the terms that turn policy into commitment, and ask before the migration starts, while Oracle still wants the cloud deal.

• Conversion ratio for the term. Write the OCPU, ECPU or vCPU rule you modeled into the ordering document, so a later revision of the service description or policy does not change your license requirement.
• A defined migration overlap. Ask for a stated period during which the same licenses may run on premises and in the cloud, so the parallel run is covered in writing.
• An agreed support reduction. Get the repriced support figure for licenses you plan to retire agreed before migration, with the resulting annual fee stated.
• Territory. Confirm or amend the licensed territory so it covers every cloud region you will use, including disaster recovery.
• ULA cloud treatment. If a ULA is running, state whether and how cloud deployments count at certification.
• BYOL rate protection. Where you commit to Universal Credits, ask that the BYOL rate card for your services holds for the commitment period.

Our white paper on Oracle on Azure and AWS BYOL covers the third party cloud version of these terms, and the AWS licensing guide goes further on RDS.

What to do next

1. Sort by license type. List the licenses you own by license type, then by product name, and mark every Application Specific Full Use and embedded entitlement as out of scope.
2. Confirm the contract facts. Check support status, support set membership and the licensed territory for everything you plan to commit.
3. Snapshot the rules. Save the current cloud licensing policy and the relevant service description, with the date you read them.
4. Convert, then size. Convert the committed licenses into OCPUs, ECPUs or vCPUs for the target platform, size the instances, and repeat the conversion for every option and management pack so each matches the converted base count.
5. Price each workload. Model the support cost per consumed OCPU hour using real run hours, compare it with the published gap between BYOL and license included rates, and choose per workload.
6. Test the rewards. Add Oracle Support Rewards to the model, then rerun it with the rewards removed to see the downside case.
7. Write the allocation down. Record which license backs which instance, from what date, with the migration overlap period shown explicitly.
8. Put it in the contract. Get the cloud counting rule and the conversion ratio into your ordering document or an amendment. A policy you can cite is worth far less than a term you can enforce.

Frequently asked questions