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:

• Key factors influencing the migration approach ( rolling  vs. an in-place “all-at-once” migration)
• Porting customizations from the legacy system to the upgraded system
• Ensuring external systems that interfaced with the legacy system continued to work with the new system

Migration Approaches

Two Migration Approaches were considered and reviewed for the migration effort:

Rolling Migration

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.

The following diagram illustrates such an effort:

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:

1.      Clone the existing docbase (database + content) to new target hardware and perform an in-place Documentum upgrade

2.      Install FDRD into the upgraded docbase

3.      Convert all documents to FirstDoc aware objects (i.e. change the documents’ object types to the FirstDoc specific object types)

4.      Call the FirstDoc SetACL and SetLink routines to ensure that the documents’ permissions and folder locations are set to business requirements

These steps are illustrated in more detail below:

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.

Secure Login

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.

Remote Import

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.

External Systems

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.

Trackwise Integration

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.

Conclusion

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.

Background

A large generic pharmaceutical manufacturer needed to migrate a subset of documents from their legacy GxPharma solution to a FirstDoc FDQM 5.0 system. Sitrof is a vendor neutral integrator, always looking for the best approach for individual customers.  We also believe in building on past successes.

After much research and consideration with a previous customer (See previous case study), we decided to build a custom migration utility rather than use an off the shelf product like Buldoser or FME’s migration-center.  That approach proved to be successful and we had envisioned using this custom utility for future migrations.

This particular client preferred to use CSC Configuration Management Utility (CMU) to perform the migration.  They had confidence in CMU and had performed a similar migration several years ago.  They were looking to adopt a consistent migration approach and toolkit to perform the FDQM migration along with any other migrations needed in the future.  While Sitrof had experience using the CMU to move FirstDoc configurations from environment to environment, we had never used the tool to perform a migration to or from a repository outside of FirstDoc.

The FirstDoc solution was already in production, presenting an interesting set of circumstances.  Other complicating factors were the GxPharma system was running Documentum version 4.2.8 while the FDQM system was running Documentum version 6.0 SP1 as illustrated below.

The Sitrof Approach

We had hoped to use CMU 5.0 to perform the entire migration.  However, CMU 5.0, which uses DFC 6.0 SP1, cannot connect to a 4.2.8 repository.   We worked around this issue by using CMU 4.2 to perform the export while using CMU 5.0 to perform the import and any post import processing steps.

A typical E-T-L (extract, transport, load) model for this type of migration would be to export the content, apply metadata transformation rules and then import into the FirstDoc repository.  With past migrations, we exported the metadata into database tables which provides an efficient and convenient way to update metadata values based on migration rules (e.g. existing documents with r_object_type of sop will have a document_type value of Standard Operating Procedure).

CMU does not provide a way to write metadata to a database but instead, writes it to an XML file.  Fortunately, rather than having to modify values within the XML export file, the CMU provides a means to transform values during the export itself so that the metadata in the resultant XML already has the transformed value.  Using the ‘transform’ attribute in the CMU ObjectExporter allows you to call your own JavaScript code where more advanced transformation rules can be applied.  Many of our transformation rules were handled in JavaScript code where either the rule was hard coded or read in from spreadsheets that contained the mapping rules.

Once the export was complete, the exported metadata resided in XML and the content resided on a file system.  The import process was very straightforward; we just used the CMU ObjectImporter to import the exported XML files.  The ObjectImporter provided a handy “save_object_id_map” feature that produced a CSV file that created a map of the old r_object_id to the new r_object_id.  This map can be useful if you wish to import audit trail values but need to update the old object Id to the new object Id.

Once the documents were imported, there were several post import steps that had to be performed.  These tasks included creating FirstDoc relationships between documents (e.g. an SOP related to a Form), calling the FirstDoc methods AutoNumber (to assign a new document number), SetACL (to apply the appropriate document security based on the document’s type and subtype) and SetLinks (to link the document to the correct folder location).  The CMU TaskManager was used to call a series of JavaScript programs to perform these tasks.

Observations

We were pleasantly surprised by the number of CMU options available to facilitate a migration.  For this particular migration, 40,000 documents (all versions) and tens of thousands of audit trail records were migrated.  While the performance was adequate for a migration of this size, the CMU would not be our tool of choice for a larger scale migration.  Also, the CMU would not be a viable option if there was a need to migrate from a non-Documentum based source system.  Nonetheless, since most FirstDoc customers already own the CMU it should be considered as an option for your next migration.

A global pharmaceutical company and Sitrof client uses FirstDoc R&D for managing their FDA submission content. After acquiring another life sciences company they were left with submission content in three disparate content repositories; one in FirstDoc and the other two lightly customized versions of Documentum. The company tasked Sitrof with defining the migration mapping requirements, evaluating configurations and customizations in the source system and implementing a technical solution in order to migrate this mission critical content and metadata.

Sitrof is committed to sharing their expertise in unstructured data for information management, data protection and compliance.

