This guide focuses on Oracle legacy license metrics. These are older licensing metrics that many companies still use today. While discontinued, these Oracle license metrics continue to influence the procedures organizations use to track software usage and audit preparedness.

What Are Oracle Legacy License Metrics?

Oracle legacy license metrics are licensing metrics that Oracle used before its current standard metrics. These older license metrics, which continue to operate within numerous organizations, have noticeable effects on license compliance, cost optimization, and audit results.

While most modern Oracle customers use the “Processor” and “Named User Plus (NUP)” metrics for Database and Middleware products, many organizations still maintain licenses under older metrics that present unique challenges and opportunities.

Common Oracle Legacy License Metrics

Before modern licensing models, Oracle employed a range of legacy metrics like UPU, Concurrent Device, and NU-SS/MS, each reflecting the technology and usage patterns of their time.

Universal Power Unit (UPU)

UPU metrics were popular in the late 1990s and early 2000s when processor performance was primarily measured by clock speed. This metric calculates licensing requirements based on processor clock speed and architecture type.

The UPU calculation formula followed this structure:

• (Number of processors) × (Processor speed in MHz) × (Architecture scaling factor)

The architecture scaling factor was 1.0 for CISC processors and 1.5 for RISC processors. For example, a server with two 1.5 GHz Xeon processors would require: (2 CPUs) × (1.5 × 1000 MHz) × 1.0 = 3,000 UPUs

As multi-core processors emerged, the calculation evolved to include Oracle’s Core Factor:

• (Number of cores × Core Factor) × (Processor speed in MHz) × (Architecture scaling)

For a quad-CPU Xeon server with 4 cores per CPU running at 2 GHz, this would translate to: (4 CPUs × 4 Cores per CPU) × (0.5 Core Factor) × (2 × 1000 MHz) × 1.0 = 16,000 UPUs

Many organizations choose to keep their UPU licenses even though Oracle introduced the “Processor” metric in 2001. Processor technology advancement has rendered UPUs less effective for their original purpose. The performance capabilities of contemporary server processors increase the requirement for 10 to 20 times more UPUs than previous technology, therefore creating compliance issues.

While Oracle replaced the UPU metric with the “Processor” metric in 2001, many organizations have maintained their UPU licenses. The challenge with UPUs is that they’ve become increasingly inadequate as processor technology has advanced. Modern servers with multiple high-speed, multi-core processors often require 10-20 times more UPUs than legacy systems, creating potential compliance gaps for organizations relying on historical UPU entitlements. Note that generally, Oracle’s conversion ratio for older UPU licenses to the new Processor license metric is 1000UPU : 1 Processor license. However, this is not formally the case and must be negotiated with Oracle.

Concurrent Device (CD)

The Concurrent Device metric, available throughout the 1990s until 2001, is perhaps the most commonly encountered legacy Oracle license metric. CDs reflected the client-server computing model prevalent during that period.

Under this metric, you needed to license the high-water mark of unique devices (both human-operated and non-human) connecting to the Oracle software. For instance, if 200 distinct devices connected to an Oracle Database over a year, but only a maximum of 55 connected simultaneously, then 55 CDs would be required.

Importantly, the CD metric also required counting front-end user populations. If one of those 55 devices in the high-water mark was a computer serving 10 users, those users’ devices would need to be counted too, bringing the total requirement to 65 CDs.

CD compliance has always been challenging to track and verify. There are typically no automated reports for monitoring distinct connecting devices or high-water marks, forcing customers to maintain detailed logs. For web-based systems, CDs become nearly impossible to track without accepting significant compliance risk.

However, in controlled environments like test/dev systems, CDs can still offer good value, and organizations shouldn’t rush to migrate to newer metrics without careful consideration.

Named User Single Server (NU-SS) and Named User Multi Server (NU-MS)

From the late 1990s until 2001, Oracle offered Named User Single Server (NU-SS) and Named User Multi Server (NU-MS) metrics, which eventually evolved into today’s Named User Plus (NUP) metric.

These metrics require licensing for all users and non-human devices connecting to the Oracle software, including front-end populations:

• NU-SS: Authorized a user or device to access the Oracle program on a single server.
• NU-MS: Allowed users or devices to connect to multiple servers without additional licensing.

Both metrics were offered alongside the UPU metric and included UPU-related minimums. For Database Enterprise Edition, this minimum was 30 UPUs per Named User.

Using our earlier example of a dual-CPU Xeon server at 1.5 GHz (requiring 3,000 UPUs), the alternative NU licensing would require: (3,000 UPUs / 30 UPUs per NU) = 100 NU-SS or 100 NU-MS licenses.

