I had an interesting discussion today with a large hospital client that is currently upgrading to Documentum 6.5. Like most of our Documentum customers, the client has chosen to refresh hardware, database, and disaster recovery tools as well as upgrade the operating system (from Solaris 9 to Solaris 10). Initially the client was targeting a database clone approach with an upgrade in place for roughly 1.4 million documents.
As referenced in a previous blog post, the client found the clone approach challenging to say the least – issues they encountered included:
- People – Client needed 5 people to “figure it out” including a DBA, Unix Admin, Storage Admin, Documentum Administrator and Project Manager.
- Downtime – Team estimated that “hopefully” the Documentum system would only be down for 2-3 days.
- Effort – The client thought the 5 person team would take at least 2-3 weeks to “figure it all out” to be able to complete the migration accurately during the 2-3 days of downtime.
While talking to TSG about OpenMigrate, the client decided to try a 2 day proof of concept to use OpenMigrate for a migration approach rather than the clone and in-place upgrade. The proof of concept was successful in handling 90% of the client’s needs. The client IT resources were able to successfully address 100% on their own after the POC with minimal phone support from TSG. Benefits of the migration approach included:
- Reduced Downtime – because the migration approach allowed for “chunks” of archive documents to be moved without bringing the current system down, downtime was reduced from 2-3 days to 2-3 hours.
- Reduced Risk – with less downtime plus the ability to check the integrity of the new system with the archive documents the risk of failure was substantially reduced. Also, the fallback approach was to leverage the old hardware and migrate any newly scanned content. With the clone approach, fallback was much more complex and might involve rescanning content.
- Reduced Development Environment Size – With the clone approach, the client had previously maintained a development environment that was the same size as production. By using OpenMigrate going forward, the client was able to leverage a significantly smaller development environment and only migrate subsets of the production docbase.