Oracle Concurrent Licensing Metrics: Legacy and Current Usage

Oracle Concurrent Licensing Metrics: Legacy and Current Usage

Oracle’s licensing metrics have evolved from legacy “concurrent” usage models to modern user- and processor-based models. Concurrent licensing metrics – which allowed a set number of simultaneous users or devices – were common in past Oracle contracts but are now largely retired.

Today, most Oracle products utilize metrics such as Named User Plus or Processor licenses.

Understanding how concurrent user and concurrent device licenses worked, why Oracle phased them out, and how current metrics operate is crucial for enterprises to optimize costs and avoid compliance issues.

Introduction: Oracle’s Evolving License Metrics

Oracle’s software licensing has undergone significant changes over the past few decades.

Many enterprises that have used Oracle for 10 years or more may still hold older contracts with legacy license metrics, such as concurrent user or concurrent device licenses.

These metrics, once common in databases and enterprise applications, measure usage by the number of users or devices active simultaneously.

In contrast, Oracle’s current licensing models mostly count named users or processing power, rather than concurrent usage.

This evolution was driven by technology changes and Oracle’s business strategy. Legacy concurrent metrics offered flexibility but were harder to track and audit.

Oracle gradually retired concurrent licensing in favor of more straightforward models (like per-user or per-processor licenses) that are easier to manage and align with modern multi-core hardware and cloud environments.

To fully grasp Oracle’s licensing (for databases, middleware, and applications), it’s important to compare the legacy concurrent metrics with today’s standard metrics and understand when and why the change happened.

What Are Concurrent Licensing Metrics?

Concurrent licensing allows a single license to be shared among multiple users, as long as only a specified number are using the software simultaneously.

In practice, an organization might have hundreds of potential users, but only pay for, say, 50 concurrent users if that’s the maximum number using the system simultaneously.

Any user can occupy one of those 50 seats when they log in, and when someone logs off, another person can use that freed license slot.

This model was historically attractive for companies with many infrequent users or staff working in shifts.

Oracle applied the concurrent concept in different ways:

• Concurrent User License: Common in older Oracle applications (like Oracle E-Business Suite, JD Edwards, or Siebel CRM). For example, a Concurrent User license for an ERP module would allow a set number of users to be logged in at once, regardless of which specific individuals they are.
• Concurrent Device License: Used for Oracle’s technology products (such as Oracle Database in the 1990s). A Concurrent Device counted the number of devices or terminals accessing the database simultaneously. It limited simultaneous connections rather than named individuals.

In both cases, concurrency metrics measure peak usage. This differs from a named user metric, where each individual authorized to use the software requires their own license (regardless of how often or when they use it).

With concurrent licensing, one license can cover multiple people as long as they don’t use the software concurrently beyond the allowed number.

Legacy Oracle Licensing Metrics (1990s–2000s)

Oracle’s older contracts featured several metrics that are no longer sold today. Understanding these legacy models gives context to how Oracle licensing has changed:

