Update on OpenMigrate Qumas Migration

I posted an article a few months ago on TSG’s migration to Qumas using OpenMigrate (OpenMigrate Supports Qumas). We have now successfully run the migration through QA and are prepping for the production migration in a few weeks. I’m happy to report that the QA (Test) run executed successfully and smoothly (smooth is sometimes more difficult than successful!). The Qumas software adds hundreds of other Qumas-specific objects & tables that need to be analyzed for impacts when performing the migration. I would like to share a few lessons that we learned. These lessons really apply to any migration:

  •  Don’t underestimate the mapping effort when moving to a new object model. This migration also involved mapping old content into a new model. The assumption going in was that the mapping could all be done programmatically. This was incorrect and tens of thousands of documents needed to be manually mapped. Mapping and the management of the data mapping took a significant amount of effort
  • Do not underestimate the complexity of working with a new object model/database structure. As stated above, Qumas adds hundreds of tables on top of the Documentum structure. On our test runs in a sandbox environment every time we thought we had the dependencies figured out, something unexpected popped up and back we went to the database to understand the inter-dependencies.
  • Perform a full test run whenever possible. Many scenarios are not uncovered when only mapping a subset of the data. I would highly recommend performing a full migration in development. We did follow this advice and I believe this was key to a successful (and smooth) run through QA/Test.
  • Open Migrate is extremely versatile! After the table dependencies and all impacted data fields were figured out, we were able to perform this migration with minimal updates to OpenMigrate. Updates to OpenMigrate included extending the product to support a translator or Rosetta look-up table and support for calling the Qumas auto-number table.  After using OpenMigrate to do migrations to/from FirstDoc and now Qumas I’m convinced it would work well with any ECM solution or add on component.

Happy Migrating!

OpenMigrate: Making Complex Migrations Simple

Past blog posts have touted the flexible, extensible and configurable nature of TSG’s open source migration tool, OpenMigrate.  These claims are currently being put to the test.

TSG is in the final stages of a complex, cross-Atlantic migration utilizing OpenMigrate.  This project requires moving approximately 40,000 documents from a Qumas DocCompliance system in the Midwest to an existing Qumas DocCompliance system in Europe.  Qumas DocCompliance is a content management system which sits on top of Documentum and adds an additional layer of application specific objects.  As a result, an extra 300,000 plus supporting objects need to be migrated as part of the document migration.

Despite the added complexity of the Qumas system, minimal effort has been required to configure OpenMigrate for the migration.  Configurations were simply created for the documents and each of the 15 Qumas objects to be migrated.  The configurations utilize OpenMigrate’s customizable Listener classes, which can be inserted during any step of the migration to manipulate data as required.   Qumas objects rely heavily on attributes which point to other Qumas objects.  Through the use of a translating Listener, these attributes are updated to point to the new objects in the target repository and the application continues to function as required.  Using OpenMigrate’s multi-threading capabilities, test migrations have moved thousands of objects across the ocean in less than a minute, making the migration not only simple but fast as well.

For more information on OpenMigrate, please visit the TSG website.

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.