The document provides an overview of clinical study migrations, detailing Perficient's expertise in facilitating this process, the reasons for migration, and necessary pre-planning, technical, and business considerations. It outlines the methodology for executing study migrations including project planning, validation, data export/import processes, and lessons learned from case studies. Additionally, it emphasizes the importance of involving stakeholders impacted by migrations and ensuring comprehensive documentation and testing throughout the process.

1. An Introduction to Clinical Study Migrations
May 24, 2017

2. 2
About Perficient
Perficient is the leading digital transformation
consulting firm serving Global 2000 and enterprise
customers throughout North America.
With unparalleled information technology, management consulting,
and creative capabilities, Perficient and its Perficient Digital agency
deliver vision, execution, and value with outstanding digital
experience, business optimization, and industry solutions.

3. 3
Perficient Profile
Founded in 1997
Public, NASDAQ: PRFT
2016 revenue $487 million
Major market locations:
Allentown, Atlanta, Ann Arbor, Boston, Charlotte, Chicago,
Cincinnati, Columbus, Dallas, Denver, Detroit, Fairfax,
Houston, Indianapolis, Lafayette, Milwaukee, Minneapolis,
New York City, Northern California, Oxford (UK), Southern
California, St. Louis, Toronto
Global delivery centers in China and India
Nearly 3,000 colleagues
Dedicated solution practices
~95% repeat business rate
Alliance partnerships with major technology vendors
Multiple vendor/industry technology and growth awards

4. 4

5. 5
Today’s Presenters
Tammy Dutkin – Director, Clinical
Data Management and Electronic
Data Capture
- 25 years in the clinical research field
- Previously SVP of a full service CRO
and VP of a Biometrics CRO
5
Richard Gavan - Solutions Architect
- Specializes in Oracle's Health
Sciences portfolio

6. 6
• What is study migration?
• Reasons to migrate
• Pre-planning steps
• Overview of the process
• Validation considerations
• Technical considerations
• Business considerations
• Case studies
Agenda

7. 7
What is study migration?
Study migration involves moving a clinical study from one database to
another database.
Based on multiple client requests, Perficient has developed a process,
using Data Pump, to export a study in it’s entirety from one Oracle
Clinical database and import it into another Oracle Clinical database.
This includes, but is not limited to, the database objects, user accounts,
audit trails and journaling records as well as the data.

8. 8
Study migration using Data Pump
o Data Pump configuration file, aka “parfile”
• List of tables to be migrated
• Filters based on study, user, and domain
• Some “global” tables not filtered
o List of users associated with the study
• User-based filters and audit trail
• User migration
o Custom database objects and integrations
o Database sequences and seed numbers
o Study version and upgrades
o “Empty” database vs. database with existing studies

9. 9
Reasons for study migration
• Archiving
• Transfer of responsibility
• Sponsor change
• CRO change
• Moving to cloud / hosted solution
• Consolidation of databases
• Due to acquisitions or partnerships
• Due to streamlining needs
• Platform change

10. 10
Pre-planning
• Risk/benefit analysis
• Are the benefits of migrating the studies worth the
cost/risk/downtime
• Getting input from all applicable team members
• Set up formal communication channels and escalation plans early
• Understand the requirements, set reasonable goals and create an
overall timeline
• Understand any conflicting priorities or study timelines that need to
be taken in account particularly when scheduling the downtime

11. 11
Process for study migration
Planning
•Project
•Validation
Analysis
•Technical
•Business
•Validation
Development
• Data export /
import
process
•Installation /
upgrade log
(if needed)
•Testing
scripts
Dry run /
informal
testing
•Migration and
installation
•Testing (IQ,
MQ, post
migration
cleanup)
Validation
• Execute
migration/inst
allation into a
Validation
environment
•Formal
documented
testing (IQ,
OQ/PQ, MQ)
Production /
Go Live
•Execute
migration /
installation
into Prod
database
•Formal
documented
testing (IQ)
Close out /
Hypercare
•Summary
Reports
•Support

12. 12
Process for study migration: Validation planning
Validation Planning
• Validation Plan
• IQ Protocol
• OQ/PQ Protocol (if determined to be required and/or version of
platform will be upgraded as part of the migration)
• Migration Documents
• Migration Protocol
• Migration Requirements Specifications
• Migration Trace Matrix
• Migration Test Case Development

