Oracle E Business Suite in the Cloud. The licensing that follows.

Moving Oracle E Business Suite to OCI, AWS, or Azure does not reset, reduce, or reprice the application license. The user and module metrics are host independent, so they follow the workload to any data center, including someone else's.

What changes is the technology stack underneath. The database and middleware convert to cloud counting rules, and each cloud converts differently. That conversion, not the application layer, decides what the move costs.

This guide covers the counting change per cloud, BYOL for the full EBS stack, the Exadata options, and what the move does to audit exposure. Read it with the Oracle Database licensing guide.

Does moving EBS to the cloud change the license?

No. The move rehosts servers, and Oracle application licenses do not care where servers are. Your ordering documents, metrics, and minimums govern on OCI, AWS, and Azure exactly as they did in your data center. See the Oracle E Business Suite product pages.

What travels and what converts

• Travels unchanged. Application User counts, module entitlements, Employee based metrics, and legacy metrics on old paper.
• Converts. Processor and Named User Plus licenses for the database and middleware tier, under rules that differ per cloud.
• Opens. The one window in a decade when retiring an unused Oracle license is operationally easy.

Which document governs, the contract or the cloud policy?

The contract governs your rights; the counting rules live in a policy Oracle publishes beside it. The cloud licensing policy defines how AWS and Azure vCPUs map to processor licenses, and it sits outside your agreement.

Oracle rewrote that policy in January 2017 and roughly doubled the licenses required in authorized clouds overnight. Nothing prevents a repeat. If the cloud business case depends on the conversion rate, ask for the rate in writing in the ordering document.

Which clouds does the policy actually cover?

Amazon Web Services and Microsoft Azure, which Oracle calls authorized cloud environments. OCI runs under Oracle's own BYOL terms instead. A cloud the policy does not name has no special counting rule at all, which pushes those conversations into negotiated territory before anything moves.

Treat the policy as a pricing input, not an entitlement. It tells you what Oracle will likely accept without a fight, and what a fight would be about.

What happens to the EBS application licenses on cloud IaaS?

They come along untouched, including their defects. An understated user count is just as understated on OCI, and a module you never deployed still accrues support. The per module metrics are cataloged in the EBS application module reference, so this page will not repeat them.

The counts Oracle will test after the move

• Authorized users, not active ones. The metric counts everyone provisioned to use a module. Deprovision before the migration snapshot, not after it.
• Every module separately. One person working in Financials and Purchasing consumes two licenses on most modern paper.
• Legacy paper on its own definitions. Concurrent and Professional User estates are a different problem, covered in the EBS legacy metrics guide.

Does the restricted use stack that ships with EBS move too?

Yes, with its boundaries intact. EBS application licenses include restricted use rights for parts of the technology stack, solely to run EBS. On release 12.2 the application tier runs WebLogic Server under such a grant, and the bundled database right excludes options, packs, and non EBS data.

If middleware is licensed separately, the move is the moment to test whether you still need it. Start with the WebLogic cloud licensing guide and the hidden Java SE coupling analysis before rehosting the app tier as is.

Who owns the middleware decision in the project?

Usually nobody, which is why it goes wrong. The EBS team treats the app tier as part of the suite, the middleware team treats it as EBS property, and separately licensed WebLogic or SOA rides along unexamined. The CFO view of that cost is in the middleware migration business case.

How does each cloud count the database under EBS?

AWS and Azure consume one processor license per two vCPUs when hyperthreading is enabled, and one per vCPU when it is not. On OCI x86 shapes, one processor license covers two OCPUs, which is four vCPUs. The core factor table applies in none of them.

The conversion rule per target

• AWS and Azure. License the vCPUs of every instance running Oracle programs, per the policy document. Dedicated hosts and default tenancy count the same way.
• OCI. Oracle's BYOL terms for Oracle Cloud effectively carry the on premises core factor into the cloud, so each license covers twice the compute the hyperscalers grant.
• Options meter identically everywhere. Partitioning, the management packs, and Advanced Compression require the same counts as the database they run on.

A worked example: the same 32 cores on three targets

Take an EBS database tier on 32 Intel cores on premises, hyperthreaded, fully covered by 16 Enterprise Edition processor licenses.

