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. Continue reading
Supersized Documentum Migrations and Upgrades Two Billion Documents and Counting
Two weeks ago we completed several of the largest Documentum migrations and upgrades we’ve ever seen. With short outage windows, we helped plan and support our client’s migration of their Documentum systems from a data center in the southeast US to the Rockies while simultaneously upgrading the repositories from Documentum 6.5 to 6.7 SPx. Altogether the repositories contained over 2 billion documents, several TB of file server and multiple Centera devices; as well as over 425,000 ActiveWizard forms!
Documentum 5 vs. 6, Databases and Dates: Does Anybody Really Know What Time It Is?
When EMC revealed Documentum 6 a few years ago, they made a subtle—yet important—change to the way Documentum would store dates and times in the database. While most clients would never even notice the change, some of us would. In particular, when it becomes necessary to access the underlying database tables, like OpenMigrate can when preserving modification dates, confusion can be the order of the day.
Migrating From Documentum with OpenMigrate: Best Practices
OpenMigrate, TSG’s open source migration framework, supports migration to and from a number of ECM repositories, including Documentum, Alfresco, FileNet and SharePoint (and many others).
We’ve designed OpenMigrate to perform several different types of migrations:
- Between different instances of the same ECM product (e.g., during an upgrade)
- Out of one ECM technology into a “neutral zone” (usually a file system and database or text files for metadata)
- From a neutral zone into an ECM technology
- Out of one ECM technology directly into another (e.g., Documentum to Alfresco)
While the general pattern of migrating content and metadata is consistent across all of these migration types,
Documentum Upgrade – Understanding Impact of WDK Development
It has been TSG’s experience that the biggest effort in most Documentum upgrades is the compatibility of customizations made to Documentum interfaces (Webtop mostly). While many of our clients choose to develop custom interfaces that migrate easily leveraging HPI or OpenContent, this blog post will only address Webtop customizations.
As detailed in our Planning Guide for Documentum Upgrade to 6.5 we recommend building an inventory all of the customizations made to core Documentum products before beginning the upgrade process. When Documentum users upgraded from the 5.2.5 platform to 5.3, the smaller WDK customizations were simple to upgrade, but the larger ones were more difficult and time consuming. With the move to D6 the same is true. The complication factor depends heavily on what features the customization leveraged and if those features were modified in D6. Below are typical customizations that should be reviewed prior to upgrading to D6.
Migrating Menu Customizations
In D6 menus are managed in XML configuration files and not in a JSP as in 5.3. All menu customizations would need to be upgraded for D6. EMC provides a set of steps to manually transform a JSP file to a properly formed XML by replacing tags from the JSP file with new XML tags.
With D6.5 going forward, AppBuilder is no longer supported for Aspect and privileged BOF. Documentum Composer is a new Eclipse-based IDE and allows for a well-defined plug-in model and a standard IDE with support for D6 features such as aspects and the Documentum Foundation Services.
Migration of Documentum 5.3 AppBuilder docapp archives can be deployed in the D6 environment with Composer. Documentum Composer is capable of performing this migration by importing a 5.3 docapp and then exporting it as a Documentum Archive (DAR) which can be deployed with Composer.
Right Click Menu
The ability to right click menus is new in D6. However, if there are custom menu options that apply to the files being selected, a new customization to add this menu option to the right click menu should be considered.
This is also a new feature in D6, like the right click menus, it allows for the option to enhance the customizations to enable keyboard shortcuts to launch custom components. There is a moderate level of effort required to add keyboard shortcuts to the defaults including an XML definition and a reference in the JSP. This feature can be disabled entirely from the XML configuration if no keyboard shortcuts are desired.
Streamline View Customizations
The Streamline view is removed from D6 and any customizations to the streamline view will be lost upon upgrading. The most common place to migrate these customizations is to the right click menu. If the customizations were more comprehensive, a significant amount of development effort may be required to redesign the changes in the new interface.
Content Transfer Applet Removed
Earlier performance enhancements to UCF content transfer were discussed. These modifications brings changes to the WDK and the potential for upgrade difficulty with specific types of customizations. Any customization that leverages the content transfer applet will no longer be supported in D6. This could potentially be a complex effort to modify such instances to use the UCF file transfer utility instead.
Datagrid changes and additions
One of the most heavily modified components in D6 is the Datagrid. Enhancements allow for mouse and keyboard selection, right click menus, fixed column headers, and resizable columns. Upgrading any WDK customizations that contain Datagrids will likely require some rewrite. There is an option to disable all new Datagrid features from the app.xml, but this is not recommended since this will eliminate many of the improved D6 features. Almost all of these upgrade efforts are contained at the JSP level and simply require updating tags to refer to the new D6 features.
Global Registry Considerations
Unlike previous versions, D6 requires one repository to be designated as the Global Registry. This will be the central location use to store common objects used by all repositories such as SBOs, BOCS, and user settings. If a Global Registry is already implemented, it can be used with a repository upgraded to 6.5. When performing an upgrade to D6, all TBO and SBO objects need to be evaluated and a strategy to migrate them to the Global Registry defined.
Changes to DQL
There have been several minor changes to the behavior of DQL statements and execution. It is unlikely that this will cause conflicts in customizations, but to ensure a smooth upgrade, any customized DQL queries in code or configurations should be evaluated.
- Maximum accepted string lengths is now governed by maximum defined in the underlying rational database
- The POSITION keyword is no longer supported
- CHANGE…TYPE can now be used outside custom object types
- Enhancements to the date literal allow for addition date formats.
If you have any questions or other input, please comment below.