TSG OpenMigrate Supports Qumas

I’ve been working with a client who needs to consolidate two Qumas content repositories into a single system. Qumas is an Irish company that has a content management solution that runs standalone as well as on top of Documentum. My client was running both Qumas applications on top of Documentum.�
In working with client, we had determined to use OpenMigrate for the migration.  This was similar to another pharmaceutical client that was using FCG FirstDocs, which OpenMigrate also supports. 

In addition to the standard Documentum objects and tables, Qumas has hundreds of other Qumas-specific objects and tables. While the tables could have made the migration a very complex task, we have been able to updateOpenMigrate to support this with minimal updates. The only required updates were an “ID Translator” component and an update to leverage Qumas’ auto-number table.  The ID Translator was needed to address parts of the system that were configured outside of the migration. The auto-number table was necessary to apply an auto number to each object when migrated into the target.  The larger task has actually been the analysis required to understand exactly what needed to be migrated and in what sequence.

For either Qumas or Documentum users, there are subtle differences between the Documentum product set and the Qumas product set.  Qumas has some nice additional features such as read and understood and configurable lifecycle-based security that are not standard with Documentum. However, with Qumas, if you find something you do not like, you cannot change it. For example, if you don’t like the search columns that are displayed they can’t be changed.