• OCI. 16 licenses cover 32 OCPUs, presenting 64 vCPUs. The tier rehosts at equivalent compute with nothing to buy.
• AWS or Azure. 16 licenses cover 32 vCPUs. Matching the on premises thread count of 64 vCPUs needs 32 licenses, a 16 license gap.
• The gap at list. At 47,500 dollars per Enterprise Edition processor on the technology price list, those 16 licenses are 760,000 dollars before options, support, or negotiation.

The right answer is rarely buying the gap. It is sizing cloud shapes to measured steady state need, which usually sits well below the on premises thread count that was itself sized for peak.

Do Named User Plus minimums follow the converted count?

Yes. Enterprise Edition requires 25 Named User Plus per processor, applied to whatever processor count the conversion produces. A production EBS user base clears the minimum easily, but development and test instances licensed by NUP need the arithmetic rerun after conversion.

What does BYOL actually require for the EBS stack?

Less than the acronym suggests, and more than most project plans check. On IaaS, BYOL simply means running your perpetual licenses on cloud infrastructure under the counting rules above. On OCI platform services it is a pricing election that cuts the subscription rate because you bring the license.

Three checks before you claim BYOL

• Support must be active. BYOL rates and update rights assume current support on every license you bring. Lapsed lines need reinstatement or repurchase first.
• The metric must convert. Processor and Named User Plus map cleanly. Ancient technology metrics on old paper may need a migration before any cloud math works, and that migration is a commercial event.
• The paper must permit it. Check territory clauses and the licensed entity list before deploying into a region or subsidiary your ordering document never contemplated.

What if the database under EBS sits inside a ULA?

Then the certification clause decides everything. Many recent ULAs count authorized cloud deployments toward certification, often averaged over the final year; older agreements are silent, and Oracle reads silence as exclusion.

Certifying while the EBS database tier runs in AWS can strand that deployment outside the certified count. Read the clause before the move, and sequence the migration around the certification date, not after it.

What happens to the support bill during the move?

It doubles up before it goes down. During parallel running you pay support on the source licenses and subscription on the target, so compress the overlap deliberately.

Afterward, terminating support on licenses the move stranded is where Oracle's repricing rules bite: dropping part of a license set can reprice the support that remains. Model the termination with the renewal calendar in front of you, and treat it as a negotiation, not an administrative step.

When is Exadata or Cloud@Customer the right landing zone?

When the database tier is large, options heavy, or forbidden to leave the building. Exadata Database Service on OCI and Exadata Cloud@Customer share one commercial model: a subscription that is either license included or BYOL against licenses you already own.

License included or BYOL on the Exadata services?

• License included. The subscription carries the database license. The licenses you stop using become a support termination conversation at the next renewal, which is a negotiation in its own right.
• BYOL. A materially lower subscription rate. You keep paying support on what you bring, and every option you enable must be separately owned.
• Check what the service bundles. Some OCI database services include packs and features that cost extra on premises. Read the service description before renewing support on options a subscription already covers.

Cloud@Customer for the estate that cannot leave

ExaCC delivers the same OCPU metering on hardware inside your data center, for residency, latency, or regulatory constraints. Its minimum configurations are sized for serious workloads, so a small EBS database rarely justifies the platform.

Two commercial notes. OCI consumption earns Oracle Support Rewards, which offset technology support bills at a published rate. And an ExaCC commitment is large enough to reopen the whole Oracle relationship, which is exactly how the EBS negotiation playbook treats it.

White Paper · Oracle EBS

Oracle E Business Suite Licensing

The EBS metrics and negotiation levers. Read it free.

Read the white paper

What does the move do to audit exposure?

It changes the shape of the exposure more than the size. Some long running arguments end at cutover, and a new set of countable facts gets created. Estates that plan for both come out ahead of estates that plan for neither.

Exposure that ends at cutover

• The VMware cluster claim. Oracle's expansive soft partitioning position has no cloud equivalent. Authorized cloud instances are counted per instance.
• Untracked hardware refreshes. Core counts stop drifting upward beneath the licensing radar every refresh cycle.
• Forgotten installs. Old test copies stop appearing in discovery scans, provided decommissioning actually happens.

Exposure that starts at cutover

