Documentum Migration: Preserve Versions and Evidence

Migrate from Documentum by identifying the source objects and evidence your records require, mapping them explicitly to the target, then verifying meaning and access as well as file integrity. A successful file export does not prove that version lineage, approved renditions, relationships, permissions or workflow history survived.

This procedure is for life-sciences teams planning a move from a Documentum repository to another controlled environment. It is a documentary migration framework, not a script tested against your repository. The exact Documentum Server, client, APIs, life-sciences configuration and target remain inputs you must establish.

The technical examples reference OpenText's public Documentum Foundation Classes 24.4 and D2FS REST Services 24.4 documentation, reopened for this guide. Those are explicit documentation versions, not a claim that 24.4 is the latest release or that its behavior applies unchanged to your deployment.

1. Identify the actual source stack and export boundary

Record the repository identity, Documentum Server version, client/application versions, installed modules, custom types, configured lifecycles and integrations. Identify whether the business uses D2, Smartview, a life-sciences application layer or other custom behavior. A product name alone does not describe the implemented records model.

Obtain authorized access, an appropriate test environment or approved extraction approach, supplier documentation for the deployed versions and the owners who can explain record meaning. Establish a read-only source-inspection boundary where practical. Do not change source lifecycle states, approvals or retention settings merely to make extraction easier.

OpenText's D2FS REST documentation describes services that use D2 configuration and notes configuration-specific behavior during object operations. This is why a migration design must identify which application rules it depends on rather than treating every Documentum API as interchangeable. OpenText D2FS REST Services 24.4 Development Guide.

Define what will move, what remains in a retained source/archive, and what cannot yet be classified. Name the authoritative location for each population after cutover. A selective migration can be defensible when the retained environment meets the relevant needs; “everything moved” is not established by exporting the current visible folder contents.

Output: a source-stack record, approved extraction scope and owners for unresolved configurations. Do not select a universal DQL or REST recipe while these inputs are unknown.

2. Inventory identities, types and version trees

Preserve repository-qualified object identity. Record r_object_id, the object's type, relevant business identifiers and the version-family relationship. In Documentum's documented model, i_chronicle_id identifies the root of the version tree; individual versions have their own object identities and labels. Do not use filename alone as the migration key. OpenText DFC 24.4 SysObject reference.

Capture implicit and symbolic version labels and the actual tree relationships needed by your records. OpenText's version-tree interface distinguishes version count from label count because one version can have multiple labels. Counting labels as though each were a separate document can corrupt reconciliation. OpenText DFC 24.4 version-tree reference.

Inventory custom types and required attributes, including repeating values and their ordering where meaningful. Ask the process owner which attributes establish product, site, lifecycle, applicability and business document number. The target's generic “document” type may not preserve those distinctions without an explicit mapping.

Include checked-out or in-process content in the scope decision. Determine whether work will finish in the source, remain there temporarily or follow an approved transition path. A working copy is not automatically the next approved target revision.

Output: an inventory that distinguishes business documents, object versions and labels, with exceptions. A source query or service response must be checked for version coverage, paging and account visibility before its count is accepted as the population total.

3. Select content and renditions deliberately

For each selected version, identify the native content and other content representations required for its intended use or retention. Preserve enough source information to distinguish the selected content: format, content identity or selector, applicable page/modifier information and its association with the object version.

OpenText's DFC 24.4 getRenditions documentation describes a query returning page-0 content, including renditions. It should not be assumed to enumerate every content position in a repository with multiple contents. Review the actual content model and supported extraction method before relying on that helper as a complete export. OpenText DFC 24.4 rendition documentation.

A PDF rendition may be useful for reading, while the native source or another rendition may preserve information required for a different purpose. Identify how your application produced the rendition and which representation supported approval or use. Do not assume every PDF is the approved view because its format matches the target's preferred format.

If regenerating a rendition, treat that as a transformation requiring assessment. Preserve the source association and check content, layout and relevant approval context. A newly generated PDF should not be presented as the historic file originally reviewed unless that assertion is supported.

Output: a content selection rule and per-version manifest. The rule must explain excluded representations and what evidence remains accessible, not simply select the first downloadable PDF.

4. Map access, relationships and process evidence separately

Exporting an ACL name is not equivalent to reproducing access. Resolve the relevant users/groups and their mapping to target identities. Document required permissions and test actual resulting access, including denied operations.

OpenText's DFC 24.4 ACL reference distinguishes basic, extended and application permissions. A target model that offers only reader/editor roles may require a deliberate redesign rather than direct translation. Do not assume numeric permission values or similarly named groups mean the same thing across systems. OpenText DFC 24.4 ACL reference.

Inventory folder links, related objects, virtual-document structures and other relationships used by the business. Determine whether each relationship identifies a particular version or is resolved through a rule. If the target cannot reproduce that behavior, preserve an approved explicit representation or retained-source access that meets the defined requirement.

Treat workflow evidence separately from a document's current state. Identify the decisions, actors, timestamps, signature context and linked records required to explain the history. An imported “approved” label is not proof that the target executed the original approval. Preserve provenance rather than creating new target events that falsely look like historic source actions.

Also identify annotations, external references, retention controls and any application-specific evidence the business relies on. Their availability and extraction path depend on the implemented modules and configuration. Missing evidence is an open migration requirement, not permission to declare it unnecessary.

