Documentum server deployment counting in an OpenText audit

Not every Documentum finding is driven by users. Where the product is licensed by server, instance, or processing capacity, an OpenText audit counts deployments, and the same patterns of double counting and non production exposure apply to machines that apply to people.

Documentum components can carry deployment based metrics: a Content Server instance, a processing tier, or a capacity measure expressed in cores or CPUs. When that is the licensing model, the audit enumerates running instances across the estate and prices any deployment it cannot match to an entitlement. As with user counts, the raw enumeration tends to overstate what should actually be charged, because it sweeps in environments that are not production workloads.

What gets counted as a server deployment

An OpenText audit will typically discover every Content Server instance it can reach, along with associated components, and treat each as a deployment requiring a license. The discovery does not distinguish between a production system serving the business and the supporting environments that surround it: development, test, staging, disaster recovery, and temporary instances spun up during migration. To the count, a running process is a running process.

The defensible position is that the licensing model and the entitlement language define which deployments are chargeable, not the mere fact that a process is running. The way capacity and instance metrics are measured matters a great deal here, and we set out the detail in Content Server CPU and instance based metrics explained.

Non production environments are the main battleground

The largest opportunity in a server count is usually the supporting environments. Development and test instances exist to build and validate change, not to serve production load. Many agreements treat them differently from production, and some allow them under the same entitlement when they are not used for live work. An audit that prices every instance at production rates ignores this entirely. We cover the argument in full in Documentum non production environments and license claims.

Disaster recovery instances

Disaster recovery deserves particular attention. A passive standby instance that exists to take over only if production fails is not a second production workload. Depending on the entitlement, a cold or warm standby may be covered by the production license rather than requiring its own. Counting the standby as a full additional deployment can double the server charge for a single workload. The specifics are covered in Documentum disaster recovery instances and licensing.

Defending the deployment count under the four Rs

Respond. Within the seven day notice window we establish a single controlled channel and make sure the audit does not enumerate every instance it can reach and present the total as your licensable footprint. Discovery output is a starting point for analysis, not an agreed baseline.

Reconstruct. We build an independent inventory of deployments classified by role: production, development, test, staging, disaster recovery, and transient migration instances. Each is mapped to the entitlement language that governs it and to the relevant capacity metric. This is the deployment equivalent of the user reconciliation described in how to reconcile Documentum entitlements before an audit.

Rebut. We challenge the count instance by instance. Non production environments are argued under the terms that apply to them. Disaster recovery standbys are tested against the production entitlement. Transient migration instances that no longer exist are removed. Capacity measures are checked against the correct metric rather than a worst case reading.

Resolve. With the deployment count corrected, we settle on buyer terms and, where useful, convert forward into an OpenPass agreement that defines the deployment and capacity metrics and writes in protections for non production and disaster recovery.

Why the correction matters

Server and capacity charges are large per unit, so each removed instance is worth far more than a single user line. A workload that the audit counts as four chargeable deployments may be one production system plus development, test, and a standby, three of which can frequently be defended. Correcting the classification can reduce the server portion of a finding dramatically before any negotiation on price even begins.

The same discipline that closes a Documentum user gap closes a deployment gap. In our anonymised insurance engagement, case file E-01, a Documentum finding fell from $7.2M to $1.6M, a 78 percent reduction, once the estate was reconstructed and priced to what was genuinely chargeable rather than to everything the audit could discover.

Reading the entitlement before accepting the metric

The most common error a buyer makes with a server count is to accept the metric the audit applies without checking it against the agreement. Documentum components have been licensed in several ways over the years, and a finding will tend to apply the reading that produces the largest number. Whether a deployment is measured by instance, by physical core, by virtual core, or by some processing capacity figure changes the charge substantially, and the correct measure is the one the entitlement specifies, not the one the discovery tool reports.

Virtualization makes this sharper. A Content Server instance running on a virtual host may be counted against the full physical capacity of the underlying hardware rather than the capacity actually allocated to it, which can inflate a capacity based charge dramatically. Whether the agreement permits allocation based counting, or requires full physical counting, is a question to settle from the contract, not from the audit output. The same applies to clustered deployments, where the count can either reflect the genuine processing footprint or every node the cluster could in principle use.

There is also the matter of what counts as a separate deployment at all. A single logical workload may be spread across components that the discovery treats as independent instances. Mapping the components back to the workloads they serve, and to the entitlements that cover those workloads, prevents one system from being counted as several. This is the deployment analogue of collapsing duplicate user identities, and it is just as effective at removing lines from a finding.

None of this is argument for its own sake. Each point is a place where the entitlement language and the metric definition can be set against the audit reading, and where a documented, contract based position will hold. The vendor prices from the largest defensible interpretation. The buyer corrects to the interpretation the agreement actually supports.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026 and our ECM and Documentum audit defense track. If an audit has enumerated your servers and you need the deployment count classified before it is priced, open a case and we will build the independent inventory.