LoadRunner Cloud and on demand Vuser models

LoadRunner Cloud and on demand Vuser models meter consumption over time rather than holding a fixed perpetual pool, and an audit that treats a flexible, time bound entitlement as though it were a standing capacity charges for headroom the buyer never owned. Defending these findings means reading the actual model in the agreement and showing what was genuinely consumed against it.

The performance testing line offers more than one way to acquire Vusers. A perpetual pool grants a standing number of concurrent virtual users the buyer owns outright, while LoadRunner Cloud and on demand arrangements provide Vusers as a flexible, often subscription or consumption based resource drawn down over a defined term. The two are metered differently, and a finding that applies perpetual pool logic to an on demand subscription, or vice versa, misstates the entitlement at the root. Because most of the estate is governed by the Additional License Authorizations, the model that actually applies is a question of reading the authorizations, not assuming the more expensive interpretation.

How the on demand model differs from a perpetual pool

A perpetual Vuser pool is sized by concurrent capacity: the buyer owns the right to run up to a set number of simultaneous virtual users, and the defense centres on peak concurrency, the approach set out in reducing a LoadRunner finding with concurrency evidence. An on demand or cloud model, by contrast, meters consumption against a subscription, so the relevant questions become what term applies, what consumption the subscription allowed, and whether usage stayed within it. An audit that counts an on demand subscription as though it were a perpetual concurrent pool, or that ignores the term boundaries, builds the finding on the wrong meter entirely.

The starting point in either case is the definition of the Vuser itself and how it is licensed, the ground covered in what is a Vuser and how is it licensed. Once the unit is clear, the model determines how it is counted, and the model is fixed by the agreement. The same inflation that arises from counting provisioned rather than concurrent capacity, explained in how Vuser counting inflates a LoadRunner finding, reappears here when a flexible subscription is read as a standing pool.

Where the model decides the finding

The decisive question in a cloud or on demand finding is which model the agreement actually grants, because the entitlement that governs a subscription is not the entitlement that governs a perpetual pool. The agreement and the Additional License Authorizations define the term, the consumption allowance, and the metric, and reading them against the actual usage is what fixes the count. This is the same authorization reading discipline applied across the estate and described in reconciling ALM entitlements before an audit.

Term boundaries matter as much as the metric. An on demand subscription covers a defined period, and consumption outside that period, or capacity assumed beyond the subscription, is not part of the entitlement the audit can measure against. Whether a momentary peak can be counted at all is a further question explored in can OpenText count peak Vusers against your license, and it bears directly on how a flexible model is read.

How we defend a cloud or on demand finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. We take over the single controlled channel and ensure the subscription agreement, the term records, and the consumption data are preserved together, because the model that applies is fixed by those documents.

Reconstruct. We build the effective license position against the Additional License Authorizations before any vendor script runs, establishing whether the entitlement is a perpetual pool or an on demand subscription and matching the consumption to the term that governs it.

Rebut. We challenge every line that applies perpetual pool logic to a subscription, or that counts consumption outside the term, presenting the agreement and the usage data for each. The finding falls by the difference between the model asserted and the model granted.

Resolve. We settle on the count that reflects the genuine model and consumption, and where it serves you, convert forward into an OpenPass agreement that records the Vuser model, the term, and how consumption is measured, so the next review cannot reinterpret the meter.

An anonymised outcome

The reason the model question is worth settling is the remedy that follows a finding. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so reading a flexible subscription as a standing pool multiplies the error across every charge at once. Our anonymised case files show what correcting the basis of a finding can do: a banking ArcSight finding was reduced from $6.0M to $1.8M, a 70 percent reduction built on measuring real activity rather than assumed capacity. A LoadRunner cloud or on demand finding responds to the same correction, because the agreement fixes the model the audit must use.

Read the model before you accept the meter

The lasting point is that LoadRunner Cloud and on demand Vuser models are not perpetual pools, and a finding that confuses the two can be taken apart by reading the agreement and the consumption against it. A buyer who knows which model the entitlement grants, and what term and allowance apply, holds the finding to the meter that was actually purchased. To build the position, read what is a Vuser and how is it licensed and reducing a LoadRunner finding with concurrency evidence, alongside LoadRunner protocol bundles and license scope and Performance Center versus LoadRunner Enterprise licensing. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a LoadRunner finding has misread your Vuser model, open a case.