Migrating From Documentum with OpenMigrate: Best Practices

OpenMigrate, TSG’s open source migration framework, supports migration to and from a number of ECM repositories, including Documentum, Alfresco, FileNet and SharePoint (and many others).

We’ve designed OpenMigrate to perform several different types of migrations:

• Between different instances of the same ECM product (e.g., during an upgrade)
• Out of one ECM technology into a “neutral zone” (usually a file system and database or text files for metadata)
• From a neutral zone into an ECM technology
• Out of one ECM technology directly into another (e.g., Documentum to Alfresco)

While the general pattern of migrating content and metadata is consistent across all of these migration types,

Document Versions

ECM systems like Documentum and Alfresco support content versioning, and generally follow the same implementation strategies. However, when migrating to a platform that does not support versioning—or supports it in a different fashion—some forethought is necessary. When exporting multiple versions to a filesystem, one possible strategy is to include Documentum’s “implicit” version label (e.g., “1.0”) as part of the filename. Another is to include a unique identifier (e.g., Documentum’s r_object_id) in the filename, or to append a unique counter if the output file already exists. OpenMigrate can implement all three of these solutions.

Document Renditions

Documentum supports multiple renditions of a given document—say, a PDF generated from an Office document or an HTML file generated from XML and XSL. Exporting to a file system is usually simple as long as the file type is known: just use the appropriate file extension. OpenMigrate can implement this in a straightforward fashion, but it can also “sniff” the file type using the open source Tika library.

Folder Paths

Documentum, along with most other ECM systems, can link a document to more than one folder. Documentum adds two twists, though: First, a document only inherits security from the “first” folder it is linked to (when the repository is configured for folder security); and second, its folders can have multiple paths of their own. OpenMigrate bases content migration on the first folder, first path (though it does capture all folders and paths in the metadata), as this is almost always the desired behavior.

Taken individually, each of these challenges is fairly easy to overcome. But pity the implementor who underestimates the big picture, especially late in a project. Using a tool like OpenMigrate helps us ensure we’re asking all the right questions as we work with a client to migrate their critical business content.