A global pharmaceutical company and Sitrof client uses FirstDoc R&D for managing their FDA submission content.  After acquiring another life sciences company that were left with submission content in three disparate content repositories; one in FirstDoc and the other two lightly customized versions of Documentum. The company tasked Sitrof with defining the migration mapping requirements, evaluating configurations and customizations in the source system and implementing a technical solution in order to migrate this mission critical  content and metadata.

Key points to consider when performing such a migration include:

• FirstDoc Object Model
• Migration of FirstDoc Configurations
• FirstDoc API
• FirstDoc Migration

FirstDoc Object Model

When performing a migration from one FirstDoc system to another, it is important to remember that FirstDoc interfaces rely on the FirstDoc object model to function correctly. The FirstDoc object model for the FDRD module is reproduced below:

All objects that extend from the fdk_document type are recognized by the FirstDoc interface to be FirstDoc documents. If types are to be mapped from one FirstDoc system to another, this is important since mapping to a type that does not extend from fdk_document will cause the document to become a normal non-FirstDoc document.

Properties of the fdk_document in all FirstDoc:

FirstDoc extends the Documentum Type architecture to Subtype, Unit, and Subunit. Thus, a mapping of the Types, Subtypes, Units and Subunits is required from one system to the other. This is usually achieved in the requirements gathering phase, after mapping has been decided upon. Furthermore, each FirstDoc module has other special mapping requirements which are unique to each module. For example, in the FDRD module, all FirstDoc documents extend from the r_and_d_document type which has the required attribute ‘product’. Each unique product is associated with a Product Dictionary in the FDRD system.

When migrating from one repository which has a different set of products to another, all product dictionaries must be created from the source system in the target one. Products may also be mapped from the source system to the target one in which case a new product dictionary does not need to be created. This is illustrated below:

For a successful migration of all documents, all products must be completely mapped or created in the target system since the FDRD module will not allow documents to have products which do not have a Product Dictionary.

Migration of FirstDoc Configurations

FirstDoc is a client-driven enforcement of server-side configurations, meaning that all FirstDoc rules and security are enforced at the Web layer. The rules are implemented and stored in the Content Server. Every FirstDoc configuration is associated with at the minimum a Type and a Subtype and at maximum the Unit and Subunit.

During migration, this presents us with two scenarios:

• All Types and Subtypes are mapped completely from the Source System to the Target System. In this case, migration of FirstDoc configurations might not be necessary--unless the configurations from the Source System to the Target system are in conflict with each other. In this case, the business owners of the source system and the target system must decide which configurations to keep.
• Some Types and Subtypes from the Source system are created as new Types and Subtypes in the Target System. In this case, the configurations associated with these type-subtypes might have to be migrated to the Target System. These new type-subtypes must also be added to the FirstDoc Dictionary of the Target System. To assist in the migration of the configurations, the FirstDoc CMU Tool could be employed.

FirstDoc API

FirstDoc provides developers with an extensive set of JAVA API to perform many of the server-side functions that are executed upon user-interaction. For the purposes of migration, only the API related to the following two functions are important:

• Refoldering API: Documents in FirstDoc are foldered according to their Type and Subtype. This is stored in a FirstDoc configuration. During import of the documents, one must run the Refoldering API so that the documents are foldered at the right place.
• Security API: Documents in FirstDoc inherit their ACL according to their Type and Subtype. This is also stored in a FirstDoc configuration and during import of the documents, one must run the Security API so that documents attain the correct ACL according to the FirstDoc rules.

The flow of the Import program is thus illustrated as below:

FirstDoc Migration

This section summarizes all the above points and provides a visual for the overall FirstDoc Migration:

Background

Our client is a pharmaceutical business unit of Akzo Nobel NV, a multinational company based in the Netherlands. Today, our client has nearly 10,000 employees and is active in more than 100 countries.

Business Challenge

Our client's West Orange, NJ, facility faced a growing challenge of managing their Standard Operating Procedure (SOP) documents. With the volume of documents increasing at 20% per year, their paper-based approach was very labor-intensive, expensive and error prone.

Objectives

Create an electronic document management system that will accomplish the following:

• Decrease review and approval times
• Reduce copying and shipping costs
• Provide better reporting capabilities.

Technical Solutions

Sitrof Technologies, Inc. used Documentum 4i server with customized Desktop Client (DTC) front-end.

Application

Customized DTC components such as Check-In, Properties, and Task Manager. New DTC components such as Reassign Tasks, Pull Reviewer Tasks, and Submit Change Request.

Tools

Visual Basic for customized DTC components. Active Server Pages and XML for web based workflow reports.

Results

• Documents are now reviewed and approved 50% faster.
• Thousands of dollars a year have been saved in photocopy and shipping charges.
• Web-based workflow status reports eliminate the need to track down who is currently working on a document and gives the Document Administrator the control to improve productivity.
• Electronic sticky notes make it easier for document authors to read reviewer comments.
• Electronic backups reduce the amount of storage space needed SOPs available to all users via the company Intranet.

Closing Statement

Sitrof built a custom electronic SOP system that has greatly reduced the amount of time spent reviewing and approving documents. This has allowed our client to re-deploy resources that were previously dedicated to make photocopies and collecting hand signatures.