• Options surface. The rebuild inventories every enabled pack and option. Run that check yourself before Oracle hears about the project, and the findings stay yours to fix.
• The account team notices. A migration RFP, an OCI quote, or a certification support ticket all signal a move. Review letters cluster around moments of change, and the in place drift that letter would find is mapped in the EBS compliance guide.
• Elasticity cuts both ways. Autoscaling that adds vCPUs adds license requirements in real time. Cap the shapes at licensed limits and alert on changes.

How do you keep the historical period defensible?

Freeze the evidence before decommissioning. An audit that arrives a year after cutover will still ask about the source estate, and the servers that could answer will be gone.

• Archive the final state. Core counts, virtualization topology, option usage output, and user extracts from the last day of production.
• Date the decommissioning. A signed record of when each source environment stopped serving users bounds the exposure window.
• Keep the migration runbook. It proves what moved where and when, which is precisely what a records request will probe.

Where the common advice on EBS cloud migration is wrong

The system integrator pitch is to rehost EBS exactly as it runs today, for speed and low risk. We disagree. In roughly 20 of the 35 EBS migrations Fredrik Filipsson advised across 2024 and 2025, the straight rehost carried shelfware modules, oversized database shapes, and unlicensed options directly into the new estate, then locked them in behind a multi year cloud commitment. The buyer side sequence is the reverse: true up privately, retire what is unused, size the target to measured need, and only then price the move. The rationalized estate typically lands 15 to 30 percent smaller than the source, and every point compounds through cloud spend and support for years.

What should a buyer do next?

1. Inventory entitlements and deployment in one pass: modules, users, database, middleware, options.
2. Run the option and pack check on every EBS database before any RFP goes out.
3. Retire unused modules and end date departed users, then reflect it at the next support renewal.
4. Model all three targets with the conversion math above, sized to steady state, not peak.
5. Price license included against BYOL for the database tier, including Support Rewards.
6. If the business case depends on a counting rule, ask for that rule in the ordering document.
7. Time the move against the support calendar and the EBS commercial negotiation.
8. Benchmark the resulting deal through the benchmarking practice before signature.
9. Archive the source estate evidence on the last day of production and file it with the contract record.

Frequently asked questions

Does moving Oracle EBS to the cloud reduce the license bill?

Not by itself. The application metrics transfer unchanged, so savings come from retiring unused modules and users during the move, not from the move. The database line can fall or double depending on target and sizing.

How does Oracle license the EBS database on AWS and Azure?

By counting vCPUs under the cloud licensing policy. Two vCPUs consume one processor license where hyperthreading is enabled, one vCPU per license where it is not, and the core factor table does not apply.

Why does OCI need fewer database licenses than AWS for the same estate?

Because Oracle's BYOL terms count one processor license as two OCPUs, which is four vCPUs of x86 compute. The identical license covers half that on AWS or Azure, so the same shape needs twice the licenses there.

Is the cloud licensing policy part of my Oracle contract?

No. It is a policy document Oracle can change without your consent, as it did in January 2017. If the cloud business case depends on the conversion rate, negotiate the rate into the ordering document.

Do EBS database options and packs need licenses in the cloud?

Yes, on the same converted counts as the database itself, unless the cloud service bundles them. Check the OCI service descriptions before paying support on options a subscription would include.

Can we use existing database licenses on Exadata Cloud@Customer?

Yes, through BYOL, which prices the subscription materially below license included. You continue paying support on the licenses you bring, and every enabled option must be separately entitled.

Do Named User Plus minimums apply on cloud vCPUs?

Yes. The 25 Named User Plus per processor minimum for Enterprise Edition applies to the converted processor count. It matters most on NUP licensed development and test instances.

Does moving EBS off VMware end the cluster licensing argument?

Prospectively, yes. Cloud instances are counted per instance, so the contested claim over clusters and vCenters has no equivalent after cutover. The historical period before the move remains auditable.

How does Redress engage on EBS cloud moves?

Redress runs EBS cloud licensing work inside Vendor Shield, the Renewal Program, and the Benchmark Program, buyer side only, with no reseller or implementation interest.

Continue with the Oracle services overview and the Oracle knowledge hub, or contact us to scope a pre move license review.