Oracle ULA and Oracle Cloud: Counting OCI Deployments

OCI and ULA: Two Separate Commercial Frameworks

An Oracle Unlimited License Agreement (ULA) is an on-premises licensing vehicle. It provides unlimited deployment rights for specified Oracle products — typically Oracle Database EE and selected options — across the contracted entities and territories. At certification, those deployments convert to perpetual on-premises licenses.

Oracle Cloud Infrastructure (OCI) is a separate commercial framework. OCI services — including Oracle Database as a Service (DBaaS), Oracle Autonomous Database, and Oracle Base Database Service — are billed under OCI Universal Credits or specific cloud service subscriptions. These are cloud consumption charges, not perpetual license purchases.

The critical point: OCI Universal Credits consumption does not, by default, count toward your ULA certification. Running Oracle Database EE in OCI via a standard OCI subscription is a cloud service transaction — not a deployment of the perpetual licenses that your ULA tracks. When you certify your ULA count, OCI-licensed deployments are outside the count unless you have specifically structured the relationship using Bring Your Own License (BYOL).

BYOL in OCI: The Key Mechanism

Bring Your Own License (BYOL) is the mechanism that allows ULA holders to deploy Oracle Database EE in OCI using their own perpetual or ULA-covered licenses rather than paying for the license component via OCI subscription pricing. Under BYOL, the customer "brings" a license from their on-premises entitlement — including from an active ULA — and applies it to an OCI compute shape running Oracle Database.

The BYOL model matters for ULA certification because when you bring a ULA license to OCI under BYOL, you are consuming a ULA deployment right in the cloud rather than on-premises. The question at certification is: does a BYOL OCI deployment count toward your certified processor license total?

Oracle's answer, in most current ULA contracts, is yes — BYOL deployments in OCI count toward certification, subject to the same Core Factor calculation as on-premises deployments. The OCPU (Oracle Compute Unit) in OCI maps to 1 physical core on the underlying hardware, and the Core Factor of 0.5 applies for Intel-based shapes, just as it does on-premises.

This creates a significant opportunity — and a significant complexity: you can accelerate your ULA certification count by deploying additional database capacity in OCI under BYOL. But you need to track BYOL OCI deployments with the same rigour as on-premises deployments. Oracle's LMS scripts do not automatically capture OCI BYOL deployments — this requires manual data collection from the OCI console and from Oracle's own license management tools.

How OCI Migration Affects Your Certification Count

The impact of an OCI migration on your ULA certification count depends entirely on how the migration is structured. Three migration models produce materially different certification outcomes.

Model 1: Full OCI Universal Credits (no BYOL). You migrate Oracle Database workloads from on-premises to OCI, paying for the Database license component via OCI subscription pricing (Oracle-provided license, or OPLC). Your on-premises deployment count decreases as you decommission on-premises instances. At certification, your count reflects only the remaining on-premises deployments — potentially a much lower number than before the migration. You have effectively paid Oracle twice: once in the ULA fee for on-premises rights you are no longer using, and again in OCI subscription fees for the cloud workload. This is Oracle's preferred outcome.

Model 2: OCI BYOL (where ULA language supports it). You migrate workloads to OCI using BYOL, applying ULA-covered license rights to OCI compute shapes. The OCI BYOL deployment counts toward certification. The on-premises count decreases; the OCI BYOL count increases. Net effect on certification count: neutral or positive, depending on Core Factor calculations for the OCI shapes versus the on-premises hardware. This is the migration model that protects ULA value.

Model 3: Hybrid (some BYOL, some standard OCI). You migrate some workloads under BYOL and others under standard OCI subscription pricing. The BYOL deployments count; the standard OCI deployments do not. The net effect depends on the split — but any standard OCI consumption during the ULA term is wasted ULA value.

Oracle's Agenda: Why They Push OCI During ULA Terms