• Named User (NU): In the 1990s, Oracle Database was often sold per Named User. Each authorized person counted as one license. This legacy Named User metric had no concept of concurrent sharing – it simply counted distinct users. Originally, it had no minimum user counts tied to hardware, which made it flexible for small systems. Oracle discontinued the old Named User metric in the late 1990s, then briefly reintroduced a variant around 2001 with minimums (e.g., 10 named users per processor). Ultimately, it was replaced by Named User Plus as the standard user-based metric.
• Concurrent Device (CD): This was a legacy concurrent licensing model for databases and other technologies, offered throughout most of the 1990s and retired by around 1999. It allowed unlimited potential connections as long as only a certain number of devices or terminals were connected at any one time. For example, if you have 20 Concurrent Device licenses for Oracle Database, you can run the database on any number of servers and define thousands of users. However, only 20 devices (or user sessions) can be actively using the database concurrently. No per-processor minimums applied – a key difference from today’s user licenses, which require a minimum count per CPU. This made concurrent device licenses very flexible: companies could deploy Oracle on multiple servers without buying more licenses, provided the concurrent usage limit wasn’t exceeded. However, managing and tracking concurrent usage could be challenging in practice. Oracle stopped selling new Concurrent Device licenses by 1999, though customers who already owned them could continue using them (with support).
• Named User – Single Server / Multi Server: Oracle offered these variants in the late 90s. A Named User Single Server license meant a user was tied to one specific server; a Multi Server license allowed a user to access multiple servers. These had some odd restrictions – for instance, license requirements scaled with hardware size (measured in CPU MHz). If you upgraded hardware, you might suddenly need more licenses for the same users because the metric was tied to processor power. These models also lacked the “Plus” benefits (no automatic exclusion for certain batch operations). Oracle eventually moved away from these models as well.
• Universal Power Unit (UPU): Another legacy metric from the 1990s, UPU was based on the processing power of the hardware. Essentially, it was a capacity-based metric – for example, a formula involving CPU clock speed (MHz) determined the number of “power units” required. This metric became obsolete as hardware evolved (multi-core processors made a simple MHz measure inadequate). UPU licenses have been deprecated; using them on modern servers can be impractical because a single new CPU could consume many times the UPU units that an old processor did. Oracle transitioned away from UPU by the early 2000s in favor of core-based licensing.
• Concurrent User (Applications): Oracle’s enterprise applications (those acquired and developed in the 1990s and early 2000s) often had a concurrent user licensing option. For example, Oracle E-Business Suite (EBS) once offered a Concurrent User license for certain modules, and JD Edwards (an ERP system Oracle acquired) also had concurrent user licenses. A company might have purchased, say, 50 concurrent user licenses for JD Edwards – meaning 50 employees could use the system at once, even if hundreds had logins. This was especially useful for organizations with global operations or shift work, where not everyone is on the system simultaneously. Siebel CRM (another Oracle acquisition) similarly had some modules licensed by concurrent users (often in contexts like call center agents). Oracle has since retired concurrent user licensing for all these products – they no longer sell new concurrent-user-based licenses for EBS, JD Edwards, or Siebel. Following Oracle’s acquisitions and licensing policy updates in the 2000s, these applications transitioned to named user or other metrics-based models. However, many Oracle customers still retain legacy entitlements under these terms from earlier contracts.
• Professional User (Applications): This was another legacy metric, commonly seen in Oracle EBS and other older Oracle applications. A Professional User was essentially a type of named user license, often with a broader usage scope across modules. (For instance, EBS had Professional User vs. Self-Service User categories, where Professional Users had full access to certain modules and were typically a higher tier license.) Some contracts allowed a mix of professional and limited-use (self-service or read-only) users. Like concurrent licenses, professional user licenses are legacy; Oracle now uses simpler “application user” metrics or enterprise metrics in their place.

When Did These Legacy Metrics Stop? Oracle’s shift away from these models occurred roughly around the late 1990s to mid-2000s:

• The core technology metrics (Concurrent Device, old Named User, UPU) were mostly discontinued by 1999-2000, aligning with the release of Oracle 8i/9i and the push toward Named User Plus and Processor licensing.
• Oracle’s applications continued to honor legacy user metrics into the 2000s, but after Oracle acquired PeopleSoft, JD Edwards, and Siebel (mid-2000s), it standardized licensing. By the 2010s, Concurrent User licenses for Oracle applications were no longer offered for sale. Existing customers could retain their rights (grandfathered), but any new licenses or additional users would have to be licensed under the newer models. In other words, if a company owns 100 EBS Concurrent User licenses from 2004, they can use them; however, if they need licenses for new users, Oracle will require a modern metric (such as per named user or an enterprise metric) for those additions.

Many organizations today still “have it today” only in the sense of legacy use: they continue running Oracle software under these old metrics because they purchased it years ago and remain on support.

Oracle generally allows this – support renewals keep the legacy licenses valid even on the latest software versions.

