ETL for Documentum

ETL, Extract, Transfer & Load, tools are essential for customers implementing Content Management solutions. Although initial implementation tends to focus on generating new content, the solution inevitably ends up having to migrate their legacy content. The most popular, out of the shelf, ETL solution available in the market for Documentum migration today is Crown Partner’s Buldoser.

Now, do you really need to buy the product for this purpose?

And here are some of Bulldoser’s out standing features besides the standard data/content migration:

ACL, SCS Config Objects, Alias sets Migration
Integration into other external data sources
Relationship management
Uses pure Java
Ability to undo

Sure, its a great product – and with the growing customer size, the features keep getting added into the application and has a big price tag, appropriately so. Now, how many of the customers need all these features and having to pay for it. Why not make this a service based application so that they could pay for what they need? And of course, if a project heavily relies on – data migration between dev/qa/prod or frequently replicating docbases or archiving objects off-line etc., then absolutely purchase the product.

Ofcourse, there is Mclaren and Blue Fish’s DIXI (which, by the way, is boring to show in a demo with developers participating – the very words from the sales manager who was performing a demo for us – now come on, what is the customer paying for – the slide show or the product?). I found Mclaren’s Docloader, the cheapest of the lot.

I had in the past have slapped together applications (in Docbasic during the EDMS98 days – when by the way, I am not sure, if Bulldoser even existed, and in Java later on) for data migration specific for the customer needs. In a given environment, if the business logic is already available as BOF, how difficult is it to slap together a decent application that does the content migration for you – no bells & whistles attached, mind you. And especially after you get the first version right, its just a matter of improving it in every subsequent run.

I have implemented legacy imports into Documentum as Documentum Methods. And if the document needs to be saved in Documentum as a PDF rendition (for legacy content), please do not scare the customer with RPTS, when there are very reliable tools available in the market. One of which is Lowagie’s iText, which can render PDF’s on the fly. And friends, it is production ready! We have been running the Documentum job for several months rendering (& loading) few hundred thousand documents a day – and its been running without a single glitch. And it was slapped together in less than a man-week (including QA). Even if the developer charges an exorbidant $200/hour, it costed the customer $8000 to get the data into Documentum. And, if only care is taken to use configuration files to dictate the content type, its attributes, format etc., you nailed it for less than 1/4th the cost.

Again, like I said, if you are replicating a docbase having ACL’s, VD’s etc., by all means, the products available out of the shelf are well worth it. And if there are more loads expected by different groups and the cost is shared across different business units, sure, purchasing might turn out to be a cheaper solution. But if you already have a team of developers, make sure to run it by them, before the call is made.