Oracle's cloud revenue has grown substantially, and OCI is the primary growth vehicle for Oracle's cloud business. ULA holders represent a strategically important segment: they are already paying Oracle significant annual fees, they have large Oracle Database deployments, and they face the existential question of what to do with those deployments in a cloud-first infrastructure world.

Oracle's playbook for ULA holders is to initiate OCI migration discussions at Year 2 of a 3-year ULA — precisely when the customer is beginning to think about certification. The pitch combines three elements: OCI gives you flexibility for the cloud era; migrating during the ULA term means you don't need to certify a large on-premises count; and Oracle will provide migration support and OCI credits to make the transition economically attractive.

The trap in this pitch is the second element: "you don't need to certify a large on-premises count." Oracle frames this as a benefit — fewer perpetual licenses to manage. In reality, it means Oracle has successfully converted your perpetual license entitlement into a recurring cloud subscription revenue stream. Every year you run Oracle Database in OCI under a standard subscription rather than BYOL is a year Oracle collects both the license and the support revenue — instead of just the support revenue on a perpetual license you already own.

The commercially correct response to Oracle's OCI pitch is: certify your full deployment count first, exit the ULA with the maximum perpetual entitlement, and then negotiate OCI pricing from a position where you hold the perpetual license as a credible alternative. Oracle cloud advisory conducted after certification — not during the ULA term — consistently delivers better OCI pricing than Oracle's migration deals.

Oracle Autonomous Database and ULA Holders

Oracle Autonomous Database (ADB) is a fully managed cloud database service available on OCI. It runs on Oracle Database EE infrastructure but is billed as a cloud service — OCPU-hours or ECPU-hours, not perpetual processor licenses. ADB is not typically included in ULA product schedules because it was not commercially available when most current-generation ULAs were signed.

The licensing question for ULA holders considering ADB is: can ADB usage count toward ULA certification? The answer in most cases is no. ADB is billed as an OCI service, not as a BYOL deployment of Oracle Database EE. The ULA covers Oracle Database EE as a separately licenced product — ADB's consumption model is incompatible with the perpetual processor license counting framework that ULA certification uses.

There is an exception for Autonomous Database Dedicated (ADB-D), which runs on dedicated Exadata infrastructure that the customer manages. Where the underlying Exadata infrastructure is deployed under BYOL, the Exadata compute nodes can potentially be counted in the ULA certification. This is the same analysis as the ExaCC certification question — it depends on your specific ULA contract language and requires independent review.

Four Scenarios: ULA Holders Migrating to OCI

Strategy: Protecting Your Certification Count During OCI Migration

If you are a ULA holder planning or undertaking an OCI migration, these five principles protect your certification count and commercial position.

• Do not decommission on-premises instances until after certification. Every on-premises Oracle Database EE instance you shut down before the certification date reduces your certified count. If you are migrating to OCI, maintain the on-premises instance until the certification is signed — then decommission.
• Verify BYOL eligibility in your ULA contract before deploying in OCI. Get independent legal confirmation that your ULA language supports BYOL OCI deployments counting toward certification. Do not rely on Oracle's sales team's verbal confirmation — Oracle sales commitments are not binding. Get it in a written amendment to the ULA if necessary.
• Track OCI BYOL deployments with the same rigour as on-premises. Oracle's LMS discovery scripts do not capture OCI deployments automatically. Build a parallel tracking process for OCI BYOL — OCPU count per shape, Core Factor application, and per-entity deployment records.
• Refuse Oracle's OCI migration deal if it conditions certification on cloud commitment. Oracle occasionally structures migration deals in which signing an OCI commitment reduces your certification count in exchange for OCI credits or pricing concessions. This is a commercial trap: the perpetual license value you surrender is worth more than the OCI credits you receive. Certify at your full count first.
• Get independent cloud advisory before and after certification. The OCI pricing you negotiate six months after certification — with perpetual licenses in hand — is materially better than the OCI pricing Oracle offers during ULA renewal discussions. Time your cloud negotiations accordingly.