However, Oracle sales and audit teams may encourage (or pressure) customers to migrate to current licensing models, especially if changes to usage are needed.

Current Oracle Licensing Metrics (Standard Models Today)

Oracle’s current licensing is dominated by a few standard metrics that replaced the legacy ones:

• Processor License (Per-Core Licensing): For databases, middleware, and some other products, Oracle uses processor-based licensing. This is hardware-centric: you license each processor core on the server where the software runs (with a weighting factor per core, defined by Oracle’s core factor table). A Processor license essentially grants unlimited user access on that processor. This model gained prominence as multi-core servers became the norm, because it charges for the computing power rather than user counts. For example, if you run Oracle Database Enterprise Edition on a server with 8 cores (Intel) and the core factor is 0.5, you need 8 × 0.5 = 4 Processor licenses. All employees or applications can use the database on that server with no additional user licenses needed. Processor licensing replaced metrics like UPU and removed the concurrency concept entirely – it doesn’t matter how many users connect, only the hardware capacity matters.
• Named User Plus (NUP): This is the modern user-based license for Oracle Database and many other products. Named User Plus counts distinct individuals (or devices) authorized to use the software. The “Plus” signifies that certain indirect usages are covered (for instance, if an Oracle database is accessed only via a batch process or a non-Oracle front-end, those end-users might not need licenses under some conditions – something the old Named User metric didn’t allow). Oracle’s contracts define “user” broadly, so every human or device that accesses the Oracle program, directly or indirectly, needs to be counted. Unlike concurrent models, Named User Plus is not concurrent – even if a user never logs in, they still require a license if authorized to use the system. Oracle enforces minimum license counts per processor with NUP. For example, on Oracle Database Enterprise Edition, there is a minimum of 25 Named User Plus licenses per processor. Even if you have a small number of users, if the database runs on a powerful server (say, four processors), you must purchase at least 4 × 25 = 100 NUP licenses (or use processor licensing instead). This minimum was implemented to prevent the misuse of user licensing on large servers. NUP is now the go-to metric for environments where the number of users is known and limited.
• Application User (and similar metrics): For Oracle’s application software (ERP, CRM, etc.), licensing is typically based on Named Users, although Oracle often refers to them as “Users” or “Seats” in price lists. Each unique person who uses the application needs a license (or a bundle of module licenses). For example, if you have Oracle E-Business Suite Financials, you might license 50 Financials Users – meaning 50 named individuals can access that module. Concurrency doesn’t apply; all 50 could log in at once (that’s fine), but a 51st person would require an additional license. Oracle no longer offers “50 concurrent users” for EBS; instead, it’s “50 named users”. Some modules or suites use enterprise metrics, such as the number of Employees, customers, or revenue, to license them – for instance, Oracle HR modules might be licensed per employee. However, these figures do not account for concurrent usage.
• Cloud Subscription Metrics: In Oracle’s cloud services (SaaS, such as Oracle Fusion Cloud ERP or Oracle Cloud Infrastructure), licensing is subscription-based and often per user per month or based on usage units (e.g., OCPU hours). These aren’t “concurrent” either – you subscribe for a certain number of user accounts or a specific capacity. This is beyond the scope of on-premises license metrics. Still, it’s worth noting that Oracle’s move to the cloud also inherently moves away from any concurrent usage model (since cloud subscriptions are named users or consumption-based).

Table: Legacy vs. Modern Oracle License Metrics

Key: Legacy metrics in italics are no longer sold, though existing licenses may be in use. Current metrics are the standard options for new licenses.

Why Oracle Moved Away from Concurrent Licensing

Concurrent licenses provided flexibility but also posed challenges for both Oracle and customers:

