A merger or acquisition often necessitates the process. But it could be a lack of support for legacy systems, or the increased cost of maintaining old hardware overshadowing the cost of migration. It could simply be the desire to switch to a less expensive document management solution.

In any case, running multiple document management systems parallel to one another is not an option – such a situation is confusing to end users, resulting in a productivity drain. Plus, IT expenses skyrocket as maintenance time increases and hard costs rise.

Analyzing processes, planning the transition, getting buy-in from staff, implementing the changes – who can companies trust to get it done right the first time? For more than a decade, Sitrof has performed complex migrations for Fortune 100 companies, successfully migrating content from a variety of sources to different target repositories. With a special focus on life sciences companies and regulated environments (including those governed by FDA 21 CFR Part 11), Sitrof is the trusted provider for complex content migrations.

The Sitrof Approach

Backed by years of life sciences experience and world-class software industry partnerships, Sitrof is the industry leader in vendor-neutral system integration services.

No two migrations are the same. Sometimes, an off-the-shelf migration tool – like Buldoser or FME’s migration-center – can get the job done. Sometimes, a custom solution is necessary. Sitrof offers best-of-breed solutions when it comes to either approach – or a combination of the two.

Recently, a large generic pharmaceutical manufacturer needed to migrate a subset of documents from their legacy GxPharma solution to a FirstDoc FDQM 5.0 system. The company elected to use CSC Configuration Management Utility to perform the migration, but a unique set of complicating factors required a unique solution. The GxPharma system was running Documentum version 4.2.8, while the FDQM system was running Documentum version 6.0 SP1. Because CMU 5.0 uses DFC 6.0 SP1 and cannot connect to a 4.28 repository, Sitrof issued CMU 4.2 to perform the export while using CMU 5.0 to perform the import and post-import processing steps.

Essentially, if a company owns a migration utility, Sitrof can use it. If a company does not, Sitrof can custom-create a solution based on need and cost. Any migration is possible – one system to one system, one system to many systems or many systems to one system. With years of experience moving data into and out of FirstDoc, Documentum, SharePoint, FileNet and DocuShare, Sitrof has the wide-ranging expertise it takes to get the job done.

The Sitrof Process

Sitrof-engineered migrations begin with an in-depth discovery process. By first determining the scope of the project and the tools necessary, Sitrof can, in many cases, even offer an upfront fixed price.

One recent merger brought together two leading life sciences companies – with five distinct document management systems between them. Sitrof identified the requirements for migrating each into the target system, and standardized naming protocols and security procedures. By the time the actual migration started, careful planning had mitigated the risk of unpleasant surprises and bottlenecks. In the end, the complex migration and validation of terabytes’ worth of regulated content proceeded smoothly.

Sitrof’s proven process allows it to migrate a company’s data, content and metadata, no matter how many repositories they have or need. Just as importantly, Sitrof guarantees all migrations are performed successfully through strict validation requirements. Whether it’s a large customer with a set migration methodology or a smaller client in need of consultation, Sitrof ensures FDA and EMA compliance, no matter how rigorous the regulatory requirements.

Don’t go it alone

Trying to complete a migration project in-house can seem attractive from a cost and effort perspective – at first. While the actual migration process – moving documents from Location X to Location Y – seems relatively straightforward, what surrounds it is not. A migration is a golden opportunity to streamline and cleanse systems of outdated and unnecessary documents and files. Without the right people, processes and methodology, businesses can struggle to fully leverage the opportunities a migration provides.

Whatever the reason for undergoing the process, Sitrof offers life sciences companies maximum return on their migration investment, as well as proven, trustworthy, validated solutions for all client sizes.

Dan Wheeler is a managing partner and co-founder of Sitrof Technologies, 700 Alexander Park, Princeton, N.J. 08540.

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.

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, 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.

To read the complete case study, click here.

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.

As I was traveling back from the symposium, I could not help but think about all the great case studies I heard.  I was grateful that Xerox Canada asked Sitrof to speak at the event. We heard some great stories about how a whole host of different companies are leveraging the functionality of Xerox DocuShare.

Kellie Barron, of  Kawartha Pine Ridge School Division, spoke about their five-year strategic model for document and records management. She shared their road map to document success and how their partnerships with Xerox has resulted in a unique licensing structure and a staged approach to DocuShare adoption.  She also shared how Sitrof helped them migrate from EMC Documentum to Xerox DocuShare and the great success of that project.

