Content Server CPU and instance based metrics explained

Where a Documentum deployment is licensed by the hardware it runs on rather than by the people who use it, the metric shifts from named seats to processors, cores, or instances. Those metrics carry their own traps, and a finding built on them can charge for capacity the business never deployed for Documentum.

Not every Documentum charge is a user count. The Content Server, the engine at the centre of a Documentum estate, can be licensed against the infrastructure it runs on, measured by processors, by cores, or by the number of instances deployed. Capacity based metrics like these are attractive to a vendor because modern hardware is dense, virtualisation multiplies the apparent footprint, and the numbers can be read in ways that favour the higher figure. For a buyer, understanding exactly what the metric counts, and on what hardware, is the difference between a charge tied to genuine Documentum capacity and one inflated by the way servers are configured. Because the OpenText EULA places compliance on the licensee, that analysis is the buyer's to perform.

What a capacity based Content Server metric measures

A processor or core based metric ties the license to the computing capacity available to the software. In principle that is a reasonable basis: more capacity can serve more work. In practice the question of what capacity counts is far from simple. A physical server may have many cores, only some of which are made available to the Content Server. A virtual environment may present a slice of a much larger host, and the metric has to decide whether to count the slice the software can use or the whole host it sits on. An instance based metric counts running deployments, and there the question is what constitutes a separate instance versus a single logical deployment spread across nodes. Each of these choices moves the number, sometimes dramatically.

The principle a buyer should hold to is that the metric should reflect the capacity actually allocated to Documentum, not the maximum capacity of the surrounding hardware. A finding that counts every core on a large virtualisation host, when Documentum runs in a constrained partition, is charging for capacity the business deployed for everything except Documentum. Establishing the genuine allocation is the substance of the defense.

Where CPU and instance counting inflates a finding

Full host counted instead of allocated capacity

In a virtualised estate, counting every core on the host rather than the cores allocated to the Documentum partition overstates the licensable capacity, sometimes by a large multiple. The allocation, not the host size, is what should drive the count.

Clustered nodes counted as separate instances

A Content Server deployed across several nodes for performance or resilience can be read as several instances. Whether those nodes are one logical deployment or several chargeable ones is exactly the question that arises for recovery copies in Documentum disaster recovery instances and licensing and for deployments generally in Documentum server deployment counting in an OpenText audit.

Non production capacity swept into the count

Development, test, and staging servers carry capacity too, and a metric that does not separate environments counts their cores and instances alongside production. The case for a production boundary is set out in Documentum non production environments and license claims.

Defending a capacity metric under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. In that window we take control of the channel and ensure the hardware and virtualisation configuration is documented as the measurement runs, so the count is not built on raw host specifications.

Reconstruct. We build the effective license position independently. We establish the capacity genuinely allocated to the Content Server in each environment, document the virtualisation boundaries, determine which nodes form a single logical deployment, and separate production capacity from non production. The reconstructed position counts the capacity Documentum actually uses.

Rebut. We challenge the finding line by line. Where the count rests on the full host, we show the allocated capacity. Where clustered nodes have been counted as separate instances, we establish the logical deployment. Where non production capacity has been swept in, we scope it out. Each correction rests on the configuration evidence and the metric definition.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that records how capacity is measured, including how virtualisation and clustering are treated, so the next audit cannot rebuild the count from the hardware specifications.

An anonymised outcome

The financial logic is the standard remedy that makes an inflated capacity count expensive. 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 of the audit, so overstating cores or instances multiplies through four charges. In our anonymised insurance engagement, case file E-01, a Documentum centred ECM finding fell from $7.2M to $1.6M, a 78 percent reduction. While that engagement turned primarily on the seat count, the same discipline that holds a count to what is genuinely deployed applies directly to capacity metrics, where the gap between the hardware footprint and the allocated capacity is often the single largest correction.

Tie the count to allocated capacity, not the hardware

The lasting lesson is that a capacity based Content Server metric is defended by establishing what Documentum actually uses, not by accepting what the hardware can provide. A large host, a dense virtualisation platform, or a multi node cluster all present a bigger number than the genuine Documentum allocation, and the audit will use the bigger number unless the buyer supplies the configuration that defines the real boundary. The metric is only as honest as the allocation evidence behind it, and that evidence is the buyer's to produce.

For a buyer, the practical step is to document the hardware and virtualisation configuration for every environment running the Content Server, including the capacity allocated to Documentum and the structure of any cluster, so that a capacity finding can be answered with the configuration rather than the host specifications. Where that documentation is incomplete, it can be reconstructed from infrastructure records. To prepare it, read how to reconcile Documentum entitlements before an audit, and to see how this fits the wider defense, read our ECM and Documentum audit defense track. If a finding has charged for capacity Documentum does not use, open a case.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To understand how deployments are counted alongside capacity, read Documentum server deployment counting in an OpenText audit.