Oracle BI On-Premise Licensing: The Options That Drive the Bill

Legacy OBIEE and BI Suite EE Plus estates carry the highest audit exposure per license dollar in the Oracle catalog, and the end-of-support squeeze is forcing decisions right now. This guide shows where the cost, the risk, and your leverage actually sit.

If you are running Oracle Business Intelligence on-premise, you own one of the most audit-prone and least-understood estates in Oracle's catalog. The products are old, the entitlements are frequently misread, the option packs ship silently in the installer, and the support runway just closed. In 25 years of negotiating with Oracle on the buyer side, I have watched BI estates that cost a few hundred thousand dollars at purchase generate audit claims in the seven figures, almost always for the same reasons. This guide covers the legacy and on-premise Oracle BI stack specifically: Oracle Business Intelligence Enterprise Edition (OBIEE), Business Intelligence Suite Enterprise Edition Plus (BI Suite EE Plus), BI Foundation Suite, and BI Publisher. It is deliberately distinct from Oracle Analytics Cloud and Oracle Analytics Server, which we cover elsewhere.

The through-line is this: your license entitlement was set once, often years ago, and the software has been quietly accumulating exposure ever since. Every enabled option, every added user, every VMware migration, and every silent installer checkbox has moved your actual usage away from what you paid for. Meanwhile OBIEE 12c Extended Support ended in August 2025, so Oracle now has both a compliance lever and a migration pitch pointed at the same estate. You need to know exactly what you own, where the gaps are, and what your alternatives cost before Oracle frames the conversation for you.

The Two Metrics That Set the Entire Bill: Named User Plus vs Processor

OBIEE and BI Suite EE Plus are licensed under two primary metrics: Named User Plus (NUP) and Processor. The choice between them is the single most consequential cost decision in the whole estate, and getting it wrong in either direction costs real money. Named User Plus counts individuals (and non-human operated devices) authorized to access the software, regardless of whether they are actively using it at any moment. Processor licensing counts physical cores on the servers running the BI software, multiplied by the applicable core factor from Oracle's Core Factor Table.

Two rules shape the NUP side. First, Oracle enforces a minimum of 10 Named User Plus licenses per processor. That minimum is a floor, not a suggestion, and it means a small user population on a large server can still trigger a substantial license count. Second, NUP counts every authorized user, including those reaching the system through portals or embedded dashboards. We treat the correct metric selection as a project in its own right in our breakdown of OBIEE Named User Plus versus Processor at your scale, because the breakeven is not intuitive.

The rule of thumb from our engagements: roughly 50 NUP licenses equal the cost of one Processor license once you account for the core factor. Below that user density per processor, NUP tends to be cheaper. Above it, Processor becomes more economical and removes the burden of counting and certifying every named individual. For an internal, stable, departmental deployment with a known headcount, NUP is usually correct. For a broadly deployed or externally facing system where you cannot bound the user population, Processor is the defensible choice.

Roughly 50 Named User Plus licenses equal one Processor license. Everything about your metric decision hinges on where your user density sits relative to that line.

How Processor Counting Actually Works (and Where the Core Factor Bites)

Processor licensing is where technical architecture becomes a financial event. Oracle does not license per socket or per server. It licenses every physical core on the machine running the BI software, then applies a multiplier from the Core Factor Table. For most Intel and AMD x86 processors the core factor is 0.5. So an 8-core Intel server running OBIEE requires 8 multiplied by 0.5, which equals 4 Processor licenses. On other chip families the factor differs, and on some it is 1.0, which doubles your requirement relative to the x86 assumption most buyers carry in their heads.

The trap is that the core factor applies to the cores where the software runs, and Oracle's definition of where the software runs is aggressive. This is the doorway to the virtualization problem, which we treat as its own section below because it is the largest single source of BI audit exposure we see. For now, understand that Processor counting is not a snapshot of your intended deployment. It is a count of every physical core Oracle can argue the software could run on, and that argument is where the money is made or lost.

BI Publisher: The Exception to Almost Every Rule

