Oracle License Metric Change: How to Switch from Processor to Named User Plus

Processor vs Named User Plus: The Core Distinction

Oracle Database Enterprise Edition is available under two primary license metrics for on-premises and IaaS cloud deployments: Processor and Named User Plus (NUP). The Processor metric licenses every physical core running Oracle, multiplied by the Core Factor Table value for the processor type (0.5 for Intel/AMD, 1.0 for IBM POWER, variable for SPARC). The Named User Plus metric licenses every specific individual who has access to Oracle — plus service accounts and automated processes that connect to the database without a human user driving the connection.

The choice between these metrics is not a once-and-forever decision — it can be changed through a license amendment, typically at contract renewal. The question is whether your specific deployment profile — number of cores, Core Factor, total user population, anticipated growth — makes Processor or NUP the lower-cost metric. Oracle does not proactively suggest the lower-cost option. It is in Oracle's interest for you to remain on whichever metric produces the higher license fee for your current deployment.

For Oracle Database Standard Edition 2, Processor metric is not available — SE2 is licensed by socket (not core), with a maximum of two populated sockets per server and maximum 16 CPU threads per instance. NUP is available for SE2 but the 25 NUP per socket minimum applies in the same way it applies per processor for Enterprise Edition.

The 25 NUP Per Processor Minimum

Oracle requires a minimum of 25 Named User Plus licenses per Processor (per licenced core × Core Factor) for Oracle Database Enterprise Edition. This minimum exists to prevent customers from using a single NUP license on a many-core server and avoiding the economics Oracle intends for processor-intensive deployments.

The 25 NUP per processor minimum means that the NUP metric is only cost-competitive when your actual user population is less than 25 per processor. For a server with 32 Intel cores at 0.5 Core Factor = 16 processors, the NUP minimum is 16 × 25 = 400 NUP. If you have fewer than 400 actual users, NUP may be cheaper than Processor. If you have more than 400 users, Processor is typically cheaper.

When NUP Beats Processor Metric

Named User Plus licensing is more cost-effective than Processor licensing in deployments with a small, clearly enumerable user population relative to the total hardware core count. The classic scenario is an Oracle Database deployed on modern high-core-count hardware (64, 96, or 128 cores) to support a single business application accessed by a defined user base of fewer than 1,000 people.

Consider an Oracle Database EE on a server with 64 Intel cores (Core Factor 0.5 = 32 Processors). At list price of $47,500 per Processor, the Processor license cost is $1.52 million. The NUP minimum is 32 × 25 = 800 NUP at $950 per NUP = $760,000 — a 50% saving even at the minimum NUP quantity. If the actual user population is 300, the NUP minimum still governs at 800 NUP, but if the server had 96 cores (48 Processors), the NUP minimum would be 1,200 NUP and the comparison shifts further toward Processor.

NUP also wins when a database serves a closed user community — an HR system accessed only by HR staff, a financial system with a fixed number of finance users, a regulatory reporting system with a defined license population. These scenarios allow precise user counting, minimal growth risk, and clear audit defense.

When Processor Beats NUP

Processor metric is more cost-effective when the user population is large, uncertain, or growing rapidly. Internet-facing applications where any registered user technically has access to Oracle data, enterprise-wide systems where every employee is a potential user, and middleware layers with many connection pools and automated processes are all poor candidates for NUP licensing.

Processor also wins when the server is relatively low-core-count relative to the user base. An 8-core server with 500 users has a NUP minimum of 200 (4 × 25) but actual users of 500 — requiring 500 NUP at $950 = $475,000 versus 4 Processor licenses at $47,500 = $190,000. The Processor metric is significantly cheaper.

The third scenario where Processor wins is when NUP counting is complex and uncertain. If you cannot definitively count your Named User Plus population — because indirect access through middleware, application servers, or web applications creates additional license obligations — then the complexity and compliance risk of NUP may outweigh its theoretical cost savings.

Step-by-Step Conversion Calculation

