In working with a client, I had the opportunity to evaluate Buldoser from Crown Partners versus OpenMigrate from TSG. Buldozer was used to change OS platforms for a Documentum 5.2 Repository while upgrading it to Documentum 5.3. Buldozer failed to migrate a second Repository due to object level complexities. OpenMigrate was then tested in the migration/upgrade of the complex Repository from Documentum 5.2.5 to new OS hardware and to Documentum 6.5. While both products were designed to assist in the upgrade process, I found they work in substantially different ways.
Crown Partner’s Buldoser – A folder Approach
- Relies on building a bulk export cache of information on the file system and in memory before importing it into the target system. For my client, this caused issues when moving a large batch of documents. Clients should verify performance on a sample set to determine file system and memory requirements.
- Performance – While quick at first, the complex folder structure in the client’s Repository caused Buldozer’s performance to degrade considerably. After a period of time it was taking several minutes to migrate a single document.
- Service/Support – For my client, as a purchased product, Buldozer could not migrate the more complex of the Repositories. Even with support and service updates it was inadequate.
The Buldozer product suite is available from EMC as a standard item on the EMC Documentum price list.
TSG OpenMigrate
First a disclaimer, as a TSG employee I have had some input into the design of OpenMigrate but the core approach was completed before I joined. That being said, the use of a node versus a folder approach was the substantial difference I found. Specifically,
- OpenMigrate relies on an alternative approach by migrating documents individually. The product uses the concept of a migration node. Each node represents an object such as a document, folder, or user.
- The set of nodes in a migration queue is built by one or more queries into a document management system. The queue can also be built from a list of documents in an Excel file. Multiple batches of OpenMigrate can be run at the same time either working from different queues in memory or a shared queue stored in a database table.
- By operating on each node individually, OpenMigrate can scale up or down to make the most efficient use of available resources. For example, OpenMigrate is multi-thread configurable in three areas: connecting to the data source, connecting to the data target, and transforming, or mapping, data values.
As a free software product, you can try out OpenMigrate’s sample configurations in about 30 minutes. The Open Migrate Binary is downloadable at https://www.tsgrp.com/Open_Source/OpenMigrate/open-migrate.jsp.
Please comment your thoughts.
One quibble…OpenMigrate claims to be an “open source framework,” yet the license is decidedly anti-OSS. The license prohibits “modify[ing], translat[ing], reverse engineer[ing], decompil[ing], disassembl[ing] […] or creat[ing] derivative works,” which is counter to the whole idea of open source.
That being said, in your post you only claim it’s free (it’s the TSG website that claims it’s OSS), and you’re comparing it to a decidedly not-free package, so it’s just a quibble.
@Dan – Dan you bring up a good point that many downloaders misunderstand. The license allows you to access the open source but not create a “derivative work”. What we are basically trying to prevent is someone taking the code, change all “OpenMigrate” to “BobsMigrate” and packaging/selling it as commercial software. The license does allow you to download and modify the code for your own internal use. Unlike other open source offerings, our license does not force you to contribute any of your changes back to the code base. We found that this license worked better for our clients or others that wanted to use the source for something internal but not necessarily share those enhancements. That being said, some of the best contributions have been made from external parties.