13. 13
Process for study migration: Project planning
Project Planning
• Project Plan with tasks, dates, resource assignments
• Communication plan
• Regularly scheduled meetings
• Take in account resource availability, holidays, study timelines and
deliverables for scheduling the production downtime

14. 14
Process for study migration: Analysis
Technical Analysis
• Determination of tables that need to be migrated and the filter requirements
of those tables
• Review of integration points
• Review of custom programming which may be impacted by the migration
• Determination of how user accounts, roles and study/site security will be migrated.
• Conflict analysis (if migrating into a database that already has data)
Business Analysis
• Review of downstream processes that may be impacted by the migration
• Determine how new users will be trained and given access to the new system
• Determine how the system changes and downtimes will be communicated to users
Validation Analysis
• Understand what will be migrated
• Identify risks and develop mitigation strategies
• Develop migration requirements specifications and determine how those issues
will be addressed

15. 15
Process for study migration: Development
Development (note this can be done in a temp environment)
• Data Pump parameter file
• The plan/scripts for transfer of external programs, files, logos, user lists, etc.
• Install and upgrade instructions
• Development of testing documents and trace matrix based on the migration
requirements specifications
• Development of any supplemental testing documents (i.e. user role testing,
integration testing)
• Development of post migration cleanup instructions (i.e. retiring procedures
that won’t function in the new database, resetting TMS dictionary objects)

16. 16
Process for study migration: Dry run/informal testing
Dry run / Informal Testing
• Installation of a testing database
• Run export scripts in source database (Data Pump and any scripts
involving external programs etc.)
• Transfer the files
• Import the files into the target database
• Dry run post migration cleanup document
• Dry run any migration, installation or supplemental test cases
• Finalize all of the export/import scripts, installation/upgrade scripts, testing
documents

17. 17
Process for study migration: Validation
Formal Validation of the migration
• Installation of a validation environment (documented)
• Run export scripts in source database (Data Pump and any scripts involving
external programs etc.)
• Transfer the files
• Import the files into the target database
• Execute the post migration cleanup document
• Execute the migration, installation and/or supplemental test cases
• Summarize the results of the validation (IQSR, MQSR)

18. 18
Process for study migration: Production
Production cutover
• Installation of a production environment (documented)
• Remove all access to the study in the source database
• Run export scripts in source database (Data Pump and any scripts
involving external programs etc.)
• Transfer the files
• Import the files into the target database
• Execute the post-migration cleanup document
• Execute IQ and any supplemental testing that is required

19. 19
Process for study migration: Close out and hypercare
Close out
• Summarize the results of the validation (IQSR, VSR)
• Release the system to the users
Hypercare
• Prepare to provide extended support to assist users who may have log in
issues or have questions

20. 20
Validation considerations
• Important that the process is fully documented, from the plan to the actual results
• QA should have input from technical and business subject matter experts to
ensure the process is detailed
• Risk based approach can be used, but all decisions made to test/not test,
migrate/not migrate etc should be fully documented
• Follow your SDLC process
• Perficient’s process included the following documents (note how there is a
plan/protocol that is followed by it’s own summary report):
• Validation Plan  Validation Summary Report
• Installation Qualification Protocol  Installation Qualification Summary Report
• Migration Qualification Protocol  Migration Qualification Summary Report
• Operational Qualification Protocol  Operational Qualification Summary Report
• Change Plan  Change Summary Report (if migrating into a database that
already has data)

21. 21
Technical considerations
• Important to provide adequate time for development and informal testing, including
multiple exports from source production system
• Need to confirm list of tables and associated filters with current and future study
owners, if applicable
• List of users should include all users that have ever touched a study or currently have
access to it to ensure all audit trail details (journaling table data) are captured
• Resetting passwords of existing users and distributing credentials
• Empty database vs. database with existing studies
• Must ensure source and target have different seed numbers, otherwise conflicts
may arise
• Must perform conflict analysis for global records
• Global audit trail data increases complexity and decision must be made how to
handle it, for example by enabling OC audit trails during import

22. 22
Technical considerations
• Customizations and integrations
• Migrate all database objects (views, procedures, functions, synonyms, etc.) used by
study in OC (e.g., in derivation/validation procedures or extract macros)
• Migrate any custom logos and RDC News items
• Study version, upgrades and character sets
• Need to ensure source data matches OC/RDC version of target database
• Need to ensure source data matches character set of target database
• Upgrades and conversions can be performed in staging database

23. 23
Business considerations
• Really important to include people impacted by the migration so that risks to downstream
processes can be taken into consideration and fully mitigated before the move to production
• Imperative that there is someone familiar with the source database, including any
customizations (back-end custom objects, custom database roles) especially if the team
performing the migration don’t have access to the source database
• Some programming may not function post migration. Decisions will need to be made as to
how to resolve those issues (post migration cleanup) or if those items are non-critical to the
team post migration, how to minimize the impact
• Derivation/Validation programs that call upon custom external objects that are outside
the scope of what is being migrated
• TMS dictionary/domains will need to be created and handled post migration
• Integrations with other systems that are outside the scope of migration will be broken

24. 24
Case Study 1
Background
A small spin-off device company needed to migrate 4 ongoing OC/RDC/TMS studies from their parent
company into their own new hosted OC/RDC/TMS database. All 4 studies would be migrated at one
time into an empty OC/RDC/TMS database. The target database would be the same character set and
the same version of OC/RDC/TMS as the source database.
Challenges
• Because of the limitations on our previously marketed product, Accel Copy, it was determined that
we needed to develop a new, highly scalable process for the migrations.
• The parent company’s CDMS system included numerous integration points, custom database
objects, email notification programming and tens of thousands of users in their source database.
• The 4 ongoing studies needed to be migrated with minimal downtime and no downtime or adverse
effects on the parent company’s system.

25. 25
Case Study 1 (cont.)
Successes / Lessons Learned
• Because our team had worked previously with the source company, we were allowed full
access to the database to do the analysis and the exports ourselves. This was ideal as it
allowed us to do numerous test exports and database queries while we developed our
process without disturbing the sponsor.
• Sponsor allowed most global tables to be exported without filters (e.g. GLIB objects, LAB
subsystem, Codelists). This simplified the process and there were less issues
encountered due to “missing” objects.
• Implications of changing the TMS dictionaries were not fully realized until post-migration
of validation database.
• Client opted to run a full proc compare of the SAS export which although took time, did
help them in their preparation for post go live and identified several issues with custom
extract macros that was missed during the analysis phase.

26. 26
Case Study 2
Background
We were hired by a CRO to migrate 7 studies into a new hosted OC/RDC/TMS database for its
client who had purchased the drug rights from a major pharmaceutical company. Due to study
timelines, it was determined that the first 6 studies would be migrated initially. The 7th study would
be migrated at a later date but would need to be imported into the same database. The source
database was version 5.0, but the CRO wished the database to be upgraded to 5.1 as part of the
migration.
Challenges:
• We had to incorporate an upgrade (with a full OQ) into the process
• This was one of the first upgrades to 5.1 that we had conducted, and we ran into quite a few
bugs that required additional time to troubleshoot
• We had to develop a modified migration process to allow a migration of 1 study into a non-
empty database
• We did not have any access to the source database. All exports, analysis and testing from
the source database had to be done by the pharmaceutical company

27. 27
Case Study 2 (cont.)
Successes / Lessons Learned
• Custom user roles from the source were not conducive to the process flow of the
CRO so new roles had to be created and tested post migration. This added to the
project timelines.
• Testers from the source side did not have access to all of the menu options needed
to capture the screenshots required as part of the migration testing and were not
familiar with Perficient’s execution practices. In further projects we have moved to
SQL row count scripts more so than screenshots which has reduced our testing
time. We also sent a resource onsite to execute the source scripts themselves.
• Had to develop a process for migrating a study into a non-empty database

28. Questions
Type your question into the chat box

29. 29
For information about Perficient’s capabilities, please email
Jessica.Knowles@perficient.com.
Perficient will be hosting several additional webinars to
offer more details on the technical and validation/business
aspects of this process, including:
• Validation and Business Considerations for Clinical
Study Migrations (August 3, 2017 at 9-10 A.M. CT)
Additional Resources
• Perficient.com/SocialMedia
• Facebook.com/Perficient
• Twitter.com/Perficient_LS
• Blogs.perficient.com/LifeSciences