Documentum – Momentum EMC World 2014 – Day 1 – Content Bridge and DEMA

I attended two interesting presentations on this first day.  Chicago Bridge and Iron’s Mark Weaver presented on “Migration and Transformation: Optimizing Complex Migrations at CB & I”.  Later in the day, EMC’s Chris Dyde presented on “Documentum Enterprise Migration Appliance – Deep Dive”.  This post will summarize thoughts on the two presentations but mostly focus on the Documentum Enterprise Migration Appliance as it was a major announcement at last year’s Momentum.

CB & I and Content Bridge

Mark’s presentation focused on the unique migration requirements for CB & I.  From a background perspective, CB & I is and engineering firm headquartered in Woodlands, Texas with Mark working out of Charlotte, North Carolina.  The migrations are focused on large ingestion of documents from external vendors as part of the construction of new nuclear plants.  The audience for the presentation was about 15 people including at least 5 from the EMC Energy and Engineering.

Content Bridge is a migration engine used by CB & I for these daily ingestions of content into the various nuclear project builds.  The “fleet” approach, in regards to multiple plants presents some unique requirements for copying certain “fleet” documents to multiple projects.  The presentation discussed many of the tricky migration needs and how Content Bridge was evolving based on these requirements as part of the consulting agreements.

I didn’t ask any questions during the presentation as it wasn’t really technical but more specific on the functionality needed for the complex migrations.  If I misrepresented anything, Mark or EMC folks, if you respond I will post updates.

Document Enterprise Migration Applicance

One of the big announcements in last years 2013 keynote was the “Enterprise Migration Applicance” or EMA.  This has been renamed, rather appropriately, to the “Documentum Enterprise Migration Appliance” or DEMA.  For background, see our thoughts on Chris Dyde and Mike Mohen’s presentation on EMA last year.

Chris presented the updated DEMA – about 50 people attended.  DEMA is an EMC Consulting only offering, so it’s somewhat difficult to call it a product as it does not exist on the EMC price list.  Like Content Bridge, it is used by consulting services to handle specific issues.  Chris mentioned specifically:

• DCM to ECM Life Sciences Migration
• Webtop to D2 or xCP
• Upgrades
• 3^rd Party Migration
• Migration to MSOD – Managed Services On Demand

Core use case for DEMA

• High Volumes – if not high, can do migrations in other ways.
• Older Source Versions of DCTM – we see this often. Upgrading from Documetum 5.2.5 to 7.2 would require multiple upgrade steps – better to do just the migration.
• Consolidating, Demerging of Documentum
• Heavy duty object model change
• Changing DB Vendor

Less likely cases for DEMA

• Changing content during migration (TIFF to PDF)
• Straightforward Upgrades
• Customer would like to do 100% by themselves – tool is not available without consulting

DEMA has evolved.  Not going to go into all the technical components, but includes a MongoDB database as a staging area for the migration.  At a high level, the data is moved in the database (very fast) with the content being moved (or left in place) afterwards.  A couple of different scenarios with different products include:

• DEMA Cloner – this is where you are replacing the database underneath Documentum. Figure this is Oracle to SQL Server or vice versa.
• DEMA Migrate – when you want to migrate from one repository to another
• DEMA Morph – when you want to “morph” the object type

DEMA – all about speed

The core of DEMA is about speed of the migration – examples included:

• Government Client – 28 million documents – 10 TB – 10 days
• Cable TV – 75 million documents – 5 TB – 15 days
• Life Sciences – 1.5 million documents – 24 hours

Some specific discussions surrounded D2 and the need to let D2 do the “core job processing” that might slow down the migration but Chris expressed that D2 would complicate things and recommended that approach rather than trying to configure too much into DEMA.

Some of the key enhancements for DEMA included:

• Retaining Object IDs – this is an ongoing issue for clients that have used the r_object_id outside of Documentum. Please see our thoughts from 2010 regarding r_object-ids and migration – not something you want to do. We typically recommend against using r_object_id or DRLs for migration reasons.
• Delta Functionality – this is code complete but has not been used at a client yet.
• Enhanced Reporting
• Improved Transformation
• Providing Dry-Run Capabilities
• Support extraction of aspect data (part of Energy and Engineering EPFM)

DEMA – What it can’t do

Chris did point out some of the items DEMA can’t do including:

• Migrating from Documentum – makes sense, as a Documentum offering, they are not in the business of moving content out of Documentum.
• Migration to InfoArchive – would think this might be coming – more on InfoArchive in other posts.
• Index to xPlore – xPlore index needs to be rebuilt following the migration.
• Ongoing Migrations – Specific question but is more of a “one time” migration tool used by IIG Consulting

Delta Migration – why speed is important but not as critical in a delta approach

Chris discussed the delta migration as a way to reduce the downtime window.  In a delta approach:

• Source system is up and running while documents are migrated to the target system over time.
• On final migration weekend, Source system is brought down.
• Delta differences created since the first migration are migrated to the target system.
• Target system is brought up as the replacement system.

In this manner, the time for the first migration is often not relevant as it can be accomplished from a copy without impacting users.

Comparison – DEMA and OpenMigrate

After last year, we had lots of questions in regards to positioning of OpenMigrate versus DEMA, both technically and strategically.  We would say the main differences are:

• Database versus API – DEMA is written for speed at the database layer and will be faster than OpenMigrate at both  moving the data as well as the content. OpenMigrate leverages the Documentum DFC and will often move the content (although migrations have been constructed to leave in-place).
• r_object_id – OpenMigrate does not allow the r_object_id to be preserved. Typically it gets stored for reference in a different attribute.
• Real-Time Moving – OpenMigrate is built to allow both Documentum repositories to be available while the migration is taking place. DEMA requires, based on the database approach, that the target and source not be available to avoid conflict.  We would expect that DEMA would probably leverage a copy of the source docbase when doing the delta approach.
• Multi-Threaded – we didn’t hear anything in particular in regards to multi-threaded support for DEMA. OpenMigrate supports multi-threaded operation on both target and source repositories.

Migration Example – where speed doesn’t matter – xPlore

As we pointed out above, we tend to recommend delta migration approaches to reduce the migration window or down time, something that DEMA is code complete to support.  During one of our last delta migrations, our biggest roadblock was the xPlore index build rather than the migration itself.

For an example difference in the approaches, let’s say the repository has 200,000 documents – with some pretty large (60 plus pages) documents – that xPlore will take 2 days to index.  Both migration tools (OpenMigrate and DEMA) will complete the initial migration in the previous weekend with a copy of the source repository.  Changes in the repository the last week affect 2,000 documents.

• DEMA and OpenMigrate would have to migrate the last week of updates. DEMA will be faster given database level but we would expect that total OpenMigrate time would be less than 2 hours depending on threading and target/source repositories configurations.
• DEMA would require the xPlore index to be rebuilt causing another 2 day downtime.
• OpenMigrate, since using the API, would have had the index built during the week after the first move. xPlore would update the index with the changed 2,000 documents – probably 2-3 hours.

Since the DEMA delta migration was somewhat new, we would look for Documentum to address the xPlore indexing component as the product evolves.

Summary

Both Content Bridge and DEMA have evolved out of IIG Consulting.  Content Bridge looks to be part of the Trinity acquisition  with DEMA evolving out of life sciences and more generic IIG consulting.  When it comes to software products, we like the approach that the clients are driving the requirements, often with their consulting spend.  It is how we developed our TSG software products including OpenMigrate.  The consultant driven approach provides a push for requirements that are important enough for a client to pay for, something much better than a client wish list.  Both products will continue to evolve, but DEMA can only be considered within an IIG consulting initiative.