Documentum and Alfresco Migrations – Why the Migration Tool is Only Part of the Equation

As the developers of OpenMigrate, we are always amazed by how often a new tool is unveiled that claims to make migrations considerably easier.  While we love what we have done with OpenMigrate, we also typically have to educate clients that a migration tool, just like other tools, is only part of the effort.  This post will touch on all of the other requirements of a migration effort beyond just moving documents from point A to point B quickly.

Why you shoudn’t automatically buy into the “Better Mousetrap” Migration Tool

All too often we hear about a new migration tool that can rapidly migrate content to Documentum/Alfresco at unheard of rates of speed to dramatically reduce the cost and effort of upgrades and migration.  This was true in regards to EMC World when Documentum unveiled their own migration tool, EMA.   As mentioned then, EMA can migrate content at 1.2 million documents per hour by skipping the Documentum API/functions and interacting directly with the database.  While there are some potential benefits of this approach in regards to speed, we had the following concerns and thoughts regarding this  approach:

• Ability to repeat the process for ongoing migration needs
• Ability to apply business logic throughout the migration process
• Incorrect assumption that all migrations are the same
• Ability to address documents/data that failed to migrate
• Ability to repeat the process for different data sources and business cases

Migration consultants spend most of their time understanding the current data and migration requirements and setting up the migration—defining transformations, locating exceptions, modifying migrations to handle exceptions, etc.  Faster migration time is always nice, but the time spent executing the migration is often a small fraction of the overall project.  Typically consultants not only review migrated data from the back end (typically the way technical IT folks want to verify a migration) but also review migrated data and content using the front end user interface (Webtop, HPI, D2, etc.) in the source and target system. Migration and transformation requirements are often missed when only reviewing the migrated data and content from the back end. The EMA solution is so focused on moving back-end database rows, we would recommend our clients confirm there is a detailed review of the migration results from the front end interface.

Why migrations are about more than the Migration Tool

As we stated earlier, migrations encompass much more than simply moving content and metadata from one system to another.  Listed below are common tasks that we often perform for our clients during migration efforts:

• Gather migration requirements
  • Analyze business processes
  • Determine migration scope and details
  • Determine metadata mappings and transformations
• Setup target system environments
  • Define new document needs
  • Define new interfaces
  • Define security model
  • Cleanup/review taxonomy
  • Cleanup/review object model
  • Cleanup/revise specific content and metadata issues and anomalies
• Execute production migrations
• Perform metadata and content verification
  • Verify content and renditions
  • Verify metadata mappings and transformations
• Execute delta migrations
  • Execute planned delta migrations
  • Address initial errors

Summary

A migration effort should be a chance for a fresh start.  As CMS systems are used, they often experience “uncontrolled” growth.  Migrating to a new system or infrastructure offers the opportunity to clean up the system—separate or combine repositories, update object models, taxonomy and security, and review data anomalies.  While migration execution speed is of course an important aspect of migration efforts, it’s important to also look at the big picture and not overlook opportunities to improve a system rather than rush through the migration itself.