The OCI Bring Your Own Licence bridge maps on-prem Oracle perpetual licences against OCI consumption rates. It is the commercial mechanic that lets the on-prem position pay down OCI Universal Credit consumption rather than sit idle. The Admodum read on the arithmetic, the support-fee posture and the migration mechanics.
BYOL (Bring Your Own Licence) is the publisher-policy construct that lets an existing on-prem Oracle perpetual licence pay for the OCI consumption of an equivalent OCI service. The buyer continues to hold the perpetual licence; the OCI service runs at a reduced (BYOL-rate) hourly consumption rate; the OCI Universal Credit envelope is debited at the BYOL rate rather than the list rate.
The bridge is not a transfer or an exchange: the perpetual licence remains in place on the on-prem position. The bridge is an authorisation: the same licence is authorised to satisfy the OCI consumption obligation, while the perpetual right to deploy on-prem also persists.
The wider editorial sits in the Oracle pillar; the OCI commitment envelope the BYOL bridge consumes against sits at the OCI commitment construct.
The published BYOL conversions are documented in the Oracle Cloud Authorisation document. The headline figures (subject to the document version) include: one Database EE Processor licence against four OCPUs of Database Cloud Service or four OCPUs of Exadata Cloud Service; one Database EE Processor licence against eight ECPUs of Autonomous Database under the ECPU pricing band; one Database Standard Edition 2 Processor licence against two OCPUs (with the SE2 socket-class limits applying to the OCI shape).
The Named User Plus conversion is published in parallel: one Database EE NUP licence against two NUP of Database Cloud Service, with the 25-NUP-per-Processor minimum applying to the converted Processor count.
The arithmetic reads against the core-factor table on the on-prem side (one Intel Xeon core at 0.5 core factor = 0.5 Processor licences) and the OCPU on the OCI side (one Intel-Xeon-based OCPU = one physical core with hyperthreading enabled). The deeper read sits at the Cloud Authorisation document.
The on-prem support fee continues to be paid against the perpetual base when BYOL is in use. The OCI consumption rate is the BYOL rate (lower than the list rate, because the licence credit is applied); the support fee on the perpetual position is unchanged.
This is the dual-cost reading that the buyer must hold in mind: the OCI consumption rate is reduced, but the on-prem support continues. The net cost is OCI consumption (at BYOL rate) plus on-prem support, against an alternative of OCI consumption (at list rate) without any on-prem position.
The buyer-side discipline is to read the support-fee escalator (the 4-to-8 percent annual escalator under support renewal mechanics) against the OCI consumption-rate trajectory, to find the indifference point where dropping the on-prem position altogether (and paying OCI at list rate) crosses BYOL plus support.
The BYOL bridge is governed by the Oracle Cloud Authorisation document. The document is publisher policy, not a contractual instrument: it is republished by Oracle from time to time, and the version in force at the time of the order is the version that applies.
The version-dependence matters. Earlier versions of the Cloud Authorisation document carried a one-Processor-against-two-OCPUs conversion on certain services; later versions widened the conversion to four OCPUs. Future versions can change the conversion further. The buyer-side discipline reads the version in force, holds a copy in the contract file, and reads the renewal moment against the then-current version.
The deeper read on the publisher-policy posture sits at the Oracle Cloud Authorisation document; the parallel publisher-policy document for on-prem virtualisation sits at the Partitioning Policy.
A BYOL migration runs in three phases. Phase one: read the on-prem position (products, metric, quantity, support) and reconcile it against deployment; surface unused entitlement and over-deployed positions before the OCI ramp begins. Phase two: model the OCI ramp against the BYOL conversion, the Universal Credit commitment quantum and the consumption envelope; size the commitment against the modelled consumption with a 10-to-20 percent buffer.
Phase three: execute the migration with consumption observability instrumented from day one. Drift in the consumed envelope is the load-bearing renewal-side risk; instrumentation surfaces drift before the renewal moment.
The ramp-design read sits at OCI ramp design; the wider commitment-envelope read sits at the OCI commitment construct.
The buyer-side discipline holds a current on-prem entitlement map (which products, which metric, which quantity, which support fees), a current BYOL conversion table (against the Cloud Authorisation document version in force), a forward-demand model for the OCI consumption envelope, and a consumption observability stack that surfaces drift in real time.
The renewal moment for the OCI Universal Credit envelope reads against this map. The decision at renewal is the commitment quantum (more or less than the prior period), the tenor (annual or multi-year), the auto-scaling ceiling (where Autonomous Database is in scope) and the support-fee position on the on-prem base (continue, repackage, terminate).
The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; active renewal moments route to the Renewal Programme.
The publisher-policy document that defines the BYOL conversion.
The Universal Credit envelope the BYOL bridge consumes against.
A senior Admodum Oracle advisor will read the on-prem position, the BYOL conversion and the migration mechanics on a private call. Active OCI commitment events route to the Renewal Programme.