A systematic metric conversion calculation follows these steps for each Oracle Database deployment.

Step 1 — Current Processor cost: Count all physical cores on the server (or all cores in the cluster if using hard partitioning). Apply the Core Factor Table multiplier. Multiply by the list price per Processor ($47,500 for Oracle Database EE). Apply your existing discount percentage. Calculate the annual support cost (22% of net license value).

Step 2 — NUP user count: Enumerate all named users who have access to Oracle — human users, service accounts, and automated processes that connect to the database. Include indirect users if middleware or integration layers create database connections on behalf of third-party system users. This is often harder than it appears; the user population for compliance purposes is frequently larger than the active user count visible from application-side monitoring.

Step 3 — Apply the NUP minimum: Calculate the NUP minimum as (number of licenced Processors) × 25. Take the higher of your actual user count or the minimum. This is your required NUP quantity.

Step 4 — NUP cost: Multiply required NUP quantity by $950 per NUP list price. Apply your negotiated discount. Calculate annual support at 22% of net license value.

Step 5 — Compare: The lower total cost (license + support per year) is the preferred metric. Note that a metric change typically involves converting existing licenses to the new metric — Oracle will credit the existing license value against the new metric purchase, so the incremental cost is the net difference.

Indirect Access & NUP Counting Rules

Oracle's definition of a Named User Plus extends beyond direct database users to include anyone who accesses Oracle data indirectly — through a web application, an ERP front-end, a middleware layer, or a data integration process. This indirect access rule is the single greatest source of NUP compliance gaps and the primary reason NUP metric is harder to defend in audit than Processor.

If you run a web application that serves 10,000 customers and that application stores data in Oracle Database, Oracle's position is that each of those 10,000 customers is a Named User Plus requiring a license. The alternative — a Processor-metric license — covers all access regardless of how many users connect. For any externally-facing application with a large or uncounted user base, NUP is almost certainly the wrong metric.

The indirect access question must be answered definitively before committing to a NUP-metric license. A metric conversion that appears to save money based on internal user counts can become more expensive than Processor if Oracle identifies indirect access during an audit or true-up review.

The Metric Change Process with Oracle

Oracle license metric changes are not self-service. They require an amendment to your Oracle Master Agreement or Order Forms, processed through Oracle's license management team and account management. Oracle will require documentation of the proposed user count for a Processor-to-NUP conversion, and may request a license verification process before approving the conversion.

The optimal time to execute a metric conversion is during a contract renewal or expansion negotiation. Oracle is most flexible on contract terms when new revenue is on the table. A metric conversion proposed in isolation, without a renewal or new purchase to accompany it, is harder to move through Oracle's internal approval processes and typically receives less commercial flexibility.

The financial mechanics of conversion require Oracle to credit the existing Processor license value (at the contracted discount percentage) against the NUP licenses being acquired. The net payment is the NUP cost minus the Processor credit. Support cost adjusts to 22% of the new net NUP license value. The conversion should be documented in a new Order Form that clearly states the Processor licenses are being retired and replaced by the specified NUP quantity.

NUP to Processor: The Reverse Conversion

The reverse conversion — from NUP to Processor — is warranted when user populations grow faster than anticipated at the time of the NUP license purchase. An organization that purchased NUP licenses for 200 internal users and has since grown to 800 users may find Processor licensing cheaper at renewal, particularly if the hardware has also scaled and the Processor count has increased proportionally.

NUP to Processor conversion is also driven by compliance risk. As noted above, indirect access rules create NUP counting complexity that grows as applications evolve. An organization that discovers its Oracle NUP license population is significantly larger than originally estimated — due to indirect access, contractor populations, or subsidiary entities — may find Processor metric provides a simpler, more defensible compliance position.

Both conversion directions require the same financial calculation and the same contract amendment process. The starting position is your current license value; the end position is the target metric at your required quantity; the net financial impact is the difference, managed through a credit and amendment process negotiated with Oracle.