There are a variety of essential validation and business considerations that should be evaluated when migrating clinical studies from one database to another (with or without existing data). Having a clear understanding of downstream study processes and receiving input from cross-functional teams are just some of the keys to a successful migration. In this SlideShare we discuss several case studies that provide insight into: The steps followed during a study migration process, from validation and business perspectives Validation considerations for migrating into an empty database, as well as a database that already contains data Suggested documentation for the migration process Business continuity considerations to ensure a smooth study migration for all team members Best practices and lessons learned

1. Validation and Business Considerations for
Clinical Study Migrations
August 3, 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
Kay Laskowski – Lead Business
Consultant, Life Sciences
- 25 years in the clinical research
field
- Experience consulting in Data
Management, PV, and Drug Safety
and QA
Joe Daly – Senior Business
Consultant, Life Sciences
- Over 20 years in the clinical data
management field
- Senior-level clinical data
programmer

6. 6
• What is study migration?
• Reasons for study migration
• Overview of the process
• Business considerations
• Validation 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
Perficient and study migration
Reasons for migration, overview of the
Data Pump process, and technical
considerations were presented in the
webinar ‘An Introduction to Clinical Study
Migrations’ in May 2017.
https://youtu.be/lKrMcw3pWzI

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

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

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

12. 12
Identifying and managing business risks
Migration Impact Considerations
• Might not be able to migrate everything
• Assess risk versus cost
• What is the business risk and how can it be mitigated?
• Validation, derivation or extract macros may not function post migration. Can these be re-
programmed at a later date?
• TMS verbatim term assignments may not transfer. Are there resources available to handle
any manual recoding that is needed?
• When is the best time to take an active database down for the production migration? Is it
better to migrate into an empty database so as not to impact studies that are running?

13. 13
Migration strategies
Not All Migration Projects Are the Same
A migration project can be streamlined if major points are
considered during the planning stage.
• Subsystems – Can major subsystems be eliminated
based on non-use (Labs/TMS)?
• Custom Programming – Identifying and planning for
dependences on custom external packages
(derivation/validation procedures, extract macros, etc.).
• TMS Dictionaries – Have dictionaries been customized?
Will manual steps be needed to ensure coding in target
database?
• New logos – Can image files be easily provided during
planning?
• Custom User Roles – Estimate time for creation and
testing of custom roles.
• Thesaurus DVG – File/table dependency consideration.

14. 14
Conflict analysis when migrating into a populated database
Conflict Analysis
• Where the target database is populated with existing objects and
ongoing clinical trials, it is important that the migrating source objects do
not conflict with target objects.
• A detailed conflict analysis produced by Perficient identifies differences
in all database objects, such as global library, reference code lists,
design elements, etc.

15. 15
Conflict resolution rules
Addressing Conflicts
• After a detailed analysis of all conflicts, an
informal risk assessment is provided to
the client for review.
• Each individual conflict may be resolved
with various approaches
–Retain data as defined in the source
database
–Retain data as defined in the target
database
• Beyond creating rules for database object
conflicts, it is important to also consider
conflicts with user accounts and user
privileges.

16. 16
Post-migration cleanup
Post-migration Cleanup
• To avoid impact to migrating studies and down stream processes, manual
modifications may be necessary following the migration. These updates are
detailed in the post-migration cleanup document.
• Examples of a manual modifications
• Retiring derivation procedures which call custom package, not present in the
target database
• Checking/unchecking “Active” flag for DVG values
• Assigning the migrated study to a different TMS domain
• Updating a reference codelist value

17. 17
Informal testing – What to test?
Informal Testing
• Once a target test environment is available, informal testing of functionality
known or suspected to be effected by migration, are tested.
• Examples of informal testing include:
• Running Batch Validation, data extracts, graphic layout editing
• Confirming menu paths and eCRFs can be opened and display correctly
• Confirming accounts migrated over have the expected access privileges
• Basic system functionality (installation qualification)
• Impact of filters on specific tables migrated over
• Testing for impact on other studies in the database
• Informal testing can reveal issues with system functionality, custom
programming dependencies, and also drive the development of testing
requirements.

18. 18
Requirements gathering
Migration Requirements Specification (MRS)
• Client and Perficient collaborate to determine
the overall extend of migration testing, as well
as the level of detail appropriate for a
particular migration project.
• Essentially the MRS is list of everything that
will tested/compared between source and
target databases.
• Important to involve client team members
who have technical knowledge of OC, source
clinical study data, as well as source
database customizations.

