HomeArticlesDocumentum non production environments and license claims
ECM & Documentum · Field Note

Documentum non production environments and license claims

Development, test, staging, and training copies of a Documentum environment exist to keep production healthy. On an audit they often appear as additional chargeable deployments, and a finding that counts every non production copy at full production rates is one of the more answerable claims a buyer will face.

A mature Documentum estate is never a single environment. Alongside production there are development repositories where changes are built, test and quality assurance copies where they are validated, staging environments that mirror production before release, training instances, and disaster recovery standbys. These non production environments are a normal and necessary part of running enterprise content management responsibly. The audit, however, sees software installed and accounts defined across many environments, and unless the buyer separates production from the rest, the finding treats them all alike. Because the OpenText EULA places compliance on the licensee, the work of distinguishing a production deployment from a test copy falls to the buyer to perform and to prove.

How non production environments enter the finding

A measurement counts what it can observe. When a self assessment or an audit data collection runs across the estate, it captures the repositories, the Content Server instances, the installed modules, and the user accounts in every environment it reaches. A development repository looks structurally similar to a production one, and the accounts inside a test copy are often clones of production accounts, so the raw count inflates with every additional environment. The vendor then maps that combined count against entitlements, and unless the buyer has already drawn the production boundary, the finding charges for the whole.

The licensing reality is more nuanced than the raw count. Whether and how a non production environment is chargeable depends on the entitlements and the terms attached to them, and many environments that appear on the audit are either covered by existing rights or fall outside the metric the vendor is applying. The point is not that non production use is always free, it is that it cannot simply be added to the production count at production rates without examination.

The trap

An audit treats a development, test, or staging environment as if it were production unless the buyer proves otherwise. The same module installed in five environments can be counted five times, even when only one of them serves the business.

Where non production counting overcharges

Cloned accounts counted again in every copy

Test and staging environments are frequently built by copying production, which means the production user accounts are reproduced in each copy. An audit that reads each environment independently counts those accounts repeatedly. The underlying problem of treating defined accounts as consumers is examined in how Documentum named user counts inflate an audit finding, and it compounds sharply across non production copies.

Installed modules counted as production deployments

A module installed in a development environment so that developers can build against it is not a production deployment. An audit that counts installed software as licensed and in use, regardless of environment, overstates the estate. Separating where software genuinely runs from where it merely exists is central to the defense, and connects to how deployments are counted, covered in Documentum server deployment counting in an OpenText audit.

Standby and recovery copies counted as live

A disaster recovery instance that sits idle until a failover is not an additional production workload. Counting it as one charges the buyer twice for a single production capability, a question we treat directly in Documentum disaster recovery instances and licensing.

Defending non production scope 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 data collection so that environments are identified and labelled as the measurement runs, rather than being swept into a single undifferentiated count.

Reconstruct. We build the effective license position independently. We map every environment in scope, classify each as production, development, test, staging, training, or recovery, and establish how each is treated under the entitlements that actually apply. We separate cloned accounts from genuine users and isolate installed software that is not a production deployment. The result is a production boundary the buyer can stand behind.

Rebut. We challenge the finding line by line. Non production environments are removed from, or repriced within, the count on the basis of what the entitlements permit and what the environment actually does. A claim that counts a test copy as production is answered with the environment classification and the contractual basis behind it.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that records how non production environments are licensed, so that the next audit does not relitigate the same test and development copies.

An anonymised outcome

The financial logic is the standard remedy that makes every overcounted environment 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. 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 drawing a clear production boundary and holding the count to the environments that genuinely served the business rather than the full set of copies the measurement had captured.

Draw the production boundary before the audit does

The lasting lesson is that the production boundary is the buyer's to define, and if the buyer does not define it, the audit will define it by default as the entire estate. A development environment is not a secret, a test copy is not hidden, and a recovery standby is not deceptive, but none of them announces itself as non production in a raw inventory. The classification has to be supplied, and it has to be tied to the entitlements that govern each environment, because the question is never simply how many copies exist but how each copy is licensed.

For a buyer, the practical step is to maintain a clear map of which environments are production and which are not, with the contractual basis for the treatment of each, so that a measurement can be reconciled against it rather than taken at face value. Where that map does not exist, it can be reconstructed, and a finding that counts every non production environment as production is precisely the kind of claim a prepared buyer can take apart. To understand how this fits the wider ECM defense, read our ECM and Documentum audit defense track, and if non production copies are inflating a finding, open a case.

Where to go next

For the complete method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To prepare the environment record that makes this defense possible, read how to reconcile Documentum entitlements before an audit.

If an OpenText or Micro Focus audit notice has reached you, the first seven days weigh more than any week that follows. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, brought the average finding down by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.