• Difficult Tracking: It’s challenging for organizations to continuously monitor the number of users or devices that are actively connected. In the early days, software had built-in limits (e.g., older versions of JD Edwards could cap concurrent sessions at a certain number). Still, modern multi-tier architectures and web-based systems don’t have simple limits. This means a company could inadvertently exceed its licensed concurrent user count if it’s not actively managed. For example, “hanging” sessions (where a user closes a window without properly logging out) may still be counted as active connections and push the concurrent count over the limit. Oracle’s audit tools often take snapshots of peak usage, which could catch those transient overages.
• Audit and Compliance Issues: From Oracle’s perspective, concurrency was hard to enforce. Oracle License Management Services (LMS) would have to rely on log files, system queries, or even trust the customer’s word to determine the peak concurrent usage. There’s no simple license key enforcing “only 50 users can log in”. This lack of a hard cap meant some customers might unknowingly (or knowingly) exceed their limits. It also meant that Oracle auditors had more work to do in interpreting the data. By moving to named user and processor metrics, Oracle shifted compliance to simpler counts (number of user accounts, or number of installed CPUs), which are more black-and-white.
• Revenue and Growth: Concurrent licensing can be very cost-effective for customers – one concurrent license can cover multiple infrequent users, which potentially limits Oracle’s license revenue as customers grow. Under a concurrent model, a company that doubled its total user base might not need to buy more licenses if its peak concurrent usage stays the same. Under a named user model, every additional headcount who needs access likely means another license sold. Oracle’s current metrics ensure that as customers’ usage or hardware grows, license requirements (and fees) grow accordingly. This was an economic incentive for Oracle to phase out legacy metrics.
• Technology Changes: The legacy metrics came from an era of client-server apps and single-core CPUs. Today’s environment of cloud computing, virtualization, and multi-core servers doesn’t fit well with metrics like “Concurrent Device” or “MHz-based UPU”. For instance, a Concurrent Device license had no adjustment for multi-core processors, so a license bought in 1998 for a 1-CPU server could technically cover a much more powerful multi-CPU, multi-core cluster today (a huge increase in effective use). Oracle naturally wanted to eliminate such loopholes. Similarly, virtualization platforms (such as VMware) enable VMs to migrate across hardware, making it challenging to determine concurrent device counts on specific servers. Oracle’s modern stance is often to require licensing of the whole environment (all processors in a cluster, etc.) unless using hard partitioning. The older metrics didn’t mesh with this stance.
• Standardization: Over the years, Oracle acquired many companies (PeopleSoft, Siebel, Sun, etc.), each with its licensing quirks. Oracle standardized the licensing terms to simplify its portfolio. Concurrency was not part of that standardization, except in rare cases. This uniform approach makes it easier for Oracle reps to sell and for Oracle to educate the market on a few key metrics (like NUP and processor), instead of maintaining various legacy options.

Pros and Cons of Legacy Concurrent Licensing (Customer Perspective)

Although Oracle prefers modern metrics, some customers deliberately retain their legacy concurrent licenses. There are advantages and disadvantages to consider:

Advantages of Concurrent Licensing:

• Cost Efficiency: You only pay for peak usage, not the total number of users. If you have 1,000 employees but only ~100 ever use the system simultaneously, 100 concurrent licenses could suffice (versus buying 1,000 named user licenses). This can significantly reduce costs for systems with sporadic or seasonal usage. It’s ideal for companies with users in different time zones or shifts – the same 50 concurrent licenses might cover 100+ people who use the system at different times of day.
• Flexibility in Deployment: Especially for the Concurrent Device metric on databases, legacy licenses often had no hardware tie-ins or minimums. A business could deploy Oracle on multiple servers or upgrade to a larger server without needing additional licenses, as long as they controlled concurrent usage. This is useful in virtualized or cloud-like environments (one legacy CD license could theoretically float across infrastructure, which is something Oracle’s current rules usually forbid with named user licenses tied to specific processors).
• Audit Leverage: Paradoxically, while concurrency can be hard for customers to track, it’s also hard for Oracle to prove non-compliance. If an Oracle auditor asks, “Prove you never had more than 50 users connected,” it might come down to your own logs and usage data. There’s often some gray area or reliance on trust and documentation, unlike named user counts, which are more straightforward (Oracle can just request user lists). Some organizations feel this gives them more negotiating leverage in an audit, because Oracle cannot easily demonstrate a clear breach unless there’s obvious evidence of overuse.

