Documentum repositories are very good at keeping things. That's the problem we want to talk about.
OpenText Documentum Content Management (CM) was built for content that is being worked on: drafted, reviewed, approved, versioned, controlled and used in regulated processes. OpenText describes it as a repository for high-volume, mission-critical documents with records lifecycle control and retention policies built in. It does that job well.
But a repository that is good at keeping things will keep everything, unless someone decides otherwise. Over time the active repository becomes the place where finished content goes to sit. Closed projects, superseded procedures, completed batch records, ten-year-old correspondence. All of it fully indexed, fully licensed, fully backed up, and sharing the same platform as the work people are doing today.
This isn't a criticism of Documentum. It's a lifecycle question, and we think it deserves an honest answer.
Draft, finalize, use, retire
Most content goes through four stages. It's drafted. It's finalized, often through review and approval. It's used, sometimes for years. Then it stops being used, but it still has to be kept.
The first three stages are what a content management platform is for. Versioning, workflow, check-in and check-out, controlled distribution, collaboration in D2 or Smart View. The fourth stage needs something different: long-term retention, legal holds, audit trails, searchable access, and defensible disposal at the end. It doesn't need a workflow engine or an authoring client.
When the fourth stage happens inside the active repository, the active platform carries the full weight of content nobody is working on. That shows up in storage, in backup windows, in upgrade testing, and in how hard it is to answer a simple question: what in here are we actually still using?
Three signs content has finished its work
It hasn't changed in years and won't again. No new versions, no workflow, no pending approvals. It's a record now, not a document in progress.
Its only remaining reason to exist is a retention rule. If you asked the business owner why it's kept and the answer is "because we have to", it belongs in retention, not in collaboration.
It slows down things that matter. If upgrade rehearsals, migrations or reindexing take longer because of content nobody opens, the inactive share is costing you on the active side.
None of these is a size threshold, and we'd be wary of anyone who offers one. The answer comes from your retention schedule and your usage data, not from a rule of thumb.
Leaving shouldn't mean losing control
The worry we hear most is reasonable: if content moves out of Documentum, do we lose the controls that made it trustworthy? It shouldn't. The point of moving inactive content is to put it somewhere designed for the retire stage, with the governance intact.
OpenText draws this line itself. Its Documentum CM product page lists OpenText Information Archive under "information archiving", for long-term data compliance. The Documentum CE 23.4 release, which OpenText called "One Documentum", named "end-to-end archival for mature content" as one of its themes.
Information Archive is OpenText's compliant archive for information that has to be kept but no longer worked on. Document repositories are among the sources OpenText says it takes in, alongside applications and databases. Event-driven retention, legal holds, encryption and audit trails are standard, and content can sit on immutable storage. For a regulated Documentum estate, those are the controls that have to survive the move.
What we'd want settled before anything moves:
Which retention rules travel with the content, and who owns them after the move.
Which metadata has to come across so that a search in five years still finds the right record.
Who needs to retrieve archived content, how often, and from which screen.
How legal holds placed in one system are honored in the other during and after the transition.
What the disposal process is when the retention period ends, and who signs off.
Those answers shape the design. The tooling follows.
One naming note
Documentum Content Management is not the same product as OpenText Content Server or OpenText Extended ECM. All of them are OpenText, all of them manage active content, and the names get mixed up often. This article is about Documentum. The lifecycle logic applies to both, but the details don't, so it's worth being precise about which repository you're actually talking about.
Where to begin
Start with a report, not a project. Pull content counts and last-modified dates by cabinet, folder or object type, then lay them against your retention schedule. The parts that are old, unchanged and kept only for compliance will stand out. That conversation is far easier to have with the business when everyone can see the same picture.
Documentum keeps doing what it's good at. The archive takes the content that has finished its work. Each platform does one job well.