19. 19
Development of testing documents
Testing Documentation Overview
• Migration Qualification Test Suite (MQTS)
• SQL row counts and specific OC/RDC screen captures executed on source and compared to
target to verify matching results after migration
• Installation Qualification (IQ)
• Testing OC/RDC/TMS installation and/or version upgrade
• Custom User Role Checklist
• Testing the OC menu access for custom user roles
• Supplemental IQ
• Example, testing installation of a new character set

20. 20
Conducting migration testing
Migration Qualification Test Suite (MQTS)
• Example of a SQL listing executed as part of MQTS might be row counts
of the total number of DCIs for a study, by DCI status (Active, Provisional,
and Retired).
• Source data access restrictions may require tester to be onsite.
• Source MQTS execution should be as close to data export as possible.
• To avoid any data changes in RDC after Source MQTS execution the
“DCI forms Entry Enabled” checkbox can be unchecked as way to prevent
RDC access in the source DB. This flag is then checked in the Target
database after migration

21. 21
Production cutover
Production Cutover
• Determine the least invasive timeframe for the system to be taken off line
• Important to identify any upcoming database locks, interim analysis, or other
study deadlines for either source study or ongoing target database studies,
and plan the production cutover accordingly
• Execute post-migration cleanup document
• Execute migration, installation or supplemental test cases
• As documented in Val Plan/Change Request/Protocol
• Summarize the results of the validation (IQSR, MQSR)

22. 22
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)

23. 23
Validation plan
• Validation Plan vs. Change Plan
• Validation Plan
• Migrating into new database
• Requires testing of the base application
• Change Plan
• Migrating into database with existing data
• System is in place and has been
validated

24. 24
Validation plan
• Validation or Change Plan should follow your SDLC procedure/templates and
should include the five W’s: Who, What, When, Where, Why (and How)
• Who: audience, roles and responsibilities of the team members
• What: scope of the project, methodology
• When: optionally reference a project plan
• Where: testing and production environments
• Why: project background
• How: brief summary of Qualification Testing

25. 25
Validation plan table of contents example

26. 26
Validation plan
• Validation Plan creation
• Author: Quality Assurance or trained
designee
• Include input from IT, system owner, SMEs
• Review and Comment: Project Manager,
IT/Installer, system owner, stakeholder,
QA, SMEs
• Approve: author, system owner,
stakeholder, QA
Your SOPs may differ – always
follow your SOPs

27. 27
Protocols
• Qualification Testing is outlined in the Plan
• Change Plan may be a hybrid of the Validation Plan and Qualification Protocols
• Protocols describe more completely the What and How of the project
• System diagram
• Referenced testing documentation (installation log, test cases)
• Testing instructions
• Test execution instructions
• Success/Failure definitions
• Documenting discrepancies
• Resolving issues

28. 28
Protocols
• Different protocols may be needed for
each phase of the qualification –
dependent on overall migration
complexity
• Installation Qualification (IQ)
• Operational
Qualification/Performance
Qualification (OQ/PQ)
• Migration Qualification (MQ)
• Author, reviewers, and approvers are
outlined in the Plan

29. 29
Installation qualification
protocol
• Tests new database install and/or existing
database clone
• Usually executed for both Validation and
Production environments
• Installation Qualification (IQ) Protocol includes:
• System specifications/diagram
• Installation and/or cloning overview
• Qualification Documentation
• IQ test suite
• High level testing to verify installation
is correct
• Installation Log
• Cloning Log
• References Summary Report

30. 30
Operational qualification/performance qualification protocol
• Tests the functionality of the system
• Typically executed in Validation only
• Operational Qualification/Performance Qualification Protocol includes:
• Testing overview
• Qualification Documentation
• OQPQ Test Suite
• Mapped to functional and/or user requirements
• Very detailed testing to verify functionality
• Reference to OQPQ summary

31. 31
Migration qualification
protocol
• Tests the study migration
• All study objects present
• All study data present
• Typically executed in Validation
• Migration Qualification (MQ) Protocol
includes:
• Testing overview
• Qualification Documentation
• MQ Test Suite
• Migration Logs
• Reference to Migration summary