Oracle BI Publisher (now Oracle Analytics Publisher) behaves differently from the rest of the stack, and those differences are worth money if you use them deliberately. First, Publisher has no minimum NUP requirement. Where the rest of the BI products impose 10 NUP per processor, a standalone full-use Publisher license lets you buy exactly the users you have. If you have five reporting users, you can license five NUP. That is genuinely unusual in the Oracle catalog and it makes Publisher a viable low-cost option for narrow, report-only footprints.

Second, a standalone Publisher license includes a restricted-use WebLogic Server to run it. You do not have to separately license WebLogic, provided that WebLogic instance is used only for Publisher. The moment you extend that WebLogic environment to run anything else, the restricted-use grant evaporates and you owe full WebLogic licensing. This is a classic slow-drift compliance gap: someone deploys another application onto the convenient, already-running WebLogic instance, and years later an audit finds it.

Third, Publisher is embedded inside many Oracle applications, and the embedded-use rights are narrow and specific. Using an application-embedded Publisher to build reports beyond the embedding application's scope is a common and expensive finding. We separate the standalone, bundled, and embedded cases in our Oracle BI Publisher licensing breakdown, because buyers routinely assume the Publisher they see is the Publisher they own, and it usually is not.

On list pricing for reference (September 2017 Oracle price list), standalone Publisher was $49,680 per Processor with $10,929.60 annual support, or $497 per Named User Plus with $109.34 support. Those are the numbers Oracle anchors from in a true-up, so know them before the conversation starts.

The Suite Bundles and the Option Packs Hiding Inside Them

Here is where most BI audit findings originate. Oracle's BI suites bundle multiple products, and Oracle's installer ships options you may not have licensed. The two suites that matter are BI Suite Enterprise Edition Plus and BI Foundation Suite. BI Foundation Suite is the fuller package Oracle pushes to new customers, and it bundles OBIEE Enterprise Edition, BI Publisher, Essbase, Scorecard and Strategy Management, and Essbase Analytics Link. BI Suite EE Plus is the more granular base.

The critical fact: Essbase is NOT included in the base OBIEE Plus license. It is included in BI Foundation Suite. But the OBIEE product installer offers Essbase as an installation option alongside OBIEE, Real-Time Decisions, and BI Publisher. So a technical team installing OBIEE Plus can check a box, deploy Essbase, and create instant exposure for a product the organization never bought. Oracle's audit scripts find enabled options regardless of intent, and intent is not a defense in the license grant.

Scorecard and Strategy Management carries the same risk with a worse twist. Oracle's own documentation states that if your organization licensed Scorecard and Strategy Management and you have the appropriate privileges, you can use the functionality as part of a default installation with no additional configuration. Read that from the buyer side: the functionality is on by default whenever the privileges exist, so usage without a license is trivially easy and hard to prevent. If you licensed by NUP, Scorecard imposes a minimum of 20 NUP per customer, and its prerequisites are BI Foundation Suite or BI Suite EE Plus (or the Oracle Applications editions) plus Essbase or Hyperion Planning entitlements.

We map every bundled option and how it surfaces under audit conditions in our guide to the BI Suite EE Plus option packs. The pattern mirrors the well-known Oracle Database options and packs accidental-use trap: separately licensed capability that ships enabled or one click away, then becomes the largest line in the audit finding.

Essbase and Scorecard are not in your base OBIEE Plus license, but both ship in the installer or switch on by default. Enabled equals owed. Intent is not a defense.

The Single Bundled Admin License That Buyers Misread

A precise but frequently missed detail: Oracle Fusion Middleware licensing documentation states that one Named User Plus license to Oracle Business Intelligence Server Administrator is included with each license to BI Server EE, BI Suite Extended Edition, and BI Suite Foundation Edition. That grant provides the minimum functionality to configure and administer metadata. The word to weight is one. It is one included admin license per underlying suite license, intended for a single administrator to configure the environment. It is not one admin seat per NUP, and it is not one per Processor.

