Like this:

Greetings,

It was a busy weekend and I had to wind up a lot of tasks.
I was busy with my preparations for moving to my new Home which I bought recently.
After being accustomed to the old place, I was counting on the tasks that I have to do to get the new Home ready to live and only then I came to know that its not just dumping my luggage from one place to another but I have to take care of many more things – time to know the new place now…

Coming back to ECM systems, it’s always a tough task to complete migration projects with 100% success.
Probable reasons are – either we are not sure about the migration strategy’s negative effects or we are not aware of the ECM system completely.
Many enterprises are still struggling to get the new system working as the old one – even after the completion of migration projects.

Here I would like to share one of my expereinces where I was involved in a Documentum Migration Project.
Hold on- It was not from one ECM to another ECM – It was a Database migration( read it: Database A to Database B)
See the requirement description here
Business already decided to move to Database B due to various reasons(read: Vendor recommendation) and I was involved in planning the strategy for the move. Various Third Party Migration utilities like Buldoser and Dixi were analyzed and were among the options we had for an OOTB migration. Documentum “Dump and Load” was also one option and the problem with this approach was the data size to migrate – It was too large (read: several hundred gigs). The question was why not to go with the EMC recommended way and use dump and load; migrate data in small chunks. I tried a small POC for this and ohhh – Dump and Load dumps and loads not only what it is asked but also the related Documentum objects to maintain the integrity. Now this was a good news as well as bad news for us.

When we will go for multiple loads, it will load the same data twice without any complain if it qualifies the “related objects criteria”. Grrr….Due to the duplication of data, we cannot go with this approach…

No worries Mate!!! Time to put your thinking hats on and understand the migration approach first and then go for the implementation.

I had a discussion with my colleagues( read: super computer minds) who were working on this assignment with me and we decided that we would go for a custom solution using Dump and Load, do a POC with the same approach but this time we will play with dump and load.

By this time I was fully enjoying this assignment…We did the POC keeping in mind following points -

• Remove all inconsistencies and run all housekeeping jobs prior the dumps

• Perform a dump and load of user and ACL objects prior to the dump of documents

• No Dump file size should exceed the magic “2 GB limit” (to be very frank, i do not want to use the word “limit” over here)

• Use “Dump without Content approach” thus no need of extra disk space

• For dump of documents, use batch dumps so that the dump file size is always less than 2 GB

• Identify and delete any such folders in the target docbase which is already loaded in the the prior batch dump

• Reconcile the docbases post load

The POC was successful and now we were clear with how dump and load works and of course about our migration strategy.

Now the only task that was left was to automate the entire approach (as we were pretty clear with what we were doing) – using Windows Scheduled tasks( basic utility but helps a lot- I should admit)

We executed the Migration exercise without any issues and enjoyed the execution with “Champagne” (I am sorry to my dear colleagues ( if they are reading) as I just had a sip to accompany them)

Now when I correlate the “migration experience” with “moving to my new home”, I come to the conclusion – Be it a ECM/Database Migration Project or moving from one place to another – You have to put your Thinking Hats ON

See you next weekend…

N.B. Your suggestions and feedback are always welcome.

Advertisement