Documentum 6.5 to 6.7 Upgrade Lessons Learned

TSG  recently assisted a client with upgrading their Documentum 6.5 environment to 6.7. Products included Content Server, xPlore, Business Process Manager (BPM), Content Transformation Services (ADTS, AVTS, MTS), DA, Webtop, Records Manager, Retention Policy Services (RPS), Archive Services for Reports (ASR), and TaskSpace. The client also runs TSG’s High Performance Interface (HPI) and OpenContent products.

Recently a large manufacturing client came to us asking for help to upgrade their Documentum 6.5 environment to 6.7 since the support for 6.5 reaches end of service life at the end of August. We were asked to help them assess the effort level to bring their entire Documentum stack into the most recent supported version. The following points outline a few helpful things that we came across during the upgrade weekend:

64-bit Hardware

As a part of doing this upgrade, the client wanted to take the opportunity to upgrade their hardware to virtual 64-bit Windows machines.  This meant the upgrade could be performed as a docbase “clone” from the old environment to the new environment. While the clone to the new server was mostly smooth, we encountered a few issues with a workflow template from an existing business process that refused to run after being upgraded to a 64-bit content server.  EMC acknowledged the content server bug, and has since fixed the issue in the P05 patch, but with the timing of the upgrade we were unable to take advantage of it.  The workaround was to re-create the business process in the new version of “Process Builder” and install it directly into the 64-bit content server.


The client had almost 3 million documents in their xPlore index, so a primary concern for the upgrade was if we were going to be able to finish a reindex of the entire repository in the weekend downtime that was scheduled. Lesson learned here is to overestimate the time the index will take to complete, as the xPlore server quickly became memory strapped and needed to be restarted a few times during the reindex operation. The other lesson learned, is that because the HPI product doesn’t require searches to be run against the xPlore index, the client was able to bring their customers back online on Monday morning to perform their daily activities even though the xPlore index operation was not complete.


The client used Documentum Content Services for Centera as their content store. There were a few tweaks that needed to be made to the content server install to point it to the centera store, but overall this portion of the upgrade was easier than expected.

Webtop Customizations

As with any upgrade, WDK customizations need to be checked and re-checked against the new Webtop/WDK codebase as there are often updates to classes and JSPs that will break or alter the behavior of any existing customizations. This can be a particularly time-consuming activity if there are heavy customizations that have been done to the Webtop interface. The upgrade of the HPI application was a much simpler process since the only updates necessary were to point the OpenContent web services layer to the new repository.

Privileged Clients

The suite of records management products from Documentum, including Records Manager and Retention Policy Services, require registration of a client applications’ DFC instance in order to execute certain privileged functions within the DFC. With the change to new hardware as part of the upgrade, each of the client applications had to be re-registered with the Content Server. It is important to note that even if the client DFC is not registered that it will continue to function but will throw an often cryptic error message when it tries to perform an operation on a document with retention assigned.

As with any upgrade, vigilant preparation up-front is the key to success. If you have any questions about your upcoming upgrade, please post about it in the comments.

5 thoughts on “Documentum 6.5 to 6.7 Upgrade Lessons Learned

  1. Will soon be upgrading from 6.0 SP1 to 6.7 (on 64-bit Windoze). We do have one workflow that I’ll have to be cautious of. Since the 6.0 environment is on 32-bit Windows, this will be more of a migration than an in-place upgrade.

  2. Chris – definitely take some time to test the workflow thoroughly on the 64-bit platform. The recent P05 patch from EMC addressed the issue we ran into,

  3. Team, we are in between upgrading 6.5 sp1 to 6.7 sp1. workflow is not working. spoke to EMC support regarding P05 patch you have mentioned, they said P05 he didnt find any thing related to workflow patch, can you please give me more details on this P05 patch you have used and exactly what issue they are fixing. Thanks in advance..

    • Hi Itzmuthu –

      The P05 patch was supposed to fix an issue discovered in testing and logged with EMC, that the Content Server code regarding existing 32-bit pcode (which runs as part of workflow/lifecycle) running against a 64-bit system crashes the server. EMC told us to rebuild the workflow template or wait for P05. We ended up not waiting on the P05 patch for release and instead rebuilt the workflow using the new 64-bit 6.7 SP1 environment we had in development. Rebuilding the workflow fixed the problem.

Comments are closed.