Other Legacy Metrics

Oracle’s historical licensing portfolio includes several other legacy metrics that appear less frequently:

• Computer/Server-based metrics: Licensed per physical server
• Session-based metrics: Based on concurrent sessions
• Network Server License: Network-based licensing

These metrics tend to be simpler to manage but are increasingly rare in today’s environments.

Legacy Oracle Applications Metrics

While Database and Middleware products have largely standardized on Processor and Named User Plus metrics, Oracle Applications historically used diverse licensing models:

E-Business Suite

Before the current “Application User” metric, Oracle commonly offered the E-Business Suite 2003 Professional User license. This was gradually replaced by the E-Business Suite Professional User license. While this license metric is not formally offered on Oracle’s E-Business Suite price list, it can still be procured.

These licenses provided access to a combination of E-Business Suite modules and made for a cost-effective way for companies to access a wide range of E-Business Suite modules and features.

Understanding the nuances of E-Business Suite 2003 Professional User license vs E-Business Suite Professional User license is key during an Oracle audit as they provided differing and varying module coverage.

Migrating Legacy Metrics: Strategic Considerations

Oracle’s current primary metrics – Processor and Named User Plus – have been standard for over 15 years. When Oracle introduces new metrics and retires old ones, customers often feel pressured to migrate their existing licenses, particularly when Oracle sales teams push for such transitions.

Oracle has several motivations for encouraging migration:

• Simplifying sales and support operations.
• Addressing situations where legacy metrics provide exceptional value on modern technologies.
• Generating migration revenue.

The migration process typically involves determining conversion ratios (provided by Oracle), calculating the equivalent licenses on the new metric, completing paperwork, and paying migration fees.

However, it’s important to understand that there is usually no contractual requirement to migrate from legacy to new metrics. If an organization purchased Computer licenses in 1992 or CDs in 1999 and remains satisfied with their licensing position, there’s often good reason to resist migration pressure.

Oracle’s migration ratios tend to favor Oracle rather than customers, and while Oracle may not sell additional licenses on legacy metrics, organizations can deploy both old and new metrics simultaneously, as long as they don’t mix metrics on individual servers. For example, a dual-CPU server cannot be partially covered with UPUs and partially with Processor licenses.

That said, certain scenarios do warrant metric migration to maintain compliance:

• CD licenses cannot effectively cover public-facing web applications without significant compliance risk.
• Legacy metrics may not adequately address modern architectural patterns.
• Support limitations may apply to very old metric types, though this may be argued by Oracle, but is contractually unfounded.

Whether considering migration between legacy and current metrics or between different current metrics, organizations should thoroughly assess the cost implications and compliance risks. These migrations are permanent, typically involve fees, and may have long-term support cost implications.

FAQ: Oracle Legacy License Metrics

How Do I Determine If We Have Legacy Oracle Metrics in Our Organization?

Review your Oracle license agreements and order documents carefully. Look for metrics like Universal Power Unit (UPU), Concurrent Device (CD), Named User Single Server (NU-SS), or terms that differ from the current Processor and Named User Plus metrics.

Your Oracle contact can also provide a definitive list of your entitlements, but as always, be careful and wary when asking Oracle for any licensing information. Reviewing your annual Oracle Support renewals is a good start, and finding the corresponding purchase agreements (Oracle Ordering Document) is the next key step.

Should We Migrate Our Legacy Metrics to the Current Oracle License Metrics?

This depends on your specific situation. In many cases, legacy metrics may provide better value, especially for controlled environments like test/dev systems. However, for certain use cases (like web applications), legacy metrics may create compliance risks. In any case, first find a valid technical and business reason to migrate on your own, without Oracle’s “assistance” in this matter.

A complete cost-effectiveness analysis must examine both migration expenses in the short term alongside sustained assistance costs in the long term.

How Does Oracle Audit Compliance for Legacy Metrics Work?

Oracle’s License Management Services (LMS) team typically requests deployment information and relies heavily on customer-provided data for legacy metrics, as automated discovery tools often don’t directly map to legacy licensing models.

Documentation of your deployment and usage patterns becomes crucial for demonstrating compliance under legacy metrics during an Oracle license audit.

Expert Guidance For Oracle License Optimization

Need help with Oracle legacy license metrics? Navigating Oracle’s complex licensing landscape requires specialized expertise to ensure compliance while controlling costs.

Your organization can contact us today to receive a free one-hour consultation about your Oracle licensing situation and create strategies for handling legacy metrics. 

Our team at Redwood Compliance specializes in helping organizations navigate these complexities while optimizing their Oracle investments. Contact us today.