Output: approved identity/access mappings, relationship dispositions and an evidence-preservation plan. For records requiring retained source access, define who can retrieve them and how that access will survive retirement of ordinary user accounts.

5. Complete this source-to-target mapping record

Use one row per required object-version/content combination, with linked records for its metadata, relationships and evidence. Record the source extraction time, tool/configuration version, mapping revision, reviewer and disposition. The table below describes the fields to include; it is a usable worksheet structure rather than a claim of universal Documentum schema.

Use Pass, Fail, Unresolved or Not applicable with rationale for each required check. A failed or unresolved critical mapping prevents acceptance of the affected scope. If the target cannot express a required relationship, agree and verify an alternative before signing off.

For GMP computerized systems, Annex 11 section 4.8 addresses preserving data value and meaning during migration. This supports evaluating more than byte transfer; the relevant context must survive the transition. EU GMP Annex 11, revision 1.

6. Exercise a wrong-version and wrong-rendition fixture

Create a permitted test case that reflects your configuration. This invented fixture uses aliases rather than real repository IDs or executable syntax:

All three objects use the same display filename. Object B also has a review rendition distinct from its released PDF. The business owner has supplied the authority evidence identifying B's released representation for the target current-use view.

Run the negative selection. A prototype extractor selects the most recently modified object and the first PDF returned. It chooses C, or pairs B with its review rendition. The copy operation can finish without a file error and still fail the migration requirement.

Apply the mapping checks. Compare the selected source object, version-family relationship, business status and rendition identity with the approved manifest. Mark the current-use mapping Fail when any of those disagree. Matching file counts or hashes against the wrongly selected file cannot repair the selection error.

Correct and repeat. Bind the export to the approved source version and required representation, while preserving A and C under their agreed historical/draft dispositions. Recheck metadata, content and target presentation. If the evidence does not identify which rendition was authorized, leave the item Unresolved and obtain the owner's decision; do not infer approval from a rendition's filename.

Complete the fixture's acceptance record at more than one level. Record one document family and three source object versions, then list the required content representations individually; their total need not equal three. For B, retain an explicit “released PDF selected for current use” entry and a separate disposition for the review rendition. If that rendition stays in the source archive, record its retrieval path and owner. This prevents a correct current-use selection from concealing an unaccounted historical representation.

Change the intended purpose. If the target population is historical review rather than current operational instructions, retaining multiple branches and renditions may be exactly the requirement. Keep them explicitly labeled and searchable without presenting them as current instructions. The selection rule changes with the approved purpose.

This is a documentary example of a failure test, not a claim that a Documentum extraction or target import was executed for this article.

7. Verify extraction and import before production acceptance

Reconcile at the appropriate levels: document families, required versions, content representations, metadata and evidence dispositions. Counts at one level do not prove completeness at another. Investigate inaccessible, missing or duplicate results rather than treating every empty response as “no record exists.”

For unchanged files, integrity checks can establish that selected bytes survived transfer. For transformations, define checks appropriate to the changed representation. Verify human readability and context as well as machine identity, and retain the actual evidence used for acceptance.

Exercise role-specific behavior in the target. A migration account with broad access cannot demonstrate that ordinary users have the correct restrictions. Include a user from an unrelated program and an attempted unauthorized state change, as relevant to your access design.

Retrieve a historical decision and follow its relationships. Confirm that the reviewer can identify the actual source object/version and distinguish preserved source history from new target actions. If a required viewer or retained application is part of that path, include its availability in acceptance.

For wider assurance planning, see the computerized system validation guide. The QMS document-control guide helps define current-use versus historical-state behavior.

Output: an accepted verification report with unresolved items visible, scope stated and evidence traceable to the extraction and mapping baseline. A successfully completed import job is an input to that report, not its conclusion.

8. Cut over without losing retained history

Define how source changes after the trial extraction will be captured and reconciled. Communicate the source-edit boundary, finish or disposition in-progress workflows, and verify the final transition population before declaring target authority. Preserve the source until its assigned migration and retention conditions are satisfied.

Document recovery at each stage. Before new target activity, returning to an available and suitable source may be possible. After target approvals or other records exist, a simple reset can discard new evidence; protect and reconcile those records under the authorized continuity plan.

If retaining Documentum for history, identify the supported operating model, licenses/contracts, infrastructure, identity access, backups, viewers and accountable owner needed for continued retrieval. “Read-only archive” is a service obligation, not merely an unchanged database backup.

If retiring it entirely, demonstrate that the retained target/archive provides the necessary records and context before decommissioning dependencies. Annex 11 section 17 addresses accessibility, readability, integrity and retrieval through relevant system changes within its GMP scope. Annex 11 archiving provision.

OpenText markets a Documentum Content Management offering for life sciences, but the product page cannot identify your organization's custom repository behavior or prove a migration path to another product. OpenText life-sciences offering. Obtain the deployed-version and configuration evidence before accepting a migration commitment.

Assyro publishes this guide. If the destination use concerns regulatory document preparation or review, evaluate Assyro's document-management offering against your completed mapping record. No native Documentum migration connector or complete historical-model equivalence is assumed here. Discuss the exact source scope with Assyro, including required versions, evidence, access and retained-archive responsibilities.