Buyer Side Briefing

Fusion Cloud Applications licensing

Fusion Cloud Applications licensing is subscription and metric based, so the audit risk shifts from on premises core and option counts to the subscribed metric count and the EBS estate you still run during a migration. The buyer move is to track the hosted user count against what you bought and to decommission the old estate deliberately so you do not pay for both.

How is Fusion Cloud Applications licensed?

Fusion Cloud Applications is licensed by subscription against a defined metric, such as hosted employee or hosted user, billed for each subscription period rather than as a perpetual processor or Named User Plus license. This is a fundamentally different model from on premises E-Business Suite. There is no core factor table, no option to accidentally enable on a server, and no partitioning question, because the infrastructure is Oracle's. What governs compliance is the metric you subscribed to and the count of that metric in your live environment.

That makes the subscription order the document to read. Hosted user and hosted employee metrics are defined precisely in the ordering documents, and the definitions decide who is counted. A subscription sized to a headcount that has since grown, or a metric that counts a wider population than expected, is the Fusion equivalent of an on premises shortfall. The discipline is to know exactly which metric each module is sold under, and to reconcile the live count against the subscribed quantity on a regular basis rather than waiting for Oracle to do it.

Is there audit risk with Fusion SaaS?

There is audit risk with Fusion software as a service, but it shifts in character: it moves from on premises core and option counts to the subscribed metric count and to the on premises estate you keep running alongside Fusion. Oracle does not need to run collection scripts against its own hosted environment to see usage, because the usage data lives in the platform. The compliance question becomes whether the live metric count exceeds the subscribed quantity, which is a reconciliation exercise rather than a discovery one.

The larger and less obvious risk sits in the transition. Organisations rarely move from EBS to Fusion overnight, and during a multi year migration both estates run. The on premises EBS environment, its database and its options remain fully licensable for as long as they operate, so a buyer who has begun paying Fusion subscriptions can also still be carrying the full on premises liability. An audit that lands mid migration can find exposure in the old estate even as the new one is compliant, which is why the parallel run has to be managed as a licensing event, not just a technical one.

Indicative Fusion versus EBS positions. Anonymized and contract dependent.
ElementLicensing basisBuyer move
Fusion moduleHosted metric subscriptionReconcile count to order
EBS during migrationPerpetual, still liveTrack and time the exit
Database under EBSProcessor or NUPDecommission with the app
Options on that databaseSeparately licensableConfirm none stay live

What happens to EBS licenses when you move to Fusion?

EBS licenses do not disappear automatically when you move to Fusion, because E-Business Suite and its underlying database and options remain licensable for as long as they run. A perpetual EBS license is an asset the buyer continues to hold, but the support stream attached to it continues too, and the database beneath EBS keeps consuming processor or Named User Plus licenses until it is genuinely switched off. Moving the business process to Fusion does not, by itself, end the on premises liability.

This is where deliberate decommissioning earns its keep. A parallel run during migration is necessary and reasonable, but it has to be time bounded and documented, with a clear plan to shut down the EBS environment, its database and any options once the Fusion cutover is complete. Support on the retired estate should be addressed knowingly rather than renewed by default, because matching service level rules constrain how an Oracle support agreement can be partially reduced. Treating the EBS exit as a managed project, rather than an afterthought, is what prevents a buyer from paying for both estates indefinitely. If a migration is underway and you want the licensing position planned around it, a strategy call is the place to start.

The next step

This article is part of our EBS and Applications cluster. Read the pillar, the Oracle license compliance guide, for the full picture, and these related reads: on premises apps versus Fusion SaaS, and decommissioning modules properly.

FAQ

Questions buyers ask first.

Fusion Cloud Applications is licensed by subscription against a defined metric such as hosted employee or hosted user, billed per period. The metric you subscribed to, and the count against it, are the terms that govern compliance.
Yes, but it shifts. The risk moves from on premises core and option counts to the subscribed metric count, and to the on premises EBS estate you keep running during and after a migration to Fusion.
They do not disappear automatically. EBS and its underlying database and options remain licensable while they run, so a parallel run during migration must be tracked and decommissioned deliberately to avoid paying for both.
The License Position

Read Oracle's next move before they make it.

A short weekly note on Oracle audits, Java, ULAs and negotiation, written for the buyer. One development, why it matters, and one move you can make this week.

No spam. Unsubscribe anytime.