Performance Center versus LoadRunner Enterprise licensing

Performance Center was the server based, web enabled edition of the LoadRunner family, and it was rebranded as LoadRunner Enterprise. The rename is more than cosmetic for audit purposes, because an audit can apply the metric of one to a deployment licensed under the other, or treat a renamed product as a new entitlement requirement. Understanding that Performance Center and LoadRunner Enterprise are the same lineage, governed by the Vuser metric, is what keeps a finding from charging twice for one product.

LoadRunner Enterprise, the product that the market knew for years as Performance Center, came to OpenText through the Micro Focus acquisition as part of a performance testing family that also includes the desktop LoadRunner and the cloud editions. The continuity matters: an organisation that licensed Performance Center and now runs LoadRunner Enterprise holds one entitlement lineage, not two, and an audit that does not carry that continuity forward can read the rename as evidence of an unlicensed product.

How Performance Center and LoadRunner Enterprise relate

Performance Center was the enterprise, centrally managed edition of LoadRunner, providing a web interface, scheduling, and shared load generators for teams running performance tests at scale. LoadRunner Enterprise is the same product under a current name, retaining the central management model and the Vuser based licensing that has always governed the family. The chargeable unit across both is the Vuser, the simulated user that generates load, the metric explained in what is a Vuser and how is it licensed. A rename does not reset the metric, and a deployment that ran under a Performance Center entitlement continues under the same Vuser basis as LoadRunner Enterprise.

The components that make this a centrally managed product, the controller that orchestrates tests and the load generators that produce traffic, carry their own licensing questions, set out in LoadRunner Enterprise controller and load generator licensing. Those questions are the same whether the installation is labelled Performance Center or LoadRunner Enterprise, because the architecture did not change with the name.

Where the rename decides the finding

The decisive question is whether the entitlement and the deployment are read as one continuous license or as two products. An organisation that purchased Performance Center Vusers and upgraded to LoadRunner Enterprise holds those Vusers under the current name, and the finding should rest on the Vuser entitlement, not on a double count that treats the old and new labels as distinct. Reconciling the entitlement history against the current deployment is the discipline that establishes the continuity, the work set out in reconciling ALM entitlements before an audit.

Once continuity is established, the finding turns on the same Vuser questions that govern any LoadRunner deployment: the sustained level the estate runs, the brief bursts that stress tests create, and the environments the tests run in. Scoping those bursts correctly is the subject of how to scope LoadRunner Vuser bursts, and the same scoping applies whether the product is named Performance Center or LoadRunner Enterprise, because the metric is the Vuser in both.

How the lineage maps to the count

The reason the rename can inflate a finding is that an audit working from product names rather than entitlement lineage may see two products in the records, one historical and one current, and count Vuser capacity against each. The defensible reading carries the Performance Center entitlement forward as the same license that now runs as LoadRunner Enterprise, so the Vuser capacity is counted once. Shifting the basis from product label to entitlement lineage is the core of the rebuttal, and it depends on the purchase and upgrade history rather than on the names in the current deployment.

This continuity reasoning sits alongside the wider comparison of how the LoadRunner family is licensed across its editions, including the cloud and on demand models, the subject of LoadRunner Cloud and on demand Vuser models. A single estate may run more than one edition, and reading them as one Vuser based family rather than as separate products is what keeps the count honest.

How we defend a Performance Center finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records, and the seven day notice clock starts immediately. Within that window we take over the single controlled channel and preserve the entitlement history, the upgrade records, and the current deployment data together, so the continuity from Performance Center to LoadRunner Enterprise is documented rather than lost.

Reconstruct. We build the effective license position against entitlements and the Additional License Authorizations independently, carrying the Performance Center Vuser entitlement forward as the LoadRunner Enterprise license it became, and establishing the single Vuser capacity the estate genuinely runs.

Rebut. We challenge every line that treats the rename as a second product or applies a different metric across the lineage, presenting the entitlement history that shows one continuous Vuser license. The finding falls by the duplicate count.

Resolve. We settle on the single Vuser count the lineage supports and, where it serves you, convert forward into an OpenPass agreement that records the product under its current name and how its Vusers are measured, so the next review cannot resurrect the old label as a separate entitlement.

An anonymised outcome

The lineage matters because the remedy is severe. 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 counting one product as two multiplies the error across every charge. Our anonymised case files show what correcting the basis of a count achieves: an insurance ECM seat count finding fell from $7.2M to $1.6M, a 78 percent reduction built on counting only what genuinely belonged in the finding. A Performance Center finding answers to the same correction, because a renamed product is not a new entitlement.

Carry the lineage forward before you accept the count

The durable point is that Performance Center and LoadRunner Enterprise are one product governed by the Vuser metric, so a finding is defended by carrying the entitlement lineage forward rather than counting the rename as a second license. A buyer who documents the continuity and produces the single Vuser capacity holds the finding to one product. To build the position, read what is a Vuser and how is it licensed, LoadRunner Enterprise controller and load generator licensing, how to scope LoadRunner Vuser bursts, and LoadRunner Cloud and on demand Vuser models. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a finding counts Performance Center and LoadRunner Enterprise as two products, open a case.