Disadvantages and Risks:

• Complex Management: Keeping under a concurrent cap requires active monitoring. You need to track the peak usage of databases or applications. In practice, tools and scripts must be in place to count current sessions. Admins must also educate users on how to properly log out to avoid ghost sessions that consume licenses. This is an extra operational overhead not present with named user licensing.
• No New Purchases: If you need more licenses, you cannot buy additional concurrent user or device licenses from Oracle today. You’d likely have to convert to a modern metric for the new increment. This can be costly and complicated. For example, if you own 100 concurrent user licenses for an ERP system and suddenly need to support 120 concurrent users, Oracle will not sell you “20 more concurrent licenses”. Instead, they might propose moving you to a named user model for all users, or selling you 20 named user licenses for the new people while keeping your 100 concurrent for the original group. This hybrid can be messy to manage. Essentially, growing beyond your legacy entitlement often triggers a re-license in modern terms.
• Potential Higher Cost if Misaligned: Concurrent licensing is cost-effective only up to a point. If your usage pattern changes such that most users are logged in all the time, a concurrent license provides no savings (e.g., if 500 out of 500 employees use the system daily from 9–5, you’d be at 500 concurrent users anyway). In such cases, you might be better off with a processor license. Some older metrics also didn’t anticipate multi-core efficiency – e.g., a contract might stipulate a minimum, such as “8 Concurrent Devices per processor” (an old Oracle guideline for Enterprise Edition databases). If one interprets it strictly on a modern 16-core CPU, it could mean needing 128 concurrent device licenses for one server, which is impractical and significantly more expensive than using just two processor licenses. In short, legacy metrics can sometimes under- or overshoot costs, depending on the context, and it requires analysis to ensure they remain beneficial.
• Oracle Pressure and Support Considerations: Oracle Sales may offer incentives to migrate to newer models (sometimes even threatening to withhold support for older models – although if you’re paying for support, your contract rights remain). During contract renewals or audits, Oracle may push a conversion, for instance, converting one concurrent license into a certain number of Named User Plus licenses. (Historically, Oracle has sometimes used conversion ratios like 1 Concurrent Device = 2 Named User Plus as a guideline, though each case can be negotiated.) If not handled carefully, a conversion can result in dramatically higher counts of required licenses, leading to increased support fees. There’s also a risk that an Oracle rep unfamiliar with legacy terms might misinterpret them (e.g., incorrectly assume a minimum user count applies when the contract doesn’t explicitly say so). Customers have to be prepared to educate Oracle’s team on their contract terms.

Real-World Example: Converting a Legacy Concurrent License

Scenario: An enterprise has an Oracle database that was originally licensed in 1998 with 50 Concurrent Device licenses. At that time, this covered their single Oracle server with plenty of headroom for 50 concurrent sessions.

In 2025, the company’s Oracle environment has grown: they now run multiple Oracle databases on virtualized servers with many CPU cores. However, they’ve kept their old 50 Concurrent Device licenses valid through support.

