• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

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

You are here: Home / Documentum / Documentum – Momentum EMC World 2014 – Day 1 – Content Bridge and DEMA

May 6, 2014

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
  • 3rd 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.

Filed Under: Documentum, News, OpenMigrate

Reader Interactions

Trackbacks

  1. Documentum – Momentum – EMC World 2014 – Day 2 – Rick Devenuti Keynote | TSG Blog says:
    May 6, 2014 at 3:29 pm

    […] « Documentum – Momentum EMC World 2014 – Day 1 – Content Bridge and DEMA […]

    Reply
  2. Documentum – Momentum EMC World 2014 – InfoArchive, aPaaS, xDB and thoughts on the “third platform” | TSG Blog says:
    May 7, 2014 at 5:51 pm

    […] like DEMA and SharePoint Connector arose out of the consulting division and was productized early in […]

    Reply
  3. Documentum – Momentum EMC World 2014 Recap – Some bunts, hits as well as some swings | TSG Blog says:
    May 23, 2014 at 10:45 am

    […] – See our write-up.  It has evolved and we like the upcoming delta migration focus.  We would probably say this is a […]

    Reply
  4. Documentum Migration – Issues with a “Two-Step” Migration Approach | TSG Blog says:
    July 16, 2014 at 10:52 am

    […] item we highlighted during EMC World in reviewing Documentum’s migration utility, DEMA, was the benefits of a delta migration approach.  Too often clients think of a Documentum […]

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Documentum or Alfresco Migration Tools – What about Speed?
  • Next Generation ECMS – Architecture Thoughts
  • Documentum Migration – "Two-Step" Bulk Load versus a "One-Step" Migration Approach
  • Documentum – Momentum EMC World 2014 Recap – Some bunts, hits as well as some swings
  • Documentum D2 – Do you need to migrate?
  • Documentum – EMC World/Momentum 2013 – TSG Recap
  • Documentum – EMC World 2013/Momentum – Day 2 – Migrations and Upgrades
  • Documentum – EMC World/Momentum 2012 – TSG Recap
  • Documentum Client Briefing – Final Agenda – June 7th – University of Chicago Gleacher Center in Chicago
  • Alfresco Consulting – Documentum Disruptor #2

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2023 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT