How OpenText measures ALM in a self assessment

Before a formal audit reaches its later stages, OpenText frequently asks the licensee to run a self assessment, a measurement script or questionnaire that gathers ALM deployment data and returns it to the vendor. Understanding how OpenText measures ALM in a self assessment is the difference between handing over a number that frames the whole negotiation against you and producing one you have already verified and can defend.

A self assessment looks cooperative and low risk, which is exactly why it deserves care. The data it returns becomes the opening figure in the finding, and once a number leaves the building it is very hard to unsay. OpenText runs a global software compliance team with executive sponsorship, and its Compliance Managers prepare entitlement and support reviews and then run the true up negotiation from whatever the measurement produced. Because the EULA places compliance on the licensee, the obligation to get the count right sits with the buyer, and that obligation is also the opportunity: a self assessment that the buyer has scoped, reviewed, and reconciled before submission is a far stronger starting point than raw output sent without examination.

What an ALM self assessment collects

An ALM self assessment typically gathers the user records, the project and environment inventory, and the deployment topology, and for LoadRunner it reaches into Vuser configuration and peak usage data. The script reads what the system can report, not what the entitlement permits, so it returns provisioned accounts whether or not they are active, it lists projects whether or not they are still in use, and it captures environments without distinguishing production from the test and staging instances that may carry different rights. The output is a snapshot of everything the tooling can see, and the gap between that snapshot and the defensible position is precisely where a finding inflates.

The measurement does not, on its own, apply the user model. It will report a count of named accounts, but it does not know whether a given license is named or concurrent, and that distinction is the single largest driver of an ALM finding, as set out in named versus concurrent user counting in ALM audits. A raw self assessment that reports total provisioned accounts against a concurrent entitlement overstates the requirement before anyone has looked at it.

Where the ALM self assessment overstates

Provisioned accounts read as active users

The script counts accounts, not active users, so dormant and departed identities flow straight into the total. Removing them with activity evidence before submission is the same discipline applied later in documenting concurrent ALM users for a rebuttal.

Environments counted without scope

Self assessments list every environment the tooling finds, including non production instances that may not require the same licensing as production. Establishing which environments genuinely count is the question addressed in LoadRunner non production and test environment scope.

Peak Vuser figures taken as the requirement

For LoadRunner the script can report the highest Vuser figure it observes, and a single short burst can set the number unless it is separated from sustained use, the argument made in reducing a LoadRunner finding with concurrency evidence.

How we defend an ALM self assessment under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. When a self assessment request arrives, we take over the single controlled channel and ensure nothing is run or returned before the scope is agreed and the buyer understands what each field will reveal.

Reconstruct. We run the measurement ourselves first, against entitlements and the Additional License Authorizations, so the buyer sees the raw output and the verified position side by side before any figure is shared, and before any vendor script runs in a way the buyer cannot review.

Rebut. We resolve every overstatement at source: deduplicating users, classifying environments, separating peak Vuser bursts from sustained load, and matching each count to the correct user model, so the number that goes back is already the defensible one.

Resolve. We settle on the verified figure and, where it serves you, convert forward into an OpenPass agreement that defines how ALM will be measured in future, so the next self assessment cannot reopen questions already settled.

An anonymised outcome

The reason a clean self assessment matters is the remedy waiting behind the 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 an inflated self assessment does not just raise the license figure, it multiplies the entire stack. Our anonymised case files show what disciplined measurement recovers, including a banking ArcSight finding reduced from $6.0M to $1.8M, a 70 percent reduction once burst was separated from sustained. An ALM self assessment responds to the same approach: verify before you submit, and the inflated figure never becomes the opening position.

Verify the measurement before it leaves the building

The lasting lesson is that a self assessment is not a neutral data request, it is the first move in the negotiation, and the buyer who treats it as such controls the number that frames everything after. Running the measurement internally, reconciling it against entitlements, and correcting every overstatement before submission turns a risk into an advantage. To prepare that groundwork, read reconciling ALM entitlements before an audit and what records does OpenText copy in an ALM audit. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If a self assessment request has arrived and you have not yet run it, open a case.