• Under Legacy Terms: Those same 50 concurrent licenses still allow any number of users to access any number of Oracle databases, as long as no more than 50 total connections are active at once across the environment. There are no core-based minimums in their 90s contract. This could theoretically allow the company to deploy Oracle on a cluster of dozens of cores, which, under today’s rules, would normally require many processor licenses. In terms of annual support, they pay Oracle support based on the original license fees (which may be relatively low compared to current prices), plus yearly increases. This looks like a great deal – high flexibility, low cost – if they can manage usage within 50 concurrent sessions.
• Challenge: The business now wants to roll out a new application that will increase database usage. They project that peak concurrent sessions might rise to 80. Since Oracle won’t sell more CD licenses, they have two main options: (a) negotiate a conversion of their 50 Concurrent Device licenses to a modern metric covering ~80 sessions, or (b) purchase additional licenses in a current model just for the new usage (while retaining the old ones for the original usage).
• Conversion Example: Oracle might propose converting the 50 concurrent licenses into Named User Plus licenses or Processor licenses. One approach could be: 1 Concurrent Device = 2 Named Users, plus (this is just an example ratio that Oracle has used historically). That would turn 50 CD into 100 Named User Plus licenses. If each database server requires a minimum of 25 NUP per processor, those 100 NUP could cover, for instance, four processor licenses’ worth of servers. If the environment is larger, Oracle might instead suggest processor licensing: e.g., if the company has 8 processors deployed, Oracle might say convert 50 CDs into 8 Processor licenses (perhaps with some discount). The list price of Oracle Database Enterprise Edition per processor is around $47,500 (as a ballpark), so eight processors would be $380,000 (plus 22% yearly support ~$83,600). If the company’s legacy 50 CD licenses originally cost, say, $1,500 each in the 1990s ($75,000 total) and support is approximately $16,500 per year, the jump to modern pricing is significant.
• Outcome: The company must weigh continuing with the 50 concurrent cap (enforcing strict limits and possibly disappointing some users) versus the cost of upgrading licenses. In many cases, customers negotiate a deal where Oracle gives credit for the original licenses toward the new purchase. Perhaps Oracle says: Your 50 CD licenses are worth $X in credit; apply that to buying processors or NUP licenses. The customer might also reduce costs by architecting the system efficiently (maybe limit Oracle to fewer servers to reduce the processor count). In any event, the case illustrates that migrating from a legacy metric to current metrics can be a major financial decision. This is why many businesses do not change until it is necessary.

Managing Legacy License Metrics Today

For organizations that still have legacy concurrent licenses (or any retired Oracle metrics) in their contracts, management and planning are key:

• Know Your Entitlements: Keep copies of your Oracle contracts and ordering documents that define the legacy metric. Understand exactly what “Concurrent Device” or “Concurrent User” means in your case, because the contract definition is what matters. (For example, some Oracle contracts for Concurrent Device licenses explicitly list a minimum number of devices per processor, while others do not. Your usage rights depend on the exact wording.)
• Monitor Usage: Implement monitoring to track concurrent usage of Oracle systems. Database administrators can use scripts or Oracle’s monitoring (e.g., querying v$license or session tables) to see peak sessions. Application admins should track login sessions for EBS/JD Edwards, etc. Regularly review these to ensure you’re within the licensed limits. If you notice usage trending upward near your limit, that’s a red flag to address proactively.
• Educate IT Staff: Ensure that anyone provisioning new servers or creating new user accounts is aware of the special licensing considerations. For instance, if you have a pool of 50 concurrent user licenses for an application, the system might technically allow you to create 500 user accounts. Still, your team must understand that only 50 can be active at once. Sometimes, technical teams accidentally violate licensing simply because they are unaware of the old rules.
• Maintain Support (if needed): As long as you pay Oracle’s support on those licenses, you are typically entitled to use the latest versions of the software under that metric. If you let support lapse, you lose upgrade rights (and Oracle could argue you no longer have a valid license for new versions). That said, some companies with perpetual licenses choose to drop support if they don’t need upgrades, to save cost – but this comes with risks (no access to patches, and difficulty reinstating support later).
• Plan for Transition: It’s wise to have a long-term plan in place. Oracle’s current direction is clear – eventually, everyone is expected to be on modern metrics or cloud subscriptions. If you have a long-term IT strategy (for example, moving workloads to Oracle Cloud or upgrading to a newer Oracle ERP), consider how and when you might convert your legacy licenses. If you anticipate growth that will break your concurrent limits, start discussions early. Often, the best time to negotiate a conversion is at a big contract event (like purchasing additional Oracle products or renewing a ULA) where Oracle might offer discounts in a bundle.

