How Oracle BYOL Licensing Works on Oracle Cloud@Customer
Introduction: Oracle’s “Bring Your Own License” (BYOL) program allows organizations to use their existing software licenses when moving to Oracle Cloud services.
In simple terms, BYOL means applying licenses you already own (for databases or other Oracle products) to equivalent services in the Oracle Cloud, instead of purchasing new licenses as part of the cloud subscription.
This concept is crucial for Oracle Cloud@Customer environments, where Oracle installs cloud infrastructure in your data center, and for Oracle’s Universal Cloud Credit model of purchasing cloud capacity.
This article starts from the fundamentals and shows how BYOL works with Oracle Cloud@Customer and how Universal Cloud Credits factor into the equation.
What Does BYOL Mean for Oracle Customers?
BYOL Defined:
BYOL stands for “Bring Your Own License.” It is a licensing model where you reuse your existing Oracle on-premises licenses for Oracle software when you move those workloads to Oracle’s cloud.
Traditionally, if you subscribe to a cloud service (like an Oracle Database cloud service), the cost could include a “license-included” fee – essentially renting the Oracle software license as part of the service. BYOL, however, lets you avoid paying for the license again by bringing your pre-owned license.
You continue to pay annual support for your on-prem license to Oracle (as you normally would), but the cloud service cost is reduced to reflect that you are supplying the license yourself.
License Mobility:
A key feature of Oracle’s BYOL program is license mobility. Oracle permits you to move licenses between on-premises environments, Oracle Public Cloud (OCI), and Oracle Cloud@Customer. If you have an Oracle Database license running on your servers, you can reassign it to an Oracle Cloud@Customer deployment, and even move it back on-prem later if needed.
There is 100% compatibility between on-prem and cloud regarding workload and licensing units. Oracle’s policy explicitly states that you have complete license mobility between on-premises, Oracle Cloud Infrastructure, and Oracle Cloud@Customer.
This flexibility ensures that adopting Cloud@Customer doesn’t “lock” your licenses in the cloud – you maintain control over where you use them.
License Mapping Rules:
When using BYOL, you must follow Oracle’s mapping of your license entitlements to cloud resources. At a high level, Oracle defines an equivalency so that a given on-prem license covers a certain amount of cloud usage.
For example, one Oracle Processor license typically entitles you to two OCPUs of the Oracle PaaS service in the cloud. (An OCPU in Oracle Cloud is roughly one CPU core’s processing power.)
In practice, if you own a license for Oracle Database Enterprise Edition for four processors on-prem, you could allocate up to 8 OCPUs of Oracle Database service in Cloud@Customer under BYOL.
These mappings ensure you’re not exceeding your licensed capacity. Oracle provides detailed BYOL conversion ratios for each product in its service descriptions. Still, the main idea is that BYOL lets you leverage the licenses you bought for on-prem hardware to cover usage in the cloud environment.
Cloud Services Eligible for BYOL:
Most of Oracle’s major cloud services that correspond to on-prem software have BYOL options. For example, Oracle Database Cloud (both standard Database service and Autonomous Database) supports BYOL, as do Oracle WebLogic Server in the cloud, Oracle Analytics Server, etc.
You can bring that license if a cloud service has an equivalent on-prem product. However, note that some cloud services are cloud-only (with no on-premises equivalent) – for instance, certain SaaS offerings or niche PaaS like Oracle IoT Cloud – those do not have BYOL because there’s no owned license to bring.
However, OCI and Cloud@Customer widely support BYOL for core infrastructure and platform services (database, middleware, etc.).
How BYOL Works on Oracle Cloud@Customer
Oracle Cloud@Customer Overview:
Oracle Cloud@Customer is a deployment model in which Oracle delivers its cloud technology inside your data center.
This could be an Exadata Cloud@Customer database system or a full Dedicated Region Cloud@Customer, bringing a mini-OCI region on-premises.
In all cases, the hardware and base cloud software are provided as a subscription service, but they live behind your firewall.
Cloud@Customer gives you cloud benefits (like elasticity, managed infrastructure, and cloud APIs) while keeping data and systems on-site for compliance or latency reasons.
BYOL in Cloud@Customer:
In Cloud@Customer environments, BYOL works like Oracle’s public cloud, benefiting from on-prem isolation.
When you deploy a service on Cloud@Customer (for example, creating a new Oracle database on an Exadata Cloud@Customer system), you will choose a licensing mode for that deployment: “License Included” or “BYOL.” If you choose License Included, Oracle will charge the higher rate that covers the database license within the subscription.
If you choose BYOL, you confirm that you have a valid Oracle Database license on-premises that you are assigning to cover this Cloud@Customer database. Oracle charges you only for the cloud infrastructure and support, not the database license fee.
In practical terms, a Cloud@Customer deployment with BYOL means:
- You continue to own and maintain your Oracle license. You must keep paying for your on-premises support contract for that software. Oracle still provides support (patches, updates) through that contract as if the software were on your server.
- Oracle bills you a reduced rate for the Cloud@Customer service. The billing for the cloud service (like the hourly or monthly charge per CPU) is much lower with BYOL because Oracle doesn’t include the software license cost. Essentially, you’re paying for the hardware usage, management, and support services provided by Oracle Cloud@Customer, but not for the right to use the Oracle software itself (since you already have that right via your existing license).
Compliance and Setup:
To use BYOL on Cloud@Customer, you will designate which licenses you are applying. Oracle expects that you have enough licenses to cover the capacity you use. For databases, this means you need to own sufficient database processor licenses for the number of OCPUs you’ll activate on the Exadata Cloud@Customer.
If you want to use additional options (like Oracle Database options such as Partitioning, Advanced Security, etc.), you must also own those licenses or include them in your ULA, otherwise you should not enable those features under BYOL. Cloud@Customer’s management interface will typically have you attest or select that you are using BYOL for a deployment.
Oracle trusts the customer to be honest and compliant, but they reserve the right to audit compliance. It’s important to track that your on-prem license inventory matches your Cloud@Customer usage (for instance, if you move a license to Cloud@Customer and also accidentally keep using it on-prem simultaneously beyond the “10-day transfer” rule, that would be non-compliant).
The good news is that Oracle’s rules generally allow moving licenses back and forth without lengthy approval—you just can’t exceed your usage at any given time beyond what you own.
Example: Suppose your company owns 10 Oracle Database Enterprise Edition processor licenses for an old on-premises environment. Now you have an Exadata Cloud@Customer to modernize your database platform.
You can create an Autonomous Database or a Database VM cluster on the Exadata Cloud@Customer and choose BYOL. If each Exadata OCPU corresponds to half of a processor license (following Oracle’s one proc = 2 OCPUs mapping), your 10 processor licenses let you use up to 20 OCPUs of database capacity on the Cloud@Customer. Oracle will only bill you the BYOL rate for those OCPUs.
For a rough idea, if the license-included price for an Exadata OCPU is say $1 (arbitrary unit) per hour, the BYOL price might be around $0.25 per hour for the same resource because you’re not paying the Oracle Database license fee in that $0.25 – you already paid for it when you bought the license. This translates to substantial savings, which we’ll discuss next.
The Role of Universal Cloud Credits in BYOL
Universal Cloud Credits (UCC) Basics:
Oracle’s Universal Cloud Credits is a purchasing model where you commit a certain amount of money to Oracle Cloud and then spend it flexibly on any OCI services (public cloud or Cloud@Customer) as you consume them.
Instead of buying specific resources upfront, you buy a pool of credits that get deducted as you use services (hourly, monthly, etc.).
It provides flexibility because you can use the same prepaid funds for many different Oracle Cloud services and even across regions or Cloud@Customer installations.
In recent years, Oracle has introduced unified billing in the context of Cloud@Customer, so Cloud@Customer services have also been drawn down against Universal Credits. When Oracle installs Cloud@Customer hardware, you typically have a contract with a certain monthly credit commitment (over a term like 4 years).
The hardware portion (the base infrastructure in your data center) might be a fixed monthly fee, and the cloud services running on it (databases, etc.) consume credits just like in OCI public cloud.
Starting with newer generations, all Cloud@Customer subscriptions use the Universal Credit model – meaning whatever you run on that on-prem cloud will simply burn through your cloud credits, at the predefined rates.
BYOL and Credit Consumption:
BYOL does not change how you use cloud credits, but how fast you use them. Because BYOL reduces the rate charged for a given service, you consume fewer credits for the same usage than a license-included service.
For example, if running an Oracle database for 1 hour on 1 OCPU would cost two credits with the license included, it might cost only 0.5 with BYOL (since you’re only paying for the infrastructure portion).
Thus, BYOL stretches your Universal Credits further. If you have a yearly Oracle Cloud@Customer credit allotment, using BYOL means you can run more hours of service before exhausting your credits, or equivalently, you spend less money out of pocket for the same workload.
Tying it Together – Lower Costs:
When leveraging BYOL on Cloud@Customer with Universal Credits, the benefits compound:
- You avoid buying new licenses by reusing existing ones.
- Each unit of service (CPU, etc.) is billed at a much lower rate, so your prepaid credits cover more usage.
- Overall, your total cost of ownership for the cloud service drops significantly. Oracle has noted that for certain services (like Autonomous Database), BYOL can lower the metered compute costs by over 70%. Oracle’s price lists show that BYOL rates are often 50-75% lower per hour than license-included rates for the same resource. This highlights how valuable BYOL can be for cost optimization.
Universal Credits Flexibility:
Another advantage is flexibility. You can choose how to allocate both if you have credits and a pool of licenses. You might run one workload in BYOL mode and another in license-included mode, depending on what licenses you own.
Universal Credits don’t care – they just get applied to whatever services you consume. So, for instance, you could use some credits to run an Oracle Analytics Cloud instance (which might not be BYOL if you don’t have a license for that) and some credits for an Oracle Database with BYOL.
This flexibility allows IT decision makers to balance their use of existing licenses versus new cloud services within one financial commitment.
Benefits and Use Cases of BYOL on Cloud@Customer
Cost Savings:
The most immediate benefit of BYOL is cost savings. Suppose your organization has already invested in Oracle licenses (which often cost tens or hundreds of thousands of dollars). In that case, BYOL lets you get full value from that investment in the cloud era.
You’re not paying twice for the same software capability. BYOL pricing can be dramatically cheaper, especially for large Oracle Database deployments. Over time, this can save millions in subscription fees.
Oracle’s Support Rewards program (available with OCI Universal Credits) can also offset costs. For every dollar you spend on Oracle Cloud, you earn credits that can reduce your on-prem support fees.
This effectively rewards BYOL users because, as you move more workloads to Oracle Cloud (including Cloud@Customer), you can lower the cost of maintaining any remaining on-prem Oracle support contracts.
Leverage Existing Investments:
Many enterprises have expansive Oracle environments with licenses for Database, WebLogic, Oracle Linux, etc. When adopting Cloud@Customer, BYOL allows a smooth transition of these environments to an as-a-service model without abandoning the license assets you’ve accumulated.
For example, suppose you own Oracle Database Enterprise Edition and various add-on option licenses (like RAC, Diagnostics Pack, etc.). In that case, you can deploy an Exadata Cloud@Customer and use all those options (assuming you license them) in the new environment. This is great for ROI: the licenses you bought for on-prem hardware now continue to serve on a modern cloud platform.
License Mobility for Hybrid Cloud:
BYOL on Cloud@Customer is particularly useful for hybrid cloud scenarios. Perhaps you are gradually migrating workloads from traditional on-premises to Cloud@Customer or want the ability to burst to the public cloud later.
Since the licenses are portable, you could, for instance, move an Oracle Database license from an on-prem server to your Cloud@Customer for a year, then later decide to move that workload to Oracle’s public cloud (OCI) – and simply shift the license over (Oracle allows mobility as long as you’re not running the same license in two places at once).
This flexibility in deployment is a huge benefit to organizations with evolving infrastructure strategies. Cloud@Customer becomes another venue (alongside on-prem and public OCI) where you can run your licensed software as needs dictate.
Use Cases: Some common use cases for BYOL on Cloud@Customer include:
- Data Sovereignty Scenarios: A government or bank must keep data on-premises for compliance, so they opt for Cloud@Customer. They already own many Oracle Database licenses, so they use BYOL to minimize the incremental cost of moving to this model. They get a cloud experience in their data center and pay mainly for infrastructure, not new licenses.
- Datacenter Consolidation: A company with numerous Oracle databases on aging hardware decides to consolidate onto an Oracle Exadata Cloud@Customer. They bring all their existing DB licenses into the new environment (BYOL) and retire the old servers. This way, they achieve consolidation and modernization with minimal new license spend. The Cloud@Customer provides high-performance hardware, and Oracle manages it, while their license costs remain the same (they are just paying for support).
- Cloud Bursting with License Reuse: An organization in a seasonal industry might normally run Oracle workloads on-premises, but during peak season, they activate additional capacity on Cloud@Customer. BYOL allows them to scale up using their spare licenses (or by temporarily reallocating licenses from non-peak systems) to cover the expanded Cloud@Customer usage and later scale down. They avoid long-term license purchases for what is a peak need. (Oracle’s policies allow some flexibility for short-term moves, though careful planning is needed to stay compliant.)
- Maximizing a ULA (Unlimited License Agreement): If a customer has an Oracle ULA – a contract allowing unlimited use of certain Oracle software – they might deploy very large workloads on Cloud@Customer under BYOL, since they effectively have rights to as many licenses as needed. This can maximize the value of their ULA before it expires, and Cloud@Customer ensures the workloads stay on-prem if required by the ULA terms. (It’s important to verify how ULAs apply to cloud use; sometimes an amendment is needed to include cloud deployments.)
Considerations and Risks of BYOL
While BYOL offers many advantages, there are important considerations:
License Compliance: With great flexibility comes the responsibility to track license usage. You must ensure that the total of cores (OCPUs) you use in Oracle Cloud (including Cloud@Customer and public OCI) with BYOL at any time does not exceed what you’re entitled to by your on-prem licenses.
Oracle’s auditing practices still apply—they can audit your cloud usage. Non-compliance (e.g., using more databases or options than you have rights to) could result in back charges or required true-ups.
Thus, governance and internal monitoring are key. Tools or scripts that regularly report how many OCPUs are deployed under BYOL and what licenses those map to can be very helpful.
Read Oracle Cloud at Customer vs. Dedicated Region.
Feature Usage:
Under BYOL, you can only use the features and editions your license covers. For example, suppose you have Oracle Database Enterprise Edition licenses but did not purchase the Partitioning option.
In that case, you cannot start partitioning on your Cloud@Customer database unless you add that license or switch that database to a license-included model for that feature. In contrast, a license-included cloud service often bundles all features.
So, BYOL requires some discipline: You may need to disable or refrain from using certain features in the cloud service if you don’t have the corresponding license. If your licenses are of a lower tier than what the cloud service could offer, this is both a compliance risk and potentially a functional limitation.
Careful planning during migration can mitigate this (for instance, know exactly which options your on-prem databases are using and ensure you have those licenses before moving them under BYOL).
Support Costs:
When you bring your license, you keep paying Oracle Support yearly for those licenses. This cost can be significant (typically ~22% of the license list price annually). The support cost is hidden within the subscription fee in a license-included subscription.
So, while BYOL lowers your cloud bill, remember to consider that you’re still paying support separately.
The overall cost is usually still lower with BYOL for a given configuration. Still, the savings might be less than expected if your licenses are older and have high support fees.
Some companies negotiate support discounts or consider Oracle’s Support Rewards (which, as mentioned, gives you credits to offset support fees based on cloud spend) to alleviate this. Essentially, BYOL shifts some cost from operational cloud fees back to your support contract. It’s not bad, just something to account for in budgeting.
Complexity of Management:
Using BYOL introduces an extra management layer – you must manage both the cloud subscriptions and the license assets. For example, if you decommission a Cloud@Customer database using BYOL, you should reallocate that freed license back to on-prem or a “license pool” for future use.
Maintaining documentation or using Oracle’s LMS tools to keep track is wise. This is simpler if you have a smaller number of large licenses (like a handful of processor licenses covering many cores) versus many smaller licenses. Many IT departments create internal processes to approve any cloud deployment under BYOL to ensure a license is available and gets assigned from the on-prem pool.
When BYOL Might Not Benefit:
If your organization does not already own Oracle licenses, or if you only have older Standard Edition licenses but want to use Enterprise Edition in the cloud, BYOL might not be applicable or beneficial.
In such cases, the license-included model could be easier. Also, if you plan to drop Oracle support for some licenses (perhaps to migrate away or because you’re replacing the software), you can’t use BYOL without active support. So BYOL is best for those who intend to stay with Oracle and have already invested in licenses.