We also heard from Mike P. Gagel and Maggie Li, of the BC School Trustees Association. They spoke about the evolution of BCSTA DocuShare and how they earned user acceptance through targeted training.  One of the key tools they were using for training is called Camtasia Studio.  They demonstrated its features and how they used it to record and deliver Xerox DocuShare training.  I did further research on the tool and determined it is an inexpensive and easy to use screen capture tool that allow you to easily create robust video demos.  I thought this was a great find.

Another interesting presentation came from Judy Cameron, of Canadian Union of Public Employees (CUPE), one of the largest unions in Canada.  CUPE is using DocuShare to manage its electronic documents, creating a virtual research library and managing its records, archives and e-mail through Xerox DocuShare. How  interesting that they are using traditional library bibliographic control to manage the thousands of publications and records produced by CUPE yearly.  Because of this indexing, they can quickly find needed documents--making the deployment a success.

After lunch we heard from Mark Bamford of Edmonton Northlands.  Northlands is in the business of producing major events to venues all over Canada. He spoke about why document management is so important and how it allows Northlands to manage its business better. I enjoyed learning more about their relatively large implementation and how they approached eating the elephant--implementing a large project--one bite at a time.  Much like the others, they chose to move forward with precaution, good analysis and a phased approach.  This has created a great experience for all users of the system and strong ROI for the business.

Once Mark was done, it was my turn to present.  I spoke about one of our customers, Copernicus Group IRB, and their case study defining how they achieved a 95% paperless office while remaining 100% Compliant. I discussed their back-file scanning project of 5 million pages of legacy documents, the elimination of printing incoming electronic documents and their automated all paper processes and workflows including electronic routing and digital signature approval with Xerox DocuShare and the Sitrof Compliance Module.

Click here to see the slides:  Sitrof-Copernicus-Case-Study

One element of the symposium that really rang true had to do with phased deployments.  Every case study detailed how they deployed the solution one phase at the time.  This is key to their success.  The best way to move forward with any document management deployment is with proper planning.  It is very important to make sure you allow enough time for strong requirements and design. Furthermore during the process, involving as many users of the system in the beginning ensures that you can achieve total buy-in for the solution.  Over the hundreds of implementations I have been involved in, we have found with these fundamental project principals in place,  you can always achieve success.

I am already looking forward to next year, thank you to all who contributed at the symposium!

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 on of the oldest and largest wealth management firms in the United States managing over 33 billion dollars in assets for over 1,800 clients. Our client is universally recognized for the depth and quality of the personal service they provide their clients.

Business Challenge

The challenge was to migrate an outdated non-supported Watermark Imaging System into a FileNET Panagon IDMCS Document Management System. This required converting 1 million documents from the legacy system into FileNET Panagon. In addition, both systems had to run in parallel over a three month period during the enterprise roll out.

Objectives

• Migrate an outdated legacy system
• Create a new Web-based document retrieval application
• Create a new Scan Application to interface with the new Document Management System
• Create a Backend batch process to sync data from the Legacy Mainframe application and the Web-based document retrieval application

Technical Solutions

Used FileNET Panagon to develop a Web and Client-Server based solution.

Application

Created a series of three major applications. The first was a robust migration tool which was used to migrate the documents stored in two Watermark systems (Palm Beach, FL and New York City, NY). This process was ongoing through the entire project.

The second application was a robust web-based retrieval system that adhered to the complex business rules of the client. It gave the users the ability to view documents, add electronic documents, create barcode scan header sheets, change properties, email documents and sort them in many different views.

The third application was a custom client-server scan tool which leveraged the FileNET Capture toolkit. This application could process barcodes off of the scan header sheets, get the information from an Oracle table, and commit the document with minimal user interaction. The scan application followed the process of Doc Prep, Scan, Image Verification, Doc Processing, Indexing and Committal.

Tools

Visual Basic, Active Server Pages, MSXML. FileNET's IDM Desktop API's and Capture Scan Module

Results

• Users are able to add information directly from their hard drives into the repository in much less time than before.
• Users are able to retrieve the information in a tenth of the time it took with the old system.
• Scanning throughput increased by 200% with the new automated process.
• The number or rejected scan header sheets went from 50-100 per month to 1-2 per month.