Oracle sells Agile PLM access three ways, and the wrong metric can double your license count or hand Oracle an audit shortfall you cannot dispute. This breakdown shows where the crossover sits, how Oracle measures concurrency, and the peak-concurrency trap that ambushes manufacturers.
Oracle sells Agile PLM access three ways, and the wrong metric can double your license count or hand Oracle an audit shortfall you cannot dispute. This breakdown shows where the crossover sits, how Oracle measures concurrency, and the peak-concurrency trap that ambushes manufacturers.
Oracle Agile PLM is licensed by user, but there is no single user metric. There are three, and the choice you made (or inherited) years ago determines both your annual support bill and your exposure the day Oracle's License Management Services team knocks. In 25 years negotiating Oracle contracts, the metric decision is the one buyers most often get wrong at signing and most often lose at audit. This page explains how Oracle counts Named, Concurrent, and Restricted users on Agile PLM, quantifies where concurrent pricing actually beats named-user pricing, and names the peak-concurrency measurement trap that turns a modest deployment into a seven-figure shortfall claim.
Per Oracle's own Agile PLM Administrator Guide (Release 9.3.6, E71145-01), Agile PLM carries three distinct user license types. Named (historically called "Power") users can log in at any time and are never counted against a concurrency pool. Concurrent users share a fixed pool and get locked out once the licensed simultaneous count is hit. Restricted users are people outside your company, such as suppliers and distributors, granted limited access. Named and Concurrent users reach identical functionality based on role and privilege. The only mechanical difference is whether Oracle counts you against a ceiling or not.
Two facts from Oracle's documentation deserve highlighting before you model anything. First, Oracle's guide states plainly that "a Power User can log in at any time and is not counted as a member of the concurrent user pool." Second, and more consequential, Oracle's own guide warns that "concurrent user assignments and counts may not apply to your current installation and upgrade," directing customers to Oracle Consulting or their sales rep. Translation: the concurrent metric may not even be legally available on your contract, and Oracle knows it. If your entitlement documents list a concurrent metric that Oracle later argues is invalid for your version, you are exposed on both sides of the ledger.
Oracle's own Administrator Guide warns that concurrent counts may not apply to your installation. That sentence is a liability, not a footnote.
Agile PLM's named metric follows Oracle's Named User Plus (NUP) rules. Under NUP, every individual authorized to access the environment needs a license, and frequency of access is irrelevant. Someone who logs in once a quarter counts the same as your lead PLM administrator. NUP also counts non-human devices operated by humans, and it counts external collaborators (suppliers, partners) unless they hold a Restricted license. This is where manufacturers hemorrhage license spend: an engineering-change workflow that touches 40 supplier contacts counts those 40 contacts unless they are properly scoped as Restricted users. We break the external counting problem down in detail in our guide to counting suppliers and external users in Agile PLM deployments.
NUP also carries a per-processor minimum. Oracle requires a floor of licenses per processor regardless of your actual headcount. As documented for Oracle's broader NUP model, the effective count is max(actual users, 25 × processor count). For Agile PLM specifically the minimum can differ by product, so verify it against your ordering document rather than assuming the database default. The practical effect is the same: on a small user base running on generously sized hardware, the processor minimum, not your headcount, sets the price. Buyers who never checked their processor count are frequently paying for phantom users who do not exist. The same crossover math governs the database itself, which we cover in Named User Plus or Processor: the metric decision.
Concurrent licensing shines under one specific condition: intermittent or shift-based access, where your total authorized population is large but the number logged in at any single moment is small. A manufacturer with 600 shop-floor and engineering users who never exceed 120 simultaneous sessions is a textbook concurrent candidate. Under NUP that customer licenses 600 (or the processor minimum, whichever is higher). Under concurrent, they license roughly 120 plus a safety margin. That is an 80 percent reduction in counted units before any discount negotiation.
Named-user pricing wins under the opposite profile: a stable, known, always-on population. If 40 engineers each spend six hours a day in Agile PLM, your peak concurrency approaches your headcount, and concurrent buys you nothing while adding lockout risk. Third-party analysis (Reveal Compliance, November 2024) confirms the general rule: NUP is cost-effective when the population is stable and countable, while concurrent shines when access is shift-based. Oracle's own licensing pattern (per Oracle Licensing Experts, July 2025) holds that NUP suits small, known populations and gets complex and expensive when counts are large or uncertain.
| Deployment profile | Total authorized users | Typical peak concurrency | Metric that costs less |
|---|---|---|---|
| Always-on engineering core | 40 | 35 to 40 | Named User Plus |
| Shift-based shop floor plus engineering | 600 | 110 to 140 | Concurrent |
| Occasional reviewers and approvers | 250 | 40 to 60 | Concurrent |
| Small stable admin team on large hardware | 30 | 25 to 30 | Named (watch processor minimum) |
The figures above reflect our field experience modeling Agile PLM populations, not Oracle list-price data. Use them as pattern recognition, then rebuild your own peak-concurrency curve from actual login logs before you commit. The single number that decides everything is the ratio of peak concurrent sessions to total authorized headcount. Below roughly 40 percent, concurrent almost always wins. Above 70 percent, named almost always wins. The 40-to-70 band is where negotiation, discount level, and audit risk break the tie.
The decision turns on one ratio: peak concurrent sessions divided by total authorized headcount. Below 40 percent, concurrent wins. Above 70 percent, named wins.
Oracle does not publish Agile PLM user pricing cleanly, and aggregator estimates are not list prices. For rough sizing only, ITQlick (June 2025) puts per-user cost between $75 and $150 per user per month for 1 to 100 users, declining to roughly $40 per user per month above 1,000 users. Treat those as directional. What matters for your model is that Oracle discounts are always expressed as a percentage off the list price in the Technology Global Price List, and negotiated deals routinely land 20 to 60 percent below list.
The support mechanics are where the metric decision compounds for a decade. Oracle Premier Support is priced at 22 percent of the net license fee (list minus your negotiated discount), and that support base then escalates at roughly 8 percent per year compounding. Choose the metric that inflates your license count by 30 percent, and you have not made a one-time error. You have locked in a 22 percent support tax on that inflated base, escalating 8 percent annually for as long as you stay on Oracle support. That escalation is also the strongest argument for evaluating your exit options, which we quantify in the Agile PLM third-party support decision.
Here is where the concurrent metric bites back. Concurrent is not measured by your average session load or your typical business-hours peak. Oracle measures the single highest number of simultaneous sessions observed across the entire audit window. One overnight batch job, one all-hands change-review meeting, one month-end release freeze where every engineer logged in at once, and your measured peak is set by that outlier. Manufacturers routinely license to their 90th-percentile concurrency and get assessed against their absolute maximum. The gap between the two is the shortfall Oracle bills.
Legacy metrics make this worse. Oracle stopped selling older metrics like Named User (legacy) and Concurrent Device years ago, and per ITAM Review, customers still carrying those obsolete metrics are selected for audit earlier precisely because their metrics no longer map cleanly onto modern deployments. If your Agile PLM contract still references a retired concurrent metric, you are wearing a target. Named-user audits are structurally messier too: Oracle's LMS team must establish who counts as a named user, who accesses directly, who accesses indirectly through connected applications, and whether the NUP minimum was met. Oracle interprets indirect and connected access broadly, and that interpretation is where most named-user disputes are lost.
The defensive posture is the same regardless of metric: instrument your login data now, retain it, and cap the measurement window Oracle can reach. Our Agile PLM audit-defense evidence pack lays out exactly which logs and entitlement documents cap exposure before an audit begins.
Oracle prices compliance gaps retroactively, and the raw license shortfall is never the whole bill. Oracle stacks the license fee, backdated support for every year of unlicensed use, and penalty terms on top. In Oracle settlement patterns we have analyzed, backdated support and penalty terms added 20 to 35 percent on top of the raw license gap, while final settlements landed 30 to 50 percent below Oracle's opening number once the count was rebuilt from real data. That last figure is the leverage: Oracle's opening claim is a negotiating position, not a measured fact, and a rebuilt user count routinely knocks a third to a half off it.
The compounding effect is the sting. When a settlement includes backdated license fees, Oracle applies its standard 22 percent annual support charge on those new licenses, and that base then escalates going forward. A concurrent measurement error you never noticed becomes a permanent support liability. This is why the metric decision belongs in your negotiation strategy, not your procurement checklist, and why it connects directly to the broader Oracle Agile PLM licensing metrics, modules, and audit exposure picture. Module sprawl multiplies the problem, because each module carries its own metric and its own count, as we detail in Agile PLM module sprawl and the add-ons that surface in an audit.
No. Per Oracle's Agile PLM Administrator Guide, a Named (Power) user can log in at any time and is never counted as a member of the concurrent user pool. Only non-Named, non-Restricted users are subject to concurrency limits and lockout. That is the sole mechanical difference, because both metrics reach identical functionality by role.
Concurrent wins when your total authorized population is large but only a small fraction is logged in simultaneously, typically shift-based or intermittent access. The decision turns on the ratio of peak concurrent sessions to total headcount: below roughly 40 percent, concurrent almost always costs less. Above 70 percent, named-user pricing wins and concurrent only adds lockout risk.
Oracle measures the single highest number of simultaneous sessions observed across the entire audit window, not your average or your typical business-hours peak. One outlier event, such as a month-end release freeze or an all-hands review, can set your measured peak far above your licensed count. This is the peak-concurrency trap: license to the 90th percentile, get assessed against the absolute maximum.
Oracle stopped selling several legacy metrics, including Concurrent Device, years ago, and Oracle's own Administrator Guide warns that concurrent counts may not apply to your installation. If your contract still references a retired metric, you face higher audit selection risk because those metrics no longer map cleanly onto modern deployments. Verify validity against your ordering document.
Oracle's Named User Plus model enforces a per-processor minimum, and the effective count is max(actual users, 25 times processor count) for the database default. Agile PLM product minimums can differ, so confirm against your ordering document. On small user populations running on large hardware, the processor floor, not your headcount, sets the price.
A shortfall is billed as license fee plus backdated support plus penalties, with backdated support and penalties typically adding 20 to 35 percent on top of the raw license gap. Worse, Oracle applies 22 percent annual support to the new licenses, escalating around 8 percent per year compounding. A single measurement error becomes a permanent, growing support liability.
Oracle sells the same database per user and per processor. The 25 NUP per processor minimum, the 50 user break-even, and how to choose the metric that fits the workload.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
