Decommissioned Documentum repositories still on the audit

A repository you retired years ago can still appear on a Documentum audit, counted as though it were live. Decommissioned systems that were never fully removed from inventory are a quiet but substantial source of audit overcharge, and they are among the most defensible items in any finding.

Documentum estates are large and long lived, and decommissioning is rarely as clean as it looks on a project plan. A repository is taken out of service, users are migrated away, and the system is marked retired, but traces remain. The server may still exist, the repository definition may linger in an inventory, and a license record may never have been updated. When an audit sweeps the estate, those traces resurface, and a system that has done no real work in years is counted as a live, chargeable deployment. Because the OpenText EULA places compliance on the licensee, the burden of proving a repository is genuinely retired falls on the buyer.

How decommissioned repositories end up on the audit

The mechanics are straightforward and unglamorous. Decommissioning is an operational activity, while licensing is a contractual one, and the two are often handled by different teams who do not fully reconcile. A repository can be operationally dead, with no active users and no business function, while still appearing in a configuration database, a server inventory, or an old license schedule. An audit measures what it can find, and what it finds includes these residual traces unless the buyer has actively removed them and can prove the removal.

The result is a finding that counts deployments which produce no value and serve no users. This is closely related to the broader problem of repository sprawl, where the sheer number of repositories drives the count, examined in Documentum repository sprawl and its license exposure. Decommissioned repositories are the sprawl that should already have been pruned but was not removed from the record.

Where decommissioned repositories inflate the finding

Retired repositories counted as production

The core overcharge is treating a retired repository as a live production deployment. A repository that was taken out of service, whose users were migrated elsewhere, should not carry a production license charge. Proving the retirement date and the absence of activity removes it from the count.

Migrated content counted twice

When content is migrated from an old repository to a new one, the data may exist in both for a period, or the old repository may persist as an empty shell. Counting both the source and the destination charges the buyer twice for a single migration. The same double counting risk arises in cloud migrations, which we cover in OpenText ECM cloud migration and dual entitlement.

Server deployments left in inventory

A decommissioned repository often leaves behind a server entry that an audit reads as a live deployment. How server deployments are counted is a question in its own right, examined in Documentum server deployment counting in an OpenText audit, and a retired server should not be counted as an active one.

Dormant accounts on retired systems

Retired repositories carry the accounts of the users who once worked in them. Those accounts are dormant by definition, and counting them compounds the overcharge, the same problem we describe in service and dormant accounts counted as Documentum consumers.

Defending decommissioned repositories 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 over the channel so the raw inventory the audit collects does not become the agreed scope. Establishing which systems are genuinely live, and which are retired, begins immediately.

Reconstruct. We build the effective deployment position independently. We identify every repository in the audit scope, establish which are live and which are decommissioned, document the retirement date and the absence of activity for each retired system, separate migrated content from active content, and scope out residual server entries. The reconstructed live estate is what we defend.

Rebut. We challenge the scope line by line. Retired repositories come out on evidence of their decommissioning. Migrated content is counted once, not twice. Residual server entries are scoped out. Dormant accounts on retired systems are removed. Each adjustment is supported by the retirement record and the activity history.

Resolve. We settle on the corrected live estate and, where it serves you, convert forward into an OpenPass agreement that records the active deployments clearly, so retired systems do not resurface on the next audit.

An anonymised outcome

The financial logic is the familiar one. 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 every decommissioned system wrongly counted as live multiplies the bill. 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 scoping retired and dormant elements out of the count and holding the finding to the genuinely active estate. Decommissioned repositories are exactly the kind of item that reduction is built from.

Proving the retirement the audit ignores

The lasting lesson is that retirement has to be proved, not merely asserted. An audit will not voluntarily remove a repository from scope because the buyer says it is retired. It removes it when the buyer produces evidence: the decommissioning date, the migration record showing users and content moved elsewhere, and the activity history showing no genuine use since. That evidence is usually available, because decommissioning is a documented project, but it has to be assembled and presented, and it has to be tied to the specific systems the audit is counting.

This is one of the clearest examples of why a buyer side reconstruction matters. The audit's inventory reflects what the systems still show, not what the business actually runs, and only the buyer can supply the operational context that distinguishes a live deployment from a residual trace. The repository that was retired three years ago is invisible as retired in a raw inventory and obvious as retired once the decommissioning record is on the table.

For the buyer, the practical takeaway is to treat decommissioning as a licensing event as well as an operational one. Every repository taken out of service should be removed from the license record and its retirement documented, so that the next audit starts from a clean scope. Where that housekeeping was not done, the evidence can still be reconstructed, and a finding that counts retired systems as live is a weak claim that a prepared buyer can answer directly.

Where to go next

For the full method behind an ECM finding, read our complete OpenText audit defense playbook for 2026 and our ECM and Documentum audit defense track. To prepare the deployment record that makes this defense possible, read how to reconcile Documentum entitlements before an audit. If a Documentum finding counts repositories you retired long ago, open a case and we will scope the count to your genuinely active estate.