32. 32
User acceptance
testing
• Optional testing executed by users of the
system
• Can be informal or formal
• Users can log in and successfully
access their studies
• Users can perform job-related tasks
• Integrations are working as expected
• May be documented in the Validation Plan

33. 33
Testing documents – Requirements, Trace Matrix, Test Cases
• Requirements
• Broad description of system specifications
• User Requirements – defined by users to ensure the system meets their business needs
• Functional Requirements – system functionality according to vendor-supplied documentation
• Requirements will drive the development of test cases
• Trace Matrix
• Mapping of the requirements to test cases
• All requirements must be mapped to at least one test case in the Trace Matrix
• All test cases must be listed in the Trace Matrix and verify at least one requirement
• Test Cases
• Detailed step-by-step test that verifies the requirement has been met
• The relationship of requirement to test case can be one-to-one, one-to-many, many-to-one, or
many-to-many

34. 34
Testing documents – Requirements, Trace Matrix, Test Cases
Requirement
Trace Matrix:
Requirement to
Test Case
Test Case

35. 35
• Types of testing
• IQ testing
• Does not require requirements/trace matrix
• Test cases designed to broadly test common functionality
• All new installations, clones of existing installations, upgrades require IQ testing
• OQ/PQ testing
• Requires requirements/trace matrix
• Test cases are detailed and designed to verify/test requirements
• New installations require OQ/PQ testing
• Upgrades may or may not require full OQ/PQ testing (Risk Assessment)
Testing documents – Requirements, Trace Matrix, Test Cases

36. 36
• Types of testing (cont.)
• Migration testing
• Requires requirements/trace matrix
• Requirements pertain to migration and not overall functionality of the system
• Example: Row counts in source database match row counts in target database
• Test cases are detailed and designed to verify/test requirements/migration data
• Study migrations require migration testing
• Integration testing
• May or may not require requirements/trace matrix/test cases
• Integration testing may be part of user acceptance testing which does not always
have a requirements or trace matrix document
• May be included in the migration testing requirements/trace matrix
• Integration testing is required for upgrades and study migrations when the system
(source or target) has one or more integrated system other than TMS
Testing documents – Requirements, Trace Matrix, Test Cases

37. 37
Testing documents –
Requirements, Trace Matrix,
Test Cases
• Types of testing (cont.)
• User role testing
• Requires requirements/trace matrix
• May be combined with the migration
requirements/trace matrices
• Requirements pertain to testing custom user
roles and not overall functionality of the system
• Because of the complexity of the user roles, the
requirement may reference a spreadsheet which
contains the user role detail
• Example: Data Management user role can
access the menu paths displayed in the User
Role spreadsheet.
• Test cases are detailed and designed to verify/test
requirements/user role data
• Upgrades and study migrations require user role
testing when the roles have been customized in the
source database

38. 38
Protocol execution summary reports (PESR)
• A report will be created to summarize the results of each qualification protocol
(phase of testing)
• The report should include documentation anomalies, discrepancies from the protocol,
test results (pass/fail percentage), and any incidents reported during testing
• The summary report should only include results specific to the protocol for which it is created
• Each protocol will have at least one summary report
• IQ Protocol will have two summary reports: one for Val and one for Prod testing
• Ideally each testing phase will be successfully closed before starting the next phase
• IQ summary report approved before OQ/PQ testing begins
• OQ/PQ summary report approved before migration testing begins

39. 39
PESR example table of contents

40. 40
Validation summary reports (VSR)
• At the completion of all qualification testing, a report will be created to summarize
the results of the validation plan
• The report should include documentation anomalies, discrepancies from the
protocol, test results (pass/fail percentage), and any incidents reported during any
phase of testing
• The VSR should include results of all qualification protocols outlined in the
Validation Plan
• The VSR should include an overall statement of validation for the system

41. 41
VSR example table of contents

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

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

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

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

46. Questions
Type your question into the chat box

47. 47
For information about Perficient’s capabilities, please email
Jessica.Knowles@perficient.com.
Register for our next webinar:
• Enriching the Value of Clinical Data with Oracle Data
Management Workbench (August 10, 2017 at 9-10 A.M.
CT)
Additional Resources
• Perficient.com/SocialMedia
• Facebook.com/Perficient
• Twitter.com/Perficient_LS
• Blogs.perficient.com/LifeSciences