With the new year comes exciting new product updates, and the release of TSG’s migration framework, OpenMigrate version 1.7, leads the way. This release of OpenMigrate includes some new features as well as enhancements to existing features, as described after the jump.
At TSG we get questions all the time in regards to “How are your consulting engagements different between Alfresco and other ECM offerings like Documentum, FileNet/IBM and SharePoint.” For this post, we will explore how we have been successful with Alfresco Consulting initiatives and point out some of the differences to commercial ECM consulting.
We posted an article last week on how Alfresco and SharePoint were Disrupting Documentum. The term disruptor is from the Innovators Dilemma business book and it relates to how difficult it is for one company to continue technology innovation over time and newcomers disrupt the industry. In a phone discussion with one of the responders, we discussed how consulting resources (like ourselves) are assisting in that cycle. This post will discuss how TSG and others Alfresco consulting firms are accelerating the disruption of established ECM tools like FileNet or Documentum.
I was at a Documentum client this week that is reviewing their ECM strategy as part of planning for 2012 and 2013. Given a somewhat difficult relationship with EMC due to a contentious software audit, the client wanted to review alternatives and consider a Documentum migration to a new ECM system as an alternative to the Documentum upgrade. For this post I will share some of the discussion of Documentum Alternatives as well as thoughts on ECM disruptors, Alfresco and SharePoint.
Interesting article in Forbes (http://www.forbes.com/forbes/2011/0117/technology-emc-joe-tucci-hp-idc-ibm-cloud-warrior.html) – (note – wait for the article – advertisement will come up first) in regards to Joe Tucci and EMC’s pursuit of the cloud through alliances with Cisco, VMWare and Intel to compete with IBM and HP. While the article doesn’t mention Documentum, it does mention that Tucci has “kept EMC competitive by snapping up software companies…the biggest being VMWare”.
I recently had the opportunity to work with a defense company who was looking to migrate data out of FileNet using our OpenMigrate solution. Compared to the other FileNet migrations we’ve done, at first this seemed much simpler, considering they only had 3 doc classes that they wanted to migrate, but pretty soon, we realized we had some challenges ahead of us.
Challenge One: A Very, Very Old AIX Server
First we found that the FileNet server they were using was a very old AIX machine, and that the latest version of Java supported on that version of AIX was Java 1.1. OpenMigrate (OM), on the other hand, had only been run on Java 1.4 and Java 1.5. It would have been a stretch, but we could have tried updating OM to work with Java 1.3, but anything lower than that would probably not have worked since OM is built on the Spring framework. What we decided to do instead was take OpenMigrate’s FileNet logic and execute the steps manually. Continue reading
OpenMigrate, TSG’s open source migration framework, supports migration to and from a number of ECM repositories, including Documentum, Alfresco, FileNet and SharePoint (and many others).
We’ve designed OpenMigrate to perform several different types of migrations:
- Between different instances of the same ECM product (e.g., during an upgrade)
- Out of one ECM technology into a “neutral zone” (usually a file system and database or text files for metadata)
- From a neutral zone into an ECM technology
- Out of one ECM technology directly into another (e.g., Documentum to Alfresco)
While the general pattern of migrating content and metadata is consistent across all of these migration types,
Frequent readers of the TSG Blog know OpenMigrate is our flexible open source migration framework; that it can be configured or extended to move content and data between different types of repositories; and that it’s been used in numerous successful migrations with Documentum, Alfresco, Qumas, Hummingbird and many others.
But perhaps you’re wondering: “There’s no way it could migrate from an old FileNet IDM system, could it? I mean, that system was built for old optical disk storage devices! I heard there was a C API but that people had mixed results trying to use it for high-volume use cases. It’s practically older than Java and the web; and certainly much older than web services. Surely you’ll tell me it can’t be done?”
Well, I’m happy to report that TSG has two successful FileNet IDM migrations under our belts, both using OpenMigrate. For the first, we migrated 1M files and data and made minor customizations to the framework; for the second, we migrated just over 2M, and ran OpenMigrate out of the box.
Some features of both migrations include:
- Selection of documents and their metadata using specific rules for each FileNet document class
- For picklists (FileNet menus): inclusion of codes, descriptions or both
- Translations of FileNet dates
- Concatenation of multi-page image files into single PDF files
- Binary concatenation of very large files (e.g., SAP Archive files)
- Migrations executed in “platter order,” in order to minimize optical disk swapping
- Two migration phases: a “pre-cutover” bulk migration in the weeks prior to cutover; and a final “delta” migration extracting the remaining documents and metadata
- Robust error recovery
In both instances, we executed OpenMigrate with 6 threads during business hours and 15 threads overnight in order to minimize the impact to interactive users.
After studying the underlying FileNet database structure and the system tools available for retrieving content, TSG determined the most cost-effective approach for implementing a migration from FileNet. Rather than attempting to integrate the Java-based OpenMigrate with the dated C API, we configured OpenMigrate to query the underlying database tables directly. And to retrieve the content, we used a few key system tools installed on the FileNet server, scripted and controlled by a single OpenMigrate component.
- The JDBC Queue Populator builds the migration’s “To-Do List” from FileNet’s underlying DOCTABA table (joining against the menu item table if appropriate for the doc classes being migrated). It includes built-in and business metadata in the query.
- Each OpenMigrate Source thread uses the FileNetCsmContentLoader component to retrieve the document from FileNet. It uses a variety of FileNet system tools to extract the image or images, determines whether to concatenate the images using iText, and translates FileNet dates to Java dates.
- The Mapping layer performs any metadata translation in order to prepare the document for import into the target system (e.g., set the r_object_type in Documentum based on the FileNet doc class).
- The Target threads write the content and its metadata to the target repository.
The resulting migration approach ended up being refreshingly straightforward and repeatable; as I noted above, our second migration was able to use the custom component out of the box.