Recommendations

To effectively manage Oracle licensing, especially regarding legacy concurrent metrics, consider the following actions:

• Identify Legacy Licenses: Catalog all Oracle licenses your organization owns. Flag any that use retired metrics (e.g., Concurrent User, Concurrent Device, old Named User, UPU). Knowing these is the first step to managing them.
• Understand Contract Terms: Review the original license agreements for any legacy metrics that may be included. Pay attention to definitions (what constitutes a “user” or “device”), any minimum requirements or hardware constraints, and whether the licenses are restricted to specific servers or environments. This will be critical in an audit or when planning changes.
• Monitor and Limit Concurrent Usage: If you continue using concurrent licenses, implement monitoring tools to track active sessions. Set up alerts or administrative controls to prevent exceeding your licensed concurrent count. For example, some companies use connection pool limits or application settings to cap the number of simultaneous sessions.
• Evaluate Cost-Benefit of Migration: Compare the costs of retaining legacy licenses vs. converting to modern metrics. Include support fees, potential additional licensing requirements, and operational overhead. In some cases, sticking with an old metric is cost-effective, but in others (e.g., moving to new hardware where old metrics don’t scale well), it might be better to convert. Perform a scenario analysis or work with a licensing specialist.
• Engage with Oracle Proactively: If you foresee needing more capacity than your legacy licenses allow, engage Oracle (or an Oracle licensing advisor) proactively. When approached early, Oracle might provide a reasonable conversion offer or migration path. If you wait until an audit finds you out of compliance, you’ll have less negotiating leverage.
• Mix Metrics Strategically: For organizations with a mix of license types (e.g., some named-user and some concurrent licenses from the past), allocate them wisely. Use concurrent licenses for intermittent users or those with infrequent access, and ensure that heavy or constant users are covered by named user licenses. This maximizes utilization while staying compliant.
• Stay Informed of Policy Changes: Oracle’s licensing policies are subject to change. Keep an eye on updates from Oracle (or analyses from firms like Gartner or Oracle licensing consultancies) about licensing rules – for instance, changes in virtualization policy or new metrics (like Oracle’s new Java per-employee metric) that might affect your strategy. Being informed will help you avoid surprises.
• Conduct Internal Audits: Don’t wait for Oracle’s official audit. Do your compliance check annually. Count your user licenses against the actual number of users, verify your server deployments against processor licenses, and simulate concurrent usage to ensure it remains within the limits. This way, you can find and fix issues before Oracle does.

Checklist

Here’s a quick checklist of five key steps to take regarding Oracle concurrent licensing metrics:

1. Inventory Your Licenses: List all Oracle licenses and identify any using terms like “Concurrent User,” “Concurrent Device,” or other legacy metrics.
2. Review License Definitions: Pull out your contracts and read the definitions for those legacy metrics. Note any limitations or special conditions (e.g., “8 concurrent devices per processor” minimum, specific named servers, etc.).
3. Monitor Usage Levels: Implement monitoring scripts or tools on your Oracle systems to track the peak number of sessions or connections. Log the maximum concurrent usage and compare it against your licensed allowances regularly (monthly or quarterly).
4. Enforce Compliance Measures: If necessary, configure your applications or database settings to limit sessions (or at least alert administrators when the limit is approaching). Educate users on how to properly log off to avoid idle sessions counting against them.
5. Plan for Growth: Project future Oracle usage needs. If you expect to exceed the limit of a legacy license, formulate a plan. Whether it’s negotiating a conversion with Oracle, archiving some usage to reduce demand, or migrating to a newer license model, start this process well before you hit the limit to avoid last-minute compliance gaps.

FAQ

Q1: What is a “Concurrent User” license in Oracle, and how is it different from a Named User license?
A1: A Concurrent User license allows a specific number of users to be logged in to the Oracle software simultaneously, regardless of who they are. It’s a floating pool of usage slots. For example, 30 Concurrent User licenses for an application mean that up to 30 people can use it simultaneously, even if 100 or more have access. In contrast, a Named User license is tied to a specific individual (the named user). If 100 people need access, you typically require 100 named user licenses – even if only 30 use the system at a time. Concurrent licensing limits the peak simultaneous use, whereas named user licensing counts the total number of unique users with permission to use the software.

