Documentum Upgrade to 6.7 – a simple approach

Back in July, we wrote a lessons learned post regarding upgrading from Documentum 6.5 to Documentum 6.7.   We have a client that recently completed, by himself, a Documentum upgrade from 6.5 SP3 to 6.7 SP1.  While TSG often assists clients in the Documentum upgrade process, some clients are very capable of performing upgrades on their own if they chose a simple approach.  This post will share some of the client’s thoughts on the upgrade and how the combination of TSG products as well as good knowledge of his environment made the upgrade relatively painless.   The only issue the client had was due to some bad documentation in regards to the xPlore upgrade that will be shared as well.

Background

The client, a Nuclear Utility, initially implemented Documentum 5.2 back in 2004 with a custom FirstDocs component.   We later found out at EMC World 2012 from some ex-FCG employees that this client was the only utility that had ever implemented FirstDocs.  Needless to say, the extensive customizations of Webtop for this version of FirstDocs, as well as lack of support, prevented the client from upgrading until 2010.  In 2010 the client successfully migrated away from Webtop and FirstDocs to Documentum 6.5 and implemented the suite of products from TSG including HPI and ActiveWizard.  Given end-of-investment announcements on Webtop and prior experience, the client choose to move completely away from Webtop or any Documentum interfaces for users.

Upgrade Documentum 6.5 SP3 to Documentum 6.7 SP1 – Early September

Simple upgrade steps for the client included:

1. Deploy 6.7 sp1 in development environment with an upgraded OS (Windows 2008 R2).  The client decided to only update the Documentum components that included Content Server, xPlore and Documentum Administrator.
2. HPI and ActiveWizard did not require any upgrade to work in the new Development Environment
3. xPlore needed to be re-installed and re-indexed.  One major issue, consistent with our earlier post, was the level of effort required for the xPlore upgrade.  While the documentation stated that the indexes could be preserved, they really had to be redone.  Unfortunately this resulted in a 2 day delay and included uninstall of xPlore, reinstalling and removing the indexes from the repository with a DQL command and some help from EMC support.  Once up, xPlore took 36 hours to re-index the content.

The client estimated that, with exception of xPlore troubleshooting and reindexing, the complete effort took a day in development followed by a day to reproduce in production.  Users were informed that full-text search would be down for 1.5 days while xPlore server was being reindexed.

Summary – All Documentum Upgrades are not the same.

This quick post highlights something clients have been experiencing with Documentum upgrades.  As we highlighted in a previous post, a Documentum backend upgrade is not that difficult.  It is the front-end – whether Webtop or newer components (xCP, D2), that require the most work during the upgrade.  Our client found that leveraging the TSG interfaces allowed him to simplify the upgrade process.  We recommended, in another post, that some clients consider running their older applications on an upgraded backend to get support without the hassles of the front-end upgrade.

We would anticipate that upgrades to newer interfaces, whether that would be D2 4.0 or xCP 2.0 from other environments (DCM, Webtop, xCP 1.0) would be considerably more difficult.  Let us know your thoughts below.