The exposure appears when multiple administrators operate the repository under that single included entitlement, or when organizations assume the admin capability scales with their user count. BI Server Administrator was listed at $6,264 per Named User Plus in the 2017 price list, so each unlicensed administrator beyond the single included seat is a discrete, quantifiable finding. Count your named administrators, confirm the single-license grant, and license the delta before Oracle does it for you.

The 'Plus / Upgrade Only' Trap: You Cannot Add EE, Only EE Plus

Oracle's BI documentation contains a rule that catches customers who have owned OBIEE for years. Existing Oracle Business Intelligence Suite Enterprise Edition customers may not license incremental users or processors of the base BI Suite. They must purchase BI Suite Enterprise Edition Plus users or processors instead. In plain terms, the base EE product is closed to expansion. Any growth forces you onto the Plus tier, which is a different and more expensive line item.

This matters in two situations. First, when you add users or capacity and assume you are extending your existing EE contract, you are not. You are opening a new EE Plus purchase, and the pricing and support base recalculate accordingly. Second, in an audit, Oracle will treat any incremental usage on a base EE deployment as an EE Plus obligation, priced at the Plus tier. Buyers who negotiated favorable EE terms years ago lose that advantage the moment they grow, so plan expansions with the Plus pricing in front of you, not the EE pricing you remember.

The Restricted-Use Database Nobody Accounts For

Under most OBIEE deployments sits an Oracle Database, typically hosting the repository, the scheduler tables (the BI Platform schema), and the Repository Creation Utility (RCU) output. Some of this runs under restricted-use rights bundled with the BI license, and some does not. The boundary between restricted-use and full-use is where audit findings appear, because the restricted-use grant covers only the specific supporting schemas that the BI stack requires, not general-purpose use of the same database instance.

The failure mode is predictable. A DBA sees an Oracle Database already running to support OBIEE and uses it for something else: a data mart, an application schema, an ETL staging area. That additional use falls outside the restricted-use grant and requires full Database licensing, often with expensive options attached. We cover exactly which schemas are covered and which are not in our analysis of the restricted-use Oracle Database under the OBIEE stack. Audit your database use against the BI restricted-use terms specifically, because Oracle's database audit and Oracle's BI audit find different things and both bills land.

Virtualization: The Single Largest Audit Exposure in a BI Estate

If your OBIEE or BI Suite EE Plus runs on VMware, this is the section that determines your risk. Oracle classifies VMware as soft partitioning, which means Oracle does not accept it as a boundary for limiting license counts. Oracle's position is that Processor licensing must cover all physical cores where the software could run, and in a VMware cluster (particularly with vMotion, DRS, or shared storage) Oracle argues the software could run across every host in the cluster, and in some versions of the argument across every cluster that shares storage.

The financial consequence is severe. A BI instance intended to consume 4 Processor licenses on a small VM can, under Oracle's soft-partitioning interpretation, generate a claim for every physical core in the entire vSphere estate it touches. We have seen this single argument multiply a BI license requirement by ten or more. The Core Factor Table then applies on top, so the multiplication compounds. This is not a theoretical risk; it is the most common way a modest BI deployment becomes a major audit finding. The same logic governs public cloud placement, which we address in our Oracle on Azure BYOL analysis.

Your defenses are architectural and contractual. Isolate Oracle BI workloads onto dedicated hardware or into a properly separated cluster, document the boundary, and control vMotion scope. Where isolation is impractical, understand that your negotiating position depends on getting ahead of the finding rather than reacting to it. We cover the broader response discipline in our Oracle licensing optimization playbook, and the virtualization principles carry directly across from database to BI.

Counting External and Anonymous Users: The NUP Estate You Forgot

Named User Plus counts every authorized individual, and OBIEE deployments that feed partner portals, customer dashboards, or public-facing analytics create a counting problem most buyers have never resolved. If external partners or customers access BI content, they are users, and under NUP they must be licensed. Anonymous access complicates it further, because Oracle's definition of an authorized user does not vanish simply because you did not assign a named account.

