A major pharmaceutical company, and long standing Sitrof client, used a very highly customized Documentum WDK Application for content authoring and submission management. While this system served the company well for many years, it ran counter to the company’s IT philosophy of moving to commercial off-the- shelf solutions.
Computer Science Corporation (CSC) was contracted to gather application requirements, perform production configuration and installation. Sitrof was engaged to gather the extensive document, user, configuration and customization migration requirements as well as to perform the design and execution.
This case study discusses the unique challenges such a migration and upgrade effort presents, including:
Two Migration Approaches were considered and reviewed for the migration effort:
A rolling migration is broken up over time to facilitate a gradual, incremental migration. The migration is divided into distinct chunks using business specific criteria. Documents are migrated from the legacy system on a department- or product-level basis to the new system.
For such an approach, the configurations and customizations to support the entire migration effort over its entire timeline are installed in the new system before any actual content is migrated. This ensures that all the functionality is always available as soon as the content is.
Often the different departments slated to use the new system convert their business processes at non-coinciding times in support of the migration. If this had been a limiting factor, then a rolling migration approach would be the only possible approach. However, this was not the case in this project, which allowed us to explore following migration approach.
In-Place “All-At-Once” Migration
An “all-at-once” migration is where all the documents, users, configurations and customizations necessary for a complete migration are done in a single chunk, usually over an extended weekend.
An in-place upgrade is one where an upgrade to the existing software is done instead of migration to a new system with the new software. An advantage of this approach from a Documentum perspective is that the unique object identifiers are left intact whereas a rolling migration requires that the object identifiers change. This was the main driving factor for the selection of this migration approach, because the business used a submission publishing system that stored these identifiers. Updating the object identifiers in the publishing system would have added increased project complexity and extended project timelines.
The following high-level process was followed in order to move the legacy system to a new FirstDoc Research & Development (FDRD) environment:
Configurations & Customizations
Because migration involved moving from a legacy Documentum System to a FirstDoc FDRD system, it was necessary to convert all documents to FirstDoc objects. Sitrof interacted closely with the client Subject Matter Experts (SMEs) to determine the FirstDoc type/subtype/units for all the existing documents. In cases where documents could not map to existing document inventory, Sitrof worked with CSC in order to have new types/subtypes/units added to the system.
The client also had WDK Customizations in the legacy systems, which Sitrof helped port over to the FDRD system by merging this functionality into the FDRD UI where possible.
The client’s IT security policy dictated that all passwords traveling on their networks be encrypted. However, using network sniffers, it was found that passwords were being passed from the WebTop/FirstDoc login screen in the application server to the Content Server in clear text. Sitrof customized the WebTop/FirstDoc login component to encrypt the passwords passed to the Content Server.
A customization of the legacy system was the ability to import documents from a list of pre-defined FTP servers directly into the Documentum repository. Sitrof merged this functionality into the FirstDoc Bulk Import function so that document import from FTP Servers is treated in an identical manner to the documents imported from the File System.
Product Dictionary Loader
The client had an existing data warehouse that contained product, regulatory, clinical and nonclinical information, and did not want to manually maintain these dictionaries within FDRD. Sitrof developed a series of custom jobs that queried the data warehouse on a daily basis and automatically created the appropriate FirstDoc Product dictionaries within FDRD whenever new data appeared in the data warehouse.
Architecture Sizing / Performance Testing
Because this was a mission-critical system, the client wanted to ensure that it was properly sized to handle current and future volume. Sitrof worked with the client’s internal testing and infrastructure teams to develop performance tests to stress all individual components of the system. The joint team also stress-tested the overall system itself by designing “day in the life” scripts.
Special attention was paid to all external systems that interfaced with the legacy system to ensure that the interfaces would work after migration. If a modification to the interface was needed, Sitrof made this change.
The existing legacy system was integrated with Trackwise, allowing users to view content residing in Documentum from a Trackwise screen. Sitrof ported this customization to work with the latest version of Documentum and FirstDoc. Sitrof also customized FirstDoc to write the unique Documentum identifier to Trackwise any time a health authority correspondence document was approved within FirstDoc.
Sitrof was involved from inception to the finish of the project, and oversaw a large part of the development and migration efforts that were required for a successful completion of the project. The client was able to decommission their legacy solution shortly after going live with the FDRD solution.