Q2: Which Oracle products historically used concurrent licensing metrics?
A2: In the 1990s and early 2000s, several Oracle product lines offered concurrent-based licensing:

• Oracle Database and Middleware: had the Concurrent Device metric for databases (and some middleware servers), which limited the number of concurrent connections from devices/terminals.
• Oracle E-Business Suite (ERP): offered Concurrent User licenses for certain modules (as well as “Professional User” licenses). This lets companies license a pool of simultaneous EBS users.
• JD Edwards ERP (acquired by Oracle): Utilized concurrent user licensing extensively before Oracle’s ownership and during the early years of Oracle’s ownership.
• Siebel CRM had some concurrent user options (e.g., for call center agents or customer portal users) before Oracle standardizing it to named users.
• Other legacy Oracle applications and tools also sometimes had concurrent session licenses. Today, none of these products sell concurrent licenses – they use named user, processor, or enterprise metrics. The concurrent metrics you might encounter now exist only in older contracts that are still in effect.

Q3: When did Oracle stop offering concurrent user or device licenses?
A3: Oracle gradually phased out concurrent licensing around the turn of the century. For core technology products (such as databases), Concurrent Device licenses were discontinued around 1999. Oracle shifted to user-based and processor-based metrics with Oracle8i and Oracle9i in the early 2000s. For enterprise applications like EBS, PeopleSoft, JD Edwards, and Siebel, Oracle continued honoring legacy metrics after acquiring those product lines (mid-2000s), but stopped selling new concurrent user licenses by the late 2000s. By the 2010s, any new licenses for these apps had to be Named User or a different model. In summary, it’s been well over a decade since Oracle actively sold concurrent licensing. If you see a concurrent metric in a contract today, it’s almost certainly a carry-over from a long-standing agreement.

Q4: Can we still use our old Oracle concurrent licenses, and are they valid for new software versions?
A4: Yes – if you purchased Oracle licenses under a legacy metric and have kept up with support (or otherwise have the rights), you can continue to use them. Oracle honors the contracts you signed. For example, if you have 100 Concurrent Device licenses for Oracle Database from 1998 and are still paying annual support, you can use those licenses on the latest Oracle Database version. They remain a valid entitlement. The key is to remain compliant with their terms (don’t exceed the concurrent count, etc.).

Q5: How should we handle an Oracle audit or contract negotiation if we have legacy concurrent licenses?
A5: Handling audits and negotiations involving old metrics requires preparation.

Negotiations/Renewals: Assess in advance what Oracle might propose. If you are renewing support or making a new purchase, Oracle reps might suggest converting everything to Named User Plus or Processor licenses “for simplicity.” Don’t agree without analyzing the cost impact. It can be helpful to get an independent licensing advisor’s input or use Oracle’s license migration tools to calculate scenarios. You may negotiate to grandfather favorable terms (e.g., retaining your concurrent licenses for current deployments and using new metrics only for new deployments). If you do decide to convert legacy licenses, try to do it as part of a larger deal where you have leverage (such as a big purchase or a broader contract renewal) to obtain better pricing or credit for your existing investment.

During an Audit, be ready to demonstrate compliance with your legacy licenses. That might include providing evidence that peak usage does not exceed your licensed concurrency limits. Maintain logs or screenshots of usage statistics. If Oracle’s auditors are unfamiliar with your older metric, you may need to explain your contract’s terms to them. Stick to what your contract states – for instance, if your contract doesn’t impose a per-processor minimum on concurrent devices, politely but firmly push back on any auditor’s claim that you need one (provide the contract text as proof).

Read about our Oracle Licensing Assessment Service.

Would you like to discuss our Oracle Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit