Many of our clients have end of year deadlines for projects. One of our newest clients contacted us with an unprecedented challenge – could we upgrade them from 32-bit Documentum 6.5 SP1 to 64-bit Documentum 7.0 Patch 12 by early December given availability of certain funds. This post will present the project and some best practices in regards to the upgrade.
Onsite versus Offsite and Health Check
Most clients typically request TSG resources work offsite as much as possible to avoid travel related costs. With a short timeline, We recommended the work be done onsite.
As we do for all our upgrade projects we began with our Health Check to learn the layout of the Documentum environment, products and customizations. Fortunately, the client had kept the system in good health and had already upgraded Webtop and DA to 6.7 SP1 on a 64-bit server. On inspection, there were a few customizations to Webtop that needed to be tested and some jars in the JMS that would need to be moved. We recommended purging documents that were past their retention to speed up the content storage transfer, shrink the database, and reduce indexing time.
As with most clients, we found that one of the biggest hurdles to a short timeframe is how responsive support teams can be for server stand-up, storage allocation, and database installs. Utilizing the clients ticketing system and leveraging good relationships and close proximity, we were able to stand up the new 64-bit environment for the Content Server, xPlore, and CTS in days, sometimes less than a day. The teams were also able to modify the servers for us to add more storage and RAM on very short notice. Without a solid support team, this project would have been impossible to deliver.
The Documentum Upgrade
Early on in the project, we chose the clone approach for the new hardware rather than a migration approach. Cloning is a necessity when moving from 32-bit to 64-bit hardware, but it is also useful for preserving the original system for a rollback option. This post lists several other benefits of using new hardware, Documentum 6.7 Upgrades and Hardware Changes.
Cloning the production environment and running the upgrade in the development environment was a marathon effort. The next step was the production upgrade. The onsite presence and continual availability of the team was key as we were able to resolve issues nearly as soon as they popped up. The production upgrade had minimal issues and completed well within the outage window. Due to the early completion of the Content Server upgrade, we were able to have the users work in the system on Sunday instead of using the paper backup process.
xPlore Upgrade and Timing
While we were able to hustle the upgrade, it wasn’t officially finished until xPlore reindexed the content. The xPlore indexing was kicked off as soon as the users finished testing the system on Sunday. The sizing of the server was estimated for indexing close to 4 million documents. Using the xPlore sizing tool from EMC, we anticipated about 40 hours for content indexing.
Noticing unusual server activity, consisting of high page swapping, we discovered that the xPlore server was only set up with 4GB RAM. This was significantly less than the 32GB RAM we originally specified. After upping the RAM, we continued the indexing process as planned. xPlore indexing is one of the most common pain points with an upgrade.
In doing upgrades, we see these types of issues all the time and it is worthwhile to double check all server configurations.
Summary
While we wouldn’t recommend a short timeline for all upgrades the unique circumstances of this team and client allowed us to move as fast as we needed in order to meet their early December upgrade goal. Several key points to remember:
- Begin with a health check – outside resources typically see things that day-to-day maintenance doesn’t always recognize.
- Consider Clone versus Migration approach when leveraging new hardware
- Remember xPlore indexing time – no easy way to migrate indexes and will need to be rebuilt. Users should understand performance and other restrictions while indexes are being built
TSG Blog 
Great article,
When cloning – did you have to consider that the New h/w, O/S & DB – be compatible with both – 6.5 as well as 6.7 – because the cloned system would be initially 6.5 and then upgraded to 6.7?
We had to once upgrade an old 5.2.5 system to 6.7 – and this O/S & DB compatibility limitation – along with a multi-stage upgrade – were the main considerations in deciding to use a migration approach; which as you have pointed, required more indepth planning and longer execution than a cloning approach
Hi Paras –
Thank you for the kind comment. Yes, when moving from the 32-bit servers to the 64-bits servers we had to consider what Documentum and DB software would run on both. 6.7 is the version for Documentum. We installed the 32-bit version of 6.7 on the 64-bit server and upgraded the repository to that version and then installed the 64-bit 6.7 version over top of the 32-bit version. From there we could upgrade to the 64-bit 7.0 product. For the database we used SQL Server 2008 as the 32-bit to 64-bit cross-over. We exported from the older 32-bit version and then imported into the 64-bit version and let SQL Server do its magic. It is definitely a multi-step process.
I have done an upgrade where we switched from Windows to Unix and SQL Server to Oracle and for that we used a content migration.