The practical exposure is that a deployment sized for 200 internal analysts may actually serve thousands of external users through embedded dashboards, and the NUP count Oracle asserts reflects the larger population. This is a frequent reason to reconsider the metric decision entirely, because Processor licensing removes the external-user counting problem at the cost of a larger fixed license base. We work through the specific counting rules, including anonymous and pooled access, in our guide to counting external and anonymous users in OBIEE portals. If your BI reaches beyond your employees, treat this as a priority review, not a footnote.

The End-of-Life Squeeze: Support Just Closed on OBIEE 12c

The timing pressure is real and specific. OBIEE 11g came out of Premier Support at the end of 2018. OBIEE 12c came out of Premier Support in 2025, and critically, OBIEE 12c Extended Support ended in August 2025 with no 14c release. There is no next version of OBIEE. The product line ends at 12c, and Extended Support for it has now closed.

A common misreading needs correcting: OBIEE does not ride the longer Fusion Middleware 12c support runway. The broader FMW 12c release (12.2.1.4) has its own Premier and Extended Support dates running further out, but OBIEE specifically does not follow that runway. Its Extended Support already closed in August 2025, independent of where the rest of the 12c stack sits. If your team assumed OBIEE inherited the FMW dates, that assumption is wrong and your estate is already in Sustaining Support.

Sustaining Support in operational terms means Oracle will generally still take a support call, but there are no more bug fixes, no new certifications against newer database or operating system versions, and no security patches for newly discovered vulnerabilities. Running OBIEE past Extended Support is a live operational and security risk, and it is also a negotiating vulnerability: Oracle knows you cannot patch, so it holds leverage in any renewal or migration discussion.

OBIEE ends at 12c. Extended Support closed in August 2025 with no 14c. If your team thought OBIEE inherited the longer Fusion Middleware runway, it does not, and you are already in Sustaining Support.

Your Migration Options and What Each One Actually Costs

You have three paths, and Oracle will only volunteer one of them. The first is Oracle Analytics Server (OAS), the on-premise successor to OBIEE. The single most important and most overlooked fact here: active OBIEE support generally carries the right to run OAS under the same entitlement. If your OBIEE support is current, you likely already have the right to deploy OAS without buying anything new. The most common error we see is buyers purchasing net-new OAS licenses for software they were already entitled to run. Before you accept any OAS quote, confirm whether your existing OBIEE entitlement already covers it.

The second path is Oracle Analytics Cloud (OAC), which we cover in dedicated pages. Moving to cloud does not reset your licensing math in your favor by default, and Oracle's cloud pitch to a stranded OBIEE estate should be read as leverage, not rescue. The third path is leaving Oracle BI entirely for a competing platform, which becomes economically rational precisely when the OBIEE estate is stranded on Sustaining Support and Oracle is pushing an expensive cloud migration. We quantify all three routes in our OBIEE end-of-life migration cost comparison.

There is a fourth option that changes the negotiation entirely: third-party support. Moving OBIEE onto a third-party support provider stops paying Oracle's 22 percent annual support fee while keeping the software running, and it removes Oracle's ability to bundle a support renewal with a migration mandate. The trade-off is losing Oracle's right to future patches (which for a product line ending at 12c is a smaller loss than usual). We work through the decision in our buyer-side analysis of OBIEE on third-party support. For an end-of-life product with no successor version, the case for third-party support is stronger than for almost any other Oracle product.

Where the Money Sits: List Prices to Anchor Your Negotiation

Know Oracle's list prices, because they are the anchor for every true-up and every migration quote. From the September 2017 Oracle price list: BI Suite Enterprise Edition Plus was $238,950 per Processor with $52,569 annual support. BI Foundation Suite was $324,000 per Processor ($71,280 support) or $3,969 per Named User Plus ($873.18 support). Historically, Oracle cut BI Suite EE Plus from $295,000 to $221,250, and Scorecard and Strategy Management from $149,250 to $89,550, so the pricing has moved and your reference point should be current, not whatever appeared on a decade-old quote.

