Concurrent vs Named User vs Processor Licensing:
Which Metric Works Best and When

Why Licensing Metrics Matter More Than Licence Counts

When procurement teams negotiate enterprise software contracts, the conversation almost invariably focuses on price per unit and total volume. The licensing metric — the mechanism that defines what a "unit" actually is — receives far less scrutiny, even though the choice of concurrent vs named user vs processor licensing often determines whether the final contract is commercially rational for the organisation or commercially optimal for the vendor. Understanding the difference between these metrics, and knowing when each one benefits the customer versus the vendor, is the foundation of any competent enterprise software negotiation.

The metric question is particularly consequential because vendors choose their preferred metrics strategically. Oracle moved from processor-based to named user licensing for Java SE in 2023 specifically because the named user model generates substantially higher revenue from large enterprises that had previously been paying processor fees on a small number of servers. Broadcom's post-acquisition restructuring of VMware licensing shifted from per-VM to per-core processor licensing — another deliberate metric change designed to maximise revenue from existing customer bases. Recognising the pattern behind these choices allows procurement and SAM teams to anticipate the commercial logic and negotiate accordingly. The enterprise software negotiation leverage guide covers the broader strategic framework; this article focuses on the mechanics of metric selection.

Concurrent User Licensing: How It Works and When It Favours the Customer

Concurrent user licensing charges for the maximum number of users simultaneously active in a system at any given time, rather than the total number of users with access rights. A 100-concurrent-user licence allows any number of named individuals to hold accounts in the system, but limits simultaneous active sessions to 100. If the 101st user attempts to log in while all 100 slots are occupied, they are typically queued or denied access until a slot becomes available.

This model strongly favours customers with shift-based or geographically distributed workforces where simultaneous system usage is structurally limited. A global manufacturing organisation with 3,000 employees using an ERP system across three time zones may have a peak concurrent session count of only 400 users — meaning a concurrent licence for 400 covers the same business requirement as a named user licence for 3,000. At comparable per-unit pricing, the saving is an order of magnitude. For shelfware identification purposes, concurrent licensing also naturally self-corrects: unused capacity does not accumulate in the same way as dormant named user accounts, because the licence pool is consumed dynamically rather than allocated statically.

The challenge with concurrent licensing is that vendors have progressively moved away from it in their standard terms, or introduced access complexity that makes the concurrent model difficult to administer. SAP still offers concurrent user licences for some professional user types, but the default commercial offer is named user. Legacy on-premise deployments of IBM Rational and SPSS tools were historically sold on concurrent terms; the cloud equivalents are almost universally named user or consumption-based. When a vendor's current portfolio no longer includes a concurrent option, the contractual leverage to negotiate it back in depends on the strength of the customer's position and the vendor's need for renewal.

Named User Licensing: The Vendor Default and Its Hidden Costs

Named user licensing is the dominant model across SaaS enterprise software and has become the default for most on-premise renewals. It charges per provisioned account, regardless of how frequently that account is used. From the vendor's perspective, this is an ideal commercial model: revenue is tied to headcount, which for most enterprises grows slowly and predictably; there is no technical mechanism to automatically reduce licence consumption when users leave or change roles; and the administrative burden of deprovisioning falls entirely on the customer.

The named user model creates a specific shelfware risk that concurrent licensing does not: the provisioned-but-inactive account. In a large Salesforce deployment, it is routine to find 15–25% of provisioned user licences associated with accounts belonging to former employees, contractors whose engagements have ended, or staff who transferred roles and no longer need CRM access. These accounts continue to consume licence entitlement and generate billing unless explicitly removed. The software licence position document for any named-user product should include a quarterly deprovisioning audit as a mandatory process step, not an optional one.

Named user licensing is genuinely the most cost-efficient model when the use pattern justifies it. A Workday HCM deployment where every employee actively uses self-service modules daily, or a Microsoft Teams deployment with near-universal adoption, represents a case where named user pricing is appropriate: the licence cost reflects real, continuous value delivered to each individual seat. The problem arises when named user pricing is applied to tools with irregular, sporadic, or seasonal usage patterns — where the same licence spend would purchase far more capacity under a concurrent or consumption model. The negotiation objective is to identify the mismatch and either renegotiate the metric or restructure the tier allocation so that high-frequency users are on full named user licences and low-frequency users are on a less expensive limited user tier.

Processor and Core-Based Licensing: When Infrastructure Is the Right Unit

Processor-based licensing charges for the physical or virtual CPU capacity on which the software runs, regardless of how many users access it or how often. It is the dominant model for database software, middleware, and any technology layer that processes transactions programmatically rather than through direct user interaction. Oracle Database Enterprise Edition is priced on a per-processor basis (with a core factor applied to each processor family). IBM Db2 uses PVU (Processor Value Unit) licensing, where each physical core is assigned a PVU value based on processor type and the total PVU count determines the licence requirement. Broadcom's VMware vSphere pricing, following the 2024 commercial restructuring, moved to a per-core model.

Processor licensing is commercially rational for workloads where user count is irrelevant — automated batch processing, API integration layers, data replication services, and machine-generated transaction processing. For these use cases, a named user licence is nonsensical; the software has no concept of a human user. Processor licensing charges for what is actually being consumed: compute capacity. The customer advantage is that a single processor licence can theoretically support unlimited users, which makes processor licensing extremely cost-effective for high-concurrency, low-compute workloads. The vendor advantage is that processor licensing scales with infrastructure investment: as customers modernise to higher-core-count processors or expand virtualised capacity, licence costs increase automatically without requiring any change in headcount.

The critical negotiation point for processor-based licensing is the virtualisation policy. Oracle, for example, does not recognise VMware as a hard partition boundary for licensing purposes — meaning an Oracle Database licence must cover all physical processors on a VMware host, not just the virtual cores allocated to the Oracle workload. This policy has been the source of more audit disputes in enterprise Oracle deployments than any other single contractual issue. Understanding the virtualisation rules before committing to a processor-based metric — or before migrating an existing workload to a new infrastructure — is essential. The internal software audit methodology should specifically include a processor licence mapping step that accounts for the virtualisation policies of each major vendor in the estate.

Negotiating Metric Flexibility: How to Change the Metric Mid-Contract

Most enterprise software contracts define a single licensing metric for the term of the agreement, with no built-in right to switch metrics at renewal. Vendors prefer this rigidity because it limits the customer's ability to optimise commercially. The practical question is how to introduce metric flexibility at the point of renewal — or, in some cases, how to renegotiate the metric within an existing contract when the original metric has become clearly misaligned with the organisation's actual usage pattern.

The strongest lever for metric renegotiation is usage data. If you can demonstrate — through 12 months of telemetry — that your peak concurrent session count represents only 25% of your named user licence count, or that your processor utilisation is consistently below the threshold that would trigger a higher licence tier, the data provides a factual basis for the commercial conversation. Vendors are more likely to agree to metric changes when the alternative is a non-renewal or a competitive displacement, and framing the metric change as a right-sizing exercise that preserves the commercial relationship is more effective than framing it as a cost-reduction demand.

Including metric flexibility clauses in initial or renewal contract terms is the most durable solution. These clauses allow the customer to switch between defined metric options — for example, between named user and concurrent user for a specific product — at renewal without requiring a commercial renegotiation. Vendors are resistant to these clauses because they reduce revenue predictability, but they are achievable with the right advisory support and negotiating position. Redress has negotiated metric flexibility provisions for over 500 enterprise clients across Oracle, SAP, Microsoft, Salesforce, and ServiceNow. The enterprise licensing white papers available from Redress cover the specific contract language and negotiation playbooks for each major vendor's metric model.