Documentum disaster recovery instances and licensing

A disaster recovery copy of a Documentum environment exists so the business can keep running if production fails. It sits idle until that day comes. On an audit it can be counted as a second live deployment, doubling a charge for a capability that is only ever used once, and the standby nature of the instance is the heart of the defense.

Responsible enterprises run disaster recovery for systems that matter, and a production Documentum estate almost always matters. The recovery instance is a standby copy, often kept synchronised with production but carrying no live workload, ready to take over only if the primary site is lost. From an operational standpoint it is insurance. From the standpoint of an audit that counts deployments, it looks like another running copy of the software, and unless the buyer establishes its standby role, the finding charges for it as though two production estates existed where only one does. Because the OpenText EULA places compliance on the licensee, the burden of proving the recovery role falls to the buyer.

How a recovery instance reaches the finding

A measurement that sweeps the estate finds the recovery instance the same way it finds production: it sees the software installed, the repository defined, and very often the production user accounts replicated into the standby. The data collection cannot tell, on its own, that the instance is dormant by design. It records a deployment, and the audit maps that deployment against entitlements. If the result is a charge for a second full production environment, the buyer is being asked to license a copy that does no work and serves no users except in a failover that may never happen.

Whether and how a recovery instance is chargeable depends on the entitlements and any rights they grant for standby or failover use. Many agreements treat a passive standby differently from an active deployment, and the question is rarely whether the instance exists, which is not in dispute, but how the contract treats a copy that is held in reserve. That is a contractual analysis, and it is the buyer's to make.

Where disaster recovery counting overcharges

Standby copies counted as active deployments

The central overcharge is treating a dormant standby as a live production deployment. How deployments are counted in general is examined in Documentum server deployment counting in an OpenText audit, and a recovery instance is precisely the kind of deployment that should not carry a full production charge while it sits idle.

Replicated accounts counted again

A recovery instance usually carries a copy of the production user accounts so it can take over cleanly. An audit that reads those accounts independently counts the same users twice, the compounding problem we describe in Documentum non production environments and license claims.

Recovery confused with active redundancy

There is a difference between a passive standby that does no work and an active redundant node that shares production load. Counting the two the same way overstates the case, and the distinction connects to how instances are measured, covered in Content Server CPU and instance based metrics explained.

Defending recovery instances 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 recovery instance is identified as standby from the outset, rather than being swept into the count as another production deployment.

Reconstruct. We build the effective license position independently. We identify the recovery instance, document its standby role and the absence of live workload, separate its replicated accounts from genuine production users, and establish how the entitlements treat failover and standby use. The reconstructed position distinguishes the one production capability from the insurance that protects it.

Rebut. We challenge the finding line by line. The recovery instance is repriced or scoped according to its standby role and the rights the contract grants. Replicated accounts are counted once. Passive standby is distinguished from active redundancy. Each correction rests on the recovery design and the entitlements.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that records how disaster recovery is licensed, so the next audit does not charge the standby as production again.

An anonymised outcome

The financial logic is the standard remedy that makes a doubled deployment so costly. 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 counting a standby as production can nearly double the bill for a single capability. 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, achieved in part by holding the count to the genuinely active estate and scoping standby and non production elements to their true role rather than accepting them as additional production deployments.

The standby role is the argument

The lasting lesson is that a disaster recovery instance is defended by establishing what it does, not by hiding that it exists. The audit will find the standby; what it will not know, unless the buyer supplies it, is that the instance carries no live workload, serves no users in normal operation, and exists solely to protect a single production capability. Once the standby role is documented and matched to the rights the contract grants for failover and recovery, a charge that treats it as a second production environment becomes difficult for the vendor to sustain.

For a buyer, the practical step is to document the disaster recovery design as part of the deployment record, capturing which instances are standby, how they are kept synchronised, and what the entitlements say about failover, so that a finding can be answered with the architecture and the contract together. Where that record is incomplete, it can be reconstructed. 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 your recovery instance as production, 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 the deployment metrics this connects to, read Content Server CPU and instance based metrics explained.