For NUP benchmarking, an OBIEE or OAS Named User Plus prices at around $950 per user at list in recent guidance. Multiply by your true authorized user count (including external and portal users) and compare against the Processor calculation at your core count times core factor. That comparison, done honestly with your real usage, is the foundation of both your compliance position and your negotiation. Support runs at Oracle's standard 22 percent of net license fees annually, which is the recurring cost that third-party support targets.

What to Do Now: A Buyer-Side Action Sequence

Do these in order, before any conversation with Oracle. First, pull your entitlements and confirm exactly what you own: which suite, which metric, how many, and whether your OBIEE support covers OAS. Second, run a full deployment inventory against the installer options, specifically checking whether Essbase, Real-Time Decisions, Scorecard and Strategy Management, or BI Publisher are enabled beyond what you licensed. Enabled equals owed, so find these before Oracle does.

Third, map your virtualization boundary. If OBIEE runs on VMware, determine precisely which physical cores Oracle can argue the software could run on, and decide whether to isolate the workload before an audit fixes the boundary against you. Fourth, count your real user population including external, portal, and anonymous access, and rerun the NUP versus Processor comparison against current list prices. Fifth, confirm the restricted-use database boundary and check that no additional workloads have crept onto the supporting Oracle Database.

Sixth, treat the EOL squeeze as a decision, not a deadline someone else sets. Decide whether OAS (likely already entitled), a platform exit, or third-party support serves you best, and price all three before Oracle frames the migration for you. If an audit letter arrives during this process, remember that the audit claim is an opening position and not a verdict. Our guides on challenging Oracle audit findings and the 22 Oracle license audit secrets every CIO should know apply directly to BI, where the findings are often built on the soft-partitioning and enabled-option arguments this guide exposes. The estate is old and the leverage is real, but only if you know your position before you sit down.

Related reading: OBIEE Named User Plus vs Processor: Which BI Metric Costs Less at Your Scale.

Frequently asked questions

Is Essbase included in my OBIEE or BI Suite EE Plus license?

No. Essbase is not included in the base OBIEE Plus license. It is included only in BI Foundation Suite. However, the OBIEE installer offers Essbase as an installation option, so a technical team can deploy it without a license and create audit exposure. Check whether Essbase is enabled in your environment, because enabled equals owed.

What is the 10 NUP per processor minimum for OBIEE?

Oracle requires a minimum of 10 Named User Plus licenses for every processor running OBIEE or BI Suite EE Plus. Even with a small user population on a large server, you must license at least 10 NUP per processor. BI Publisher is the notable exception, with no minimum NUP requirement for a standalone full-use license.

Has OBIEE reached end of life?

Yes. OBIEE 12c Extended Support ended in August 2025 with no 14c release, so the product line ends at 12c. OBIEE does not ride the longer Fusion Middleware 12c support runway. Your estate is now in Sustaining Support, meaning no bug fixes, no new certifications, and no security patches for newly discovered vulnerabilities.

Do I need to buy new licenses to move from OBIEE to Oracle Analytics Server?

Usually not. Active OBIEE support generally carries the right to run Oracle Analytics Server under the same entitlement. The most common and expensive error is buying net-new OAS licenses for software you already own the right to run. Confirm your existing OBIEE entitlement before accepting any OAS quote from Oracle.

Why is VMware a problem for OBIEE licensing?

Oracle classifies VMware as soft partitioning and does not accept it as a boundary for limiting Processor license counts. Oracle argues the software could run across every physical core in the cluster, or across clusters sharing storage. This can multiply a modest BI license requirement many times over, making it the single largest audit exposure in most BI estates.

How many administrator licenses come with BI Suite EE Plus?

One. Oracle includes a single Named User Plus license to BI Server Administrator with each BI Server EE, BI Suite Extended Edition, or BI Suite Foundation Edition license. It is one included admin seat, not one per NUP or per Processor. Additional administrators require additional licenses, historically listed at $6,264 per NUP.