There are a variety of essential technical considerations that should be evaluated when migrating clinical studies from one database to another. Does the incoming data need to be “merged” into an existing database? What if the source application has been customized? What obstacles can be expected? Where does regulatory compliance come into the picture? In this SlideShare, Richard Gavan, a solutions architect in our life sciences practice, discusses several case studies that provide insight into the: Steps followed during a study migration process, from a technical perspective Technical considerations for migrating into an empty database or a database that already contains data – and how to decide between the two Actions needed to preserve the integrity of clinical audit trails Difficulties and opportunities presented by existing customizations Pitfalls and challenges that may be encountered Lessons learned

1. Technical Considerations for
Clinical Study Migrations
December 7, 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
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
5
Richard Gavan – Solutions Architect, Life
Sciences
- System administrator, database
administrator and software developer
specializing in Linux and Windows
platforms
- Focuses on Life Sciences projects,
including:
- Project 1
- Migrate large home-grown clinical
analysis and reporting application
- Solaris to Red Hat Linux
- Integrated with HPC platform
- Project 2
- Migrate seven OC studies from legacy
CRO environment to new hosted
platform
- Project 3
- Migrate three OC studies from legacy
CRO environment to new hosted
platform

6. 6
• Migration Process Overview
• Moves and Merges
• Upgrades and Conversions
• Audit Trails
• Customizations
• Challenges and Opportunities
• 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
Perficient and Study Migration
Reasons for migration, overview of the
Data Pump process, and technical
considerations were presented in our
webinar “An Introduction to Clinical Study
Migrations” in May, 2017.
https://youtu.be/lKrMcw3pWzI
Additional details were given in “Validation
and Business Considerations for Clinical
Study Migrations” in August, 2017.
https://youtu.be/H9YxOUWZlwA

9. 9
Migration Process Overview
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/
installation
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

10. 10
Migration Process Overview
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/
installation
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

11. 11
Migration Process Overview
• Export
–Tables
• List of tables for your version of the application database
• Metadata inspection script to generate list of users implicated in audit trail
• Filters for extracting only a single study or subset of studies
–Sequence
• Tables use numeric sequences to track record identifiers
–Custom objects
• Derivation/validation procedures, extract macros, thesaurus DVGs may depend
on external objects such as stored procedures, tables and views

12. 12
Migration Process Overview
• Upgrade and Convert
–Data application version upgrade
–Character set conversion
• Import
–Import tables
• Disable triggers, foreign key constraints
–Apply sequences
• Run script to update all tables with latest sequence numbers
–Import custom objects
–Import Users
• Typically without passwords

13. 13
Moves and Merges
• Move
–Target database is a newly created database with the target application installed,
but no data entered
–All global data is either already existing or new
–Keep new data to capture configuration/customization
• Merge
–Target database is an already-existing database with the target application
installed; some data has been entered and system is live
–Some global data may conflict with existing
–Conflict resolution
• Create copy of target database for development, attempt to import
• Review log for errors, compare conflicting rows
• Update import script to account for whether to keep existing or incoming record

14. 14
Upgrades and Conversions
• Upgrade
–Target database application version does not
match the source database
–Data must be upgraded prior to final import
–Need to create staging database where data
will be imported and upgraded first prior to final
import
• Character Set Conversion
–Target database character set does not match
the source character set
–Data must be converted prior to final import
–Either update in the source system or in staging
database

15. 15
Clinical Audit Trail
• Need to ensure necessary identifying information for users implicated in audit trail for
study being migrated
–Users may no longer be active
–Accounts don’t necessarily need to be migrated
–But the contact info does (e.g., Oracle_accounts table)
• Some applications do not have a straightforward mapping of users to the studies
they’ve touched
• Need to inspect existing audit trails to compile list of users
–Query username column of journaling tables
–Query created_by, modified_by, etc. fields of standard tables

16. 16
Conflict Analysis
• Attempt to import into copy of target
database, similar to standard process
• However, import probably won’t succeed
• Inspect import errors to determine which
tables had a conflict
• Refresh target database copy, import
conflicting tables into a different schema
• Use SQL operations to identify just those
rows that had a conflict
• Determine whether to keep existing data
or replace with new
• Update import scripts accordingly

17. 17
Customizations
• Customizations of the existing system need to be accounted for. This can include:
–Customized defaults and settings
–Custom data
• Thesaurus DVGs
–Custom programming
• External procedures, packages
–Custom images
• CRF Logos
–Customer user roles and permissions
• Migrate each object appropriately
–Customized defaults and settings included in standard tables
–Custom data, custom programming objects migrated via SQL or Data Pump
–Images transferred
–Custom database roles created, permissions migrated

18. 18
Challenges
• Heavy customization can significantly increase effort
–Especially if existing customizations are not well documented
–Try to identify all of them during analysis; otherwise, testing effort may be delayed by
issues discovered
• Downtime
–Target database will need to be offline during the final import
–Not a problem if importing into new database
• Export/import iterations
–Typically, development of migration scripts involve at least two exports from the
source system
–Risk for delays if a new export cannot be readily obtained
–Even worse when there’s poor communication

19. 19
Opportunities
• Database Cleanup
–Migration affords an opportunity to retire
unneeded dependencies and objects
–Avoid migrating perceived dependencies if they
are not required in the new system
–Cleans the database and makes the migration
easier
–Testing will be occurring anyway, this may be a
good time for some cleanup
• Multiple goals in the same project can reduce
total effort
–E.g., study migration with upgrade, character set
conversion, and merge
–Accomplish goal of moving the study, upgrading
the application, upgrading the hardware, etc.

20. 20
Case Study
We were hired by a large CRO to migrate 7 studies into a new hosted OC/RDC/TMS database for
its client that 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
–Application bugs
• Project involved upgrading to OC 5.1; encountered a number of bugs
• Effort increased due to having to discern application vs. migration defect during development and testing
• At least one bug was data-specific
–Did not have access to source system
• Had to coordinate with legacy vendor and timelines depended on their availability
–7th study needed to be merged into the same database
• Conflict analysis increased complexity and effort

21. Questions
Type your question into the chat box

22. 22
For more information about Perficient’s capabilities or to
set up a free clinical study migration brainstorming
session to explore options most relevant to your
situation, please email Jessica.Knowles@perficient.com.
Next Steps
• Perficient.com/SocialMedia
• Facebook.com/Perficient
• Twitter.com/Perficient_LS
• Blogs.perficient.com/LifeSciences