What records does OpenText copy in an ALM audit

OpenText gives seven days notice before an audit and the right to copy relevant records. In an ALM audit the word that decides the size of the finding is relevant, because the records OpenText reaches for, user lists, project inventories, license server logs, and deployment data, are exactly the inputs that determine how many named or concurrent users the audit will charge for. Controlling what is copied, and on what basis, is the first defensive move.

An ALM estate is data rich. Application Lifecycle Management, Quality Center, ALM Octane, LoadRunner, UFT, and the wider DevOps toolset that came to OpenText through the Micro Focus acquisition each keep their own user records, license records, and usage logs, and an audit assembles its finding from those records. Knowing which records are genuinely relevant to the licensed metric, and which merely look incriminating when pulled out of context, is what separates a defensible copy scope from a fishing expedition. The right of OpenText to copy relevant records is real, but relevant is a limit, not a blank cheque.

The records an ALM audit typically asks to copy

In most ALM engagements the audit asks for a recognisable set of records. The first is the user inventory: every account provisioned across ALM, Quality Center, and Octane, often exported straight from the site administration console. The second is the license configuration: the license server records, the named user assignments, and the concurrent license pool definitions. The third is deployment data: how many servers, environments, and instances are running, including non production systems. The fourth is usage data: login records, session logs, and the concurrency history that shows how many users were actually active at once.

Each of these records can support a finding or undermine one, depending on how it is read. A raw user inventory looks like a named user count, but it includes leavers, service accounts, and duplicates that should never reach the finding. License server logs look like a concurrency overage, but they also contain the peak simultaneous session data that proves the concurrent pool was never exceeded. The records that the audit wants to copy are the same records the defense needs, which is why they must be preserved and read carefully rather than handed over and interpreted by the vendor alone.

Why relevant is the word that limits the copy

The grounding right is narrow on its face: OpenText may copy records relevant to verifying the license position. Relevance ties the copy to the licensed metric. If ALM is licensed by named user, the records relevant to the count are the user inventory and the entitlement, while raw network traffic or unrelated system data is not relevant. If LoadRunner is licensed by Vuser, the relevant record is the test configuration and the peak Vuser figure, not every test that ever ran. A copy scope that reaches beyond the licensed metric is reaching beyond what relevance allows, and that boundary is a defensible position rather than an obstruction.

The decommissioned and the dormant deserve particular attention here, because audits routinely copy records for systems that no longer run. A project that was retired, an environment that was torn down, or an account that was disabled may still appear in an old export, and counting it inflates the finding. The discipline of separating live records from historical ones is the same discipline set out in decommissioned ALM projects still on the audit, and it begins at the moment records are copied, not weeks later when the finding arrives.

How the records map to the count

The reason the copy scope matters so much is that each record maps directly to a counting method, and the wrong record produces the wrong count. A named user finding rests on the user inventory, so the inventory must be cleaned of accounts that are not licensable before it becomes a count, the work described in named versus concurrent user counting in ALM audits. A concurrent finding rests on the session logs, so the peak simultaneous session figure must be drawn from those logs rather than assumed from headcount, the method in how to challenge an ALM concurrent user headcount.

Deployment records carry their own exposure, because an audit that copies a list of environments may count non production systems that the license never intended to charge for, a problem examined in LoadRunner non production and test environment scope. The copied record is neutral; the interpretation is where the finding is built, and the interpretation is what the buyer must control.

How we defend the copy scope under the four Rs

Respond. The seven day notice clock starts immediately, and within that window we take over the single controlled channel and define what relevant means for this estate before any record leaves the building. We preserve the user inventory, the license records, the deployment data, and the usage logs together, so the records that prove the defensible count are not lost while the records that support the finding are produced.

Reconstruct. We build the effective license position against entitlements and the Additional License Authorizations independently, using the same records the audit copies but reading them for the licensed metric: a clean user count for a named model, a peak concurrency figure for a concurrent one.

Rebut. We challenge any copy scope that reaches beyond the licensed metric and any count built on uncleaned records, presenting the inventory stripped of leavers and service accounts, the concurrency logs that cap a concurrent finding, and the deployment data that excludes retired systems.

Resolve. We settle on the count the relevant records actually support and, where it serves you, convert forward into an OpenPass agreement that records which metric governs ALM and which records are relevant to verifying it, so the next review cannot widen the copy scope to inflate the finding.

An anonymised outcome

The records matter because the remedy that follows a finding 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 a count built on records that were never cleaned multiplies the error across every charge. Our anonymised case files show what disciplined reading achieves: an insurance ECM seat count finding fell from $7.2M to $1.6M, a 78 percent reduction built on disqualifying accounts that the raw inventory had treated as licensable. An ALM finding answers to the same correction, because the count is only as defensible as the records it rests on.

Control the copy before you defend the count

The durable point is that an ALM audit is shaped at the moment records are copied, because relevant is a limit and the records the vendor reaches for are the same records the defense needs. A buyer who defines relevance, preserves the full record set, and reads it for the licensed metric holds the finding to what the data genuinely supports. To build the position, read named versus concurrent user counting in ALM audits, how to challenge an ALM concurrent user headcount, and decommissioned ALM projects still on the audit. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If an ALM audit notice has arrived and records are being requested, open a case.