Oracle EBS on OCI Licensing

BYOL versus licence included

When Oracle E-Business Suite moves to Oracle Cloud Infrastructure, the first decision is the licensing model for the underlying programs. There are two: bring your own licence, where you carry your existing perpetual EBS and database entitlements onto OCI compute and pay only for the infrastructure, and licence included, where the subscription bundles the software rights into the cloud price. For an established EBS estate with substantial perpetual entitlement already on maintenance, bring your own licence is almost always the right model, because it preserves the value of licences you have already paid for rather than buying the same rights again inside a subscription.

The choice has consequences for both cost and flexibility. Under bring your own licence you continue to pay support on the perpetual estate and pay OCI for compute, and you retain the perpetual rights if you later leave OCI. Under licence included you stop paying separate support but lose the underlying entitlement when the subscription ends. For a customer weighing OCI against the SaaS path, this is a different decision from the one analysed in the Fusion migration article: OCI keeps EBS as EBS on Oracle infrastructure, whereas Fusion replaces EBS with a different product. The EBS licensing pillar frames where each path fits.

How OCPU counting works

OCI measures compute in OCPUs, and the OCPU is the unit that drives processor licensing. One OCPU corresponds to one physical core, presented as two vCPU threads. For Oracle programs licensed on the processor metric, OCI's documented rule counts two vCPUs as a single OCPU for licensing purposes, so the licensable processor count maps to the OCPUs of the shape rather than to the raw vCPU thread count. An eight OCPU shape therefore generally requires processor licensing for eight cores, before any applicable core factor adjustment is applied to the database layer.

The clarity of the OCPU model is itself a benefit. Because the shape defines the OCPU count and the OCPU count defines the licensable cores, there is little ambiguity about the footprint, unlike the contested boundaries of on premise virtualisation. Scaling becomes a licensing decision you make explicitly: adding OCPUs adds cores in scope, so right sizing the shape to genuine workload is the primary cost lever.

The database layer on OCI

EBS on OCI carries its database with it, and the database is licensed separately from the application, on its own metric, exactly as it is on premise. The same Named User Plus versus processor decision applies, the same restricted use grant governs what database use is bundled with EBS, and the same core factor considerations affect the processor count. Running on OCI does not change which metric governs the database; it changes only the infrastructure the metric is measured against, and the OCPU shape of the database compute is what determines the processor count required.

This is where the two layer structure of EBS, set out in the comparison of Named User Plus and Application User, must be carried onto OCI deliberately. The application licences cover the modules; the database licences cover the database compute; and the restricted use boundary still applies to limit how the bundled database may be used. A customer who reasons that moving to OCI simplifies licensing into a single cloud line is mistaken: the layers remain distinct and must each be reconciled against the OCI footprint.

Support Rewards and the cost offset

One of the genuine commercial advantages of running EBS on OCI is Oracle Support Rewards, a program that returns a rebate against your on premise Oracle support bill in proportion to your OCI consumption. For a bring your own licence EBS estate, this creates a virtuous loop: the OCI compute you consume to run EBS earns rewards that offset the support on the very EBS and database licences you are bringing. At the program's published rates this can materially reduce the net cost of the estate, effectively discounting support through infrastructure spend.

The caveats are real and should be priced in. The program terms change over time, the rebate applies to support rather than to new licence purchases, and the rewards are only worth pursuing if the OCI consumption is genuine workload rather than spend manufactured to chase the rebate. Treated as a deliberate offset within a broader OCI strategy, as developed in the cloud and OCI practice, Support Rewards is a meaningful lever; treated as a reason to over consume, it is a false economy.

The audit boundary on OCI

Running on OCI changes the audit dynamic in a specific way: the footprint is transparent. Oracle operates the infrastructure and can see the shapes and OCPUs in your tenancy, so there is little of the measurement ambiguity that surrounds on premise estates. This is the opposite of the contested boundary that makes EBS on VMware so fraught, where Oracle argues that an entire cluster must be licensed. On OCI the licensable boundary is the shape, cleanly defined, with no all hosts argument available.

Transparency cuts both ways. It removes the disputes that on premise virtualisation invites, but it also means there is nowhere to hide an inaccurate position, because the deployment is visible. This makes an accurate baseline more important on OCI, not less: with the footprint in plain sight, the only defence is to have licensed it correctly. The applications licensing practice reconciles the OCI footprint against entitlement so the transparent deployment matches a documented position.

The buyer side view

OCI is an attractive home for an established EBS estate because it keeps EBS as EBS, lets you bring perpetual licences you have already paid for, defines the licensable footprint cleanly through OCPU shapes, and can offset support cost through Support Rewards. Compared to the on premise virtualisation disputes it sidesteps and the product replacement that a Fusion move entails, OCI is the path that changes the least about your licensing while improving its clarity and economics. The buyer side discipline is to choose bring your own licence for an entitled estate, right size the OCPU shapes to genuine workload, carry the two layer structure onto OCI deliberately, and pursue Support Rewards as a genuine offset.

The defining feature of OCI is transparency, and the right response to transparency is accuracy. There is no ambiguity to exploit and none to fear, provided the footprint is licensed correctly and reconciled to a current baseline. To plan an EBS move to OCI around bring your own licence and Support Rewards, request a consultation.

Autonomous, Base Database and the EBS database choice

Running EBS on OCI raises a database deployment choice that has direct licensing consequences. The EBS database can run on OCI compute as a self managed database under bring your own licence, on Base Database Service, or on Exadata, and the model differs across them. Under bring your own licence on plain compute, you carry your existing database entitlement and license the OCPUs of the database instance. On the managed services the relationship between the service subscription and your underlying licence needs to be confirmed, because some OCI database services bundle the licence into the service price while others expect you to bring it.

EBS itself constrains the choice. Oracle's certified configurations for EBS on OCI define which database deployment options are supported, and Autonomous Database in particular has historically not been a certified target for the EBS database because EBS expects a level of database control that the autonomous model abstracts away. The practical position for most EBS estates is a bring your own licence database on OCI compute or Base Database Service, which keeps the familiar Named User Plus or processor metric and the restricted use grant intact, simply measured against the OCI footprint.

The decision should be made on the combination of certification, control, and cost. A bring your own licence model preserves the value of existing perpetual database entitlement and keeps the metric you already understand; a licence included managed service can simplify operations but may mean paying for database rights you already own. Modelling the two against the existing entitlement, rather than defaulting to the managed service because it is the cloud native option, is the buyer side discipline, and it connects to the broader OCI licensing strategy.

Disaster recovery and non production on OCI

Non production and disaster recovery environments are where OCI deployments quietly accumulate licence cost, because the same OCPU counting that governs production applies to them unless a specific exception is in play. A full scale test, development, and disaster recovery estate replicated on OCI can require as much licensing as production if each environment runs licensed cores continuously. The OCI model's clarity helps here too: because each environment's OCPU footprint is explicit, the cost of each non production environment is visible and can be managed deliberately.

The OCI advantage for non production is the ability to scale environments down or stop them when idle, reducing the OCPUs in scope and therefore the licensing, in a way that fixed on premise hardware does not allow. A development environment that runs eight OCPUs during the working day and is stopped overnight and at weekends carries a fraction of the exposure of an always on server. Exploiting this requires treating non production licensing as an active management discipline rather than a fixed cost, and it is one of the genuine economic reasons an EBS estate benefits from OCI's elasticity, provided the disaster recovery failover terms are confirmed against the contract rather than assumed.