Legacy Agile PLM carries three overlapping compliance surfaces that Oracle prices at full list when an audit lands: user metrics, module toggles, and the embedded database. This guide maps each one, names where the leverage sits, and tells manufacturers still on-premise exactly what to fix before the true-up.
Legacy Agile PLM carries three overlapping compliance surfaces that Oracle prices at full list when an audit lands: user metrics, module toggles, and the embedded database. This guide maps each one, names where the leverage sits, and tells manufacturers still on-premise exactly what to fix before the true-up.
Oracle Agile PLM is a legacy product that Oracle acquired in 2007 and has kept on maintenance-only life support ever since. If you are a manufacturer still running Agile on-premise, you are sitting on a licensing estate that Oracle understands far better than you do, because the contracts predate your current procurement team, the metrics predate Oracle's own current price list, and the embedded database quietly makes you an audited party of record whether you know it or not. In 25 years of negotiating against this vendor, I have watched Agile PLM audits produce findings that had nothing to do with how many people actually use the PLM system and everything to do with what got toggled on, what got connected to the database, and which metric your original contract locked you into.
This is the definitive buyer-side breakdown. It covers the three user license types Agile recognizes and the single contractual metric Oracle actually enforces, the module sprawl that surfaces during a script run, the Application Specific Full Use (ASFU) database restriction that produces the most expensive single findings we see, and the migration pressure toward Oracle Fusion Cloud PLM now that Premier Support for the final Agile release is dated. Read it as a compliance map. Every section ends with what you should do.
Agile PLM's own license console recognizes three user license types: Named (formerly labeled "Power"), Concurrent, and Restricted. Per the Oracle Agile PLM Administrator Guide (Release 9.3.6), Restricted users are people outside your company, such as distributors and suppliers, who are given limited access. Named and Concurrent users have access to the same functionality based on their roles and privileges. The mechanical difference is straightforward: a Named user is not applied against concurrency counts and can log in at any time, while everyone who is not Named or Restricted is subject to concurrency limits and can be locked out when the ceiling is hit.
That is the technical picture inside the software. The contractual picture is different, and the gap between the two is where buyers get hurt. Oracle's contractual metric for Agile PLM is Named User Plus (NUP), applied to each individual authorized to access the environment, whether internal employee or external collaborator. The rule is authorization, not usage: each person who is authorized to access Agile PLM must have a license regardless of how often they log in. A supplier who touches the system twice a year still counts. The worked arithmetic Oracle applies is blunt: 200 employees plus 50 suppliers who need access equals 250 NUP licenses. There is no averaging, no rounding down for light users, and no credit for the fact that only a fraction are ever logged in at once.
The software counts concurrency. The contract counts heads. Buyers who plan around the console and get audited against the contract lose the difference at list price.
NUP is person-specific and non-transferable on a concurrent basis. Two employees sharing one set of credentials under a single NUP license is a violation, and each individual needs their own named license even if they never access the system at the same time. This matters enormously in shop-floor and quality environments where shared workstation logins are common operational practice. Oracle treats every shared credential as an uncounted user during an audit, and the remedy is a purchase, not a warning. We cover the full mechanics of this in Agile PLM named user versus concurrent user pricing.
Some older Agile contracts were sold on concurrent user metrics, and Oracle has broadly phased out concurrent licensing across its product line. Most Oracle products today use Named User Plus or Processor metrics, and concurrent user and concurrent device metrics are effectively legacy. Oracle's own Agile documentation flags this directly: a note in the Administrator Guide states that concurrent user assignments and counts may not apply to your current installation and upgrade, and points you to Oracle Consulting or your sales representative for clarification. When Oracle tells you in its own manual to phone a salesperson about your metric, treat that as a warning, not a courtesy.
Here is the trap. If you hold legacy concurrent capacity and you need more users, you generally cannot simply buy additional concurrent licenses. Instead, Oracle requires you to convert the incremental users, and often the whole base, onto a current metric such as Named User Plus. We have watched this exact conversion pattern play out across Oracle's application estate, including JD Edwards, where the same dynamic applies. The conversion happens during a true-up or an audit, which is precisely when you have the least leverage, and it can be expensive if not negotiated in advance. A concurrent grant is a fixed asset that only shrinks in relative value as your business grows, and Oracle knows it.
| Scenario | What the metric permits | Where the exposure sits |
|---|---|---|
| Legacy concurrent grant, stable headcount | Fixed simultaneous-session ceiling, no per-person licensing | Low, provided you never exceed the ceiling and never expand |
| Legacy concurrent grant, growing headcount | Ceiling is fixed; growth cannot be met by buying more concurrent | High. Conversion to NUP forced at true-up, often on the full base |
| Named User Plus grant | Per authorized individual, internal and external | Medium. Exposure is total authorized heads, including dormant accounts |
If you still hold a concurrent Agile grant, that is a leverage asset, not a liability, as long as you protect it. Do not casually expand user counts, do not let Oracle re-paper your metric during a routine support renewal, and get any conversion terms priced and capped before you sign anything. The single worst move is to let the conversion surface inside an audit finding, where it arrives bundled with penalty framing and no negotiating room.
Agile PLM is not one product. It is a family of separately licensed modules, and each is licensed based on what you purchased. The technical enablement runs through a single license key entered at install, after which the administrator uses the Modules tab of the Licenses node to select the PLM solutions the company has purchased. Selecting a module enables the associated PLM Classes and functions; deselecting disables them. The core module set is broad and includes Product Governance and Compliance (PG&C), Product Portfolio Management (PPM, formerly Program Execution), Product Quality Management (PQM), Engineering Collaboration for CAD design data, Product Cost Management (PCM), and Product Collaboration (PC).
The compliance problem is that enablement runs on the honor system. When an administrator saves a module selection, Agile prompts: "Please verify your company is contractually licensed to use the modules selected." That prompt is the entire enforcement mechanism. Nothing in the software checks the module toggle against your actual ordering document. An administrator can enable Product Quality Management or Product Governance and Compliance with a mouse click and a system restart, and the software will happily run a module you never bought. Every enabled-but-unlicensed module is a clean audit finding priced at full list.
Agile's module enforcement is a checkbox and a warning message. Oracle's enforcement is a script that reads which modules are enabled and prices the gap at list.
There is a dependency trap layered on top. Product Portfolio Management is the only solution that can operate without Product Collaboration, but even a PPM-only shop will very likely need PC in practice. That means administrators enable adjacent modules to make workflows function, without anyone checking whether those modules sit on the contract. Over a decade of operation, module scope drifts upward through routine administration, upgrades, and well-meaning fixes. We break down which add-ons surface most often in the Agile PLM module sprawl audit findings guide, because the specific modules that get quietly enabled are predictable.
Agile PLM runs on an Oracle Database, and in most estates that database is licensed as Application Specific Full Use (ASFU). ASFU is a restricted-use license that lets you run Oracle technology only with a specific third-party application, at a lower price than Full Use. It carries the same technical capability as Full Use but confines it legally to the named application. The moment you use that database for anything else, you breach the grant. This is not a footnote. It is the single most expensive category of Agile-related finding we encounter, and it usually surprises the customer completely.
The economics explain why. ASFU and the related Embedded (ESL) license can cost 40 to 70 percent less than Full Use. That discount is exactly what makes the repurposing trap so costly. Buyers accept a cheap embedded database with Agile, then over the years connect corporate reporting tools, ETL jobs, custom development, or a second application to the same database, because it is right there and it holds valuable product data. Every one of those connections breaches the ASFU restriction, and Oracle prices the remedy at full Full Use list rates. The remedy for ASFU misuse is typically a full-price Full Use license purchase, not a modest adjustment. Our detailed treatment sits in the Oracle ASFU licensing explainer and the Agile-specific embedded database restricted-use guide.
The structural point buyers miss: under ASFU, you are the licensee, not the software vendor. Oracle audits its own customers of record, and an ASFU order makes you one, complete with a processor count Oracle can test against your servers. So the embedded database you may have thought of as "part of Agile" is in fact a direct Oracle database license on your books, fully auditable, with a processor metric Oracle will measure against your physical or virtual cores. Many manufacturers do not even have the ASFU restriction documented internally, which means their reporting and integration teams connect to the database with no idea a boundary exists.
| Common integration | ASFU compliant? | Oracle's remedy if found |
|---|---|---|
| Agile application reads and writes | Yes, this is the named use | None |
| Corporate BI or reporting tool querying the Agile DB | No | Full Use license purchase at list |
| ETL or data warehouse extraction from the Agile DB | No | Full Use license purchase at list |
| Custom application sharing the same database | No | Full Use license purchase at list |
| Second Oracle-based app on the same database | No | Full Use license, plus any options enabled |
There is a second layer inside the database itself. A Processor or NUP entitlement covers Oracle Database, not Oracle Database plus every option. Options such as Real Application Clusters, Partitioning, Advanced Security (Transparent Data Encryption), Active Data Guard, and Diagnostics Pack are separately licensed. If any of these are enabled on the Agile database, additional Processor-metric licenses are required for each. Diagnostics Pack and Partitioning are the two we see enabled by default or by a well-intentioned DBA far more often than they are licensed. An Agile database audit therefore has two blades: the ASFU boundary and the options usage, and Oracle runs both.
An Oracle Agile audit is not one measurement. It is three, run together, because Oracle knows the compliance surface is layered. First, the user count: Oracle establishes how many individuals are authorized, internal and external, and compares that against your NUP entitlement or your concurrent ceiling. Second, the module selection: Oracle reads which PLM solutions are enabled and prices any that lack a contractual basis. Third, the database: Oracle measures processor counts against the ASFU entitlement, tests whether the database serves anything beyond Agile, and checks which options are in use. Any single blade can produce a finding larger than your annual support bill.
In our experience defending these, the sequence matters. Oracle typically opens with a friendly "license review" or a Software Investment Advisory conversation before it formally invokes the audit clause, because a soft review lets it gather data you would be entitled to withhold under a formal audit's scoping rules. Do not volunteer database connection diagrams, module screenshots, or user extracts into an informal review. Everything you hand over informally becomes the baseline for the formal number. The discipline of a controlled evidence pack, prepared by you and scoped by you, is what caps exposure, and we lay out exactly what belongs in it in the Agile PLM audit defense evidence pack guide.
Oracle's soft license review exists to collect the data a formal audit would let you withhold. Treat every informal request as discovery.
The counting of external users deserves specific attention because it is where large manufacturers accumulate silent exposure. Suppliers, contract manufacturers, and distributors who touch Agile all consume licenses under the NUP metric, and supplier populations churn constantly while access is rarely deprovisioned. A supplier portal that once served 30 vendors and now nominally lists 400 authorized accounts, most dormant, is a finding waiting to happen. We treat external user counting as its own discipline in counting suppliers and external users in Agile PLM.
Agile PLM 9.3.6 is the final release, and Oracle has dated the end of Premier Support. This is the lever behind every Fusion migration conversation you are now having or about to have. Once mainstream support lapses, you face the familiar Oracle legacy pattern: no new patches, security exposure that grows over time, and a vendor that positions the cloud product as the only supported way forward. We have seen the identical playbook on Oracle iAS, where end of support was used as the primary migration accelerant and the audit risk of staying put was framed as inevitable.
Understand what the deadline does and does not mean. It does not mean your Agile licenses expire; perpetual licenses you own remain yours to run indefinitely. It does not mean the software stops working. It means Oracle stops shipping fixes and support, and it means Oracle's sales motion now has a burning platform to point at. The pressure is real but the choice is genuinely yours, and there are three viable paths: migrate to Fusion Cloud PLM, stay on-premise with third-party support, or run Agile as-is at reduced support cost while you plan. The right answer depends on the numbers, not on Oracle's timeline.
Migrating from Agile PLM to Oracle Fusion Cloud PLM is not a technical upgrade. It is a fundamental contractual reset, and it is where Oracle recovers the discount you enjoyed on a legacy perpetual estate. The core change: you move from perpetual licenses you own, with a database you already paid for, to a subscription you rent, priced per user per month, with no residual asset value. Your sunk investment in Agile perpetual licenses and the embedded ASFU database does not transfer as credit. In practice Oracle offers migration incentives, but those incentives are discounts off future subscription, not recognition of what you already own.
The user metric shifts too. Fusion PLM is licensed on hosted user metrics rather than NUP, and the definition of who counts can differ from Agile's authorization test. This is the same metric dynamic we document across Oracle's cloud applications, including in Oracle ERP Cloud hosted named user versus hosted employee, where the choice of metric drives a 20 to 35 percent swing in total cost. Before you accept a Fusion PLM proposal, model the subscription over a five to seven year horizon and compare it to the fully loaded cost of staying on Agile, including third-party support. Cloud subscriptions have no terminal value, so the comparison must run long enough to capture the crossover. We build that comparison in detail in migrating from Agile PLM to Oracle Fusion Cloud PLM.
Fusion PLM turns an asset you own into a subscription you rent. Model at least five years, because a cloud contract has no terminal value to offset against.
The most important negotiating point on migration: do not let an outstanding compliance gap set your migration price. Oracle's preferred sequence is to surface an audit finding, then present Fusion migration as the resolution, wrapping the compliance liability into a multi-year subscription. That converts a one-time exposure you might have negotiated down into an annuity you pay forever. Resolve or cap the compliance question separately and first, then negotiate migration on clean terms. Anything else lets Oracle price your past mistakes into your future run rate.
For many manufacturers, the rational move once Premier Support lapses is neither Fusion nor Oracle extended support. It is third-party support on a stable Agile estate you own outright. Independent support providers typically charge around half of Oracle's annual support fee and will maintain a mature, stable Agile deployment for years. If your Agile installation is doing exactly what you need and you have no functional requirement driving change, the arithmetic often favors staying put, paying a third party, and treating the perpetual license as the asset it is.
The decision hinges on two variables: how stable your Agile deployment is (a system you are not changing needs far less support) and how clean your compliance position is (leaving Oracle support does not extinguish Oracle's audit rights over your perpetual licenses and your ASFU database). Before you drop Oracle support, close every module and database gap, because an audit can still land and you will no longer have a support relationship to soften the conversation. We work through the full decision in Agile PLM on third-party support. The related metric-and-trap analysis on Oracle JD Edwards licensing is worth reading alongside it, because Oracle applies the same conversion and audit patterns across its legacy application portfolio.
Strip away the detail and the Agile PLM position resolves to a clear map. Your leverage sits in three places. First, perpetual license ownership: you own the software and Oracle cannot take that away, which means you are never forced onto Fusion by anything other than commercial persuasion. Second, a legacy concurrent grant if you hold one, because it is an asset Oracle can no longer sell and must convert on terms. Third, timing: as long as you resolve compliance before the migration conversation, you control the sequence, and sequence is most of the negotiation.
Your risk sits in three matching places. First, the embedded ASFU database, where a single reporting connection can produce a Full Use finding measured in six or seven figures. Second, module sprawl, where a decade of honor-system toggling has enabled solutions you never bought. Third, uncounted users, particularly dormant suppliers and shared shop-floor credentials. Every one of these is fixable before an audit and expensive after one. The entire buyer-side strategy for Agile PLM reduces to a single instruction: measure your own estate against your own contracts, close the gaps on your timeline, and never let Oracle's soft review or migration pitch surface those gaps for you.
You own perpetual Agile licenses and you control the clock. Oracle owns the audit script. Whoever measures the estate first sets the number.
The manufacturers who come through Agile audits and migrations with their budgets intact are the ones who did the reconciliation work before Oracle arrived. They knew their authorized user count to the head, they could prove every enabled module against an ordering document, and they had disconnected every non-Agile tool from the ASFU database. That preparation is unglamorous and it is the whole game. If you take one action from this guide, run the three-blade self-audit now: users, modules, database. Whatever it costs you in effort, it is a fraction of what an uncontrolled Oracle finding will cost you at list.
Oracle's contractual metric is Named User Plus (NUP), applied to each individual authorized to access the environment, internal or external. Authorization triggers the license, not usage frequency, so a supplier who logs in twice a year still counts. The concurrency counts shown in the Agile console are a technical control, not your contractual position, unless your specific ordering document is a legacy concurrent grant.
The database is usually licensed as Application Specific Full Use (ASFU), which is restricted to running only the Agile application at a 40 to 70 percent discount off Full Use. Connecting any reporting tool, ETL job, custom application, or second system to that database breaches the restriction. Oracle prices the remedy at full Full Use list rates, and because you are the licensee of record, Oracle audits you directly.
No. Premier Support ending for Agile 9.3.6 does not expire your perpetual licenses or stop the software running. You have three viable paths: migrate to Fusion, move to third-party support at roughly half Oracle's annual fee, or stay on Oracle terms while you plan. The right choice depends on a five to seven year cost model, not Oracle's deadline.
Agile modules are licensed separately but enabled through a checkbox in the Licenses node, with only a warning prompt asking you to verify you are licensed. Nothing in the software checks the toggle against your contract. Over years of administration and upgrades, modules like Product Quality Management or Product Governance and Compliance get enabled without a purchase behind them, and each one is a clean audit finding at list price.
Oracle cannot take an existing concurrent grant away, but it has phased out the concurrent metric across its product line, so you generally cannot buy additional concurrent capacity. Any growth forces conversion to Named User Plus, often on your entire base, and Oracle prefers to trigger that conversion during a true-up or audit. Protect the concurrent grant as an asset and negotiate any conversion terms in advance.
Treat any informal license review or Software Investment Advisory contact as discovery, because it lets Oracle gather data a formal audit would allow you to withhold. Do not volunteer user extracts, module screenshots, or database diagrams. Route the request through procurement and legal, and build your own scoped evidence pack covering users, modules, and database usage before Oracle scripts anything.
Siebel is licensed on authorization across several user metrics, grants access through responsibilities and custom views, and sits under Oracle lifetime support. The traps and the
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.
