Migrating Data to Veeva Clinical Operations

This guide provides best practices for migrating clinical study data to Vaults with the Veeva Clinical Operations application family. The general best practices and data transformation considerations for Vault migrations apply to all application families.

Use Case

The primary use case for a clinical Study migration is an incremental migration. This commonly involves having one set of studies and then going live with a second set of studies. In this case, you must migrate additional data to accommodate the second set of studies.

Study Migration Mode

Study Migration Mode helps load studies faster and reduces downtime during migrations. We recommend using Study Migration Mode for all Veeva CTMS migrations, particularly when handling large volumes of object data. Study Migration Mode is intended to be additive with Record Migration Mode. Learn more about Record Migration Mode.

Effects

When a Study enters Study Migration Mode, Vault makes study-related object data for that Study hidden and uneditable for non-Admin users. This locks down target studies that are being migrated while allowing users to update documents and input data for the remaining studies. See the list of objects with the Migration field for more information.

Study Migration Mode also bypasses productized triggers for the target studies, such as calculating metrics and generating related records.

Certain jobs exclude studies that are In Migration from processing.

Standard Vault to Vault Connections exclude studies that are In Migration. Vault to Vault Connection jobs continue to process updated records that were bypassed while the study was being migrated.

Enablement

If your Study object uses an object lifecycle, Vault Admins must configure a user action that marks a study as In Migration. Learn more about status and archiving studies.

You can enable Study Migration Mode for Study records using the following methods:

For new Study records:
- For all objects with the Migration field, use Vault Loader or Vault API to set the study_migration__v field with the value m__v.
For existing Study records:
- Recommended: Enable Study Migration Mode for the existing Study via a user action available on the Study object record.
- Before loading additional data, set study_migration__v with the value m__v for all existing Study object records and related clinical object records that are within the scope of the migration. To enable Study Migration Mode for multiple studies in a single operation, use Vault API.

Considerations

Consider the following when conducting a clinical Study migration:

Because Vault bypasses productized triggers, you should load additional data, such as related records, as part of the migration process.
Because Vault bypasses certain consistency checks, you should account for this when migrating data.
Admins should make the user action to initiate Study Migration Mode available for studies in a particular lifecycle state.
You cannot execute the action to initiate Study Migration Mode in bulk via the Vault UI. Instead, use Vault API to enable or disable Study Migration Mode for multiple studies in a single operation.
While in Study Migration Mode, Vault hides standard Study-related object records (with the study_migration__v field populated) from all users except Vault Owners, System Admins, and users with the Application: All Object Records: All Object Read permission.
Custom objects may still be visible to users.

Bypassing Custom SDK Code

When Study Migration Mode is enabled, Vault also bypasses the Clinical App SDK by default.

You must write additional code for a custom SDK to have the same behavior as the Clinical App SDK. Because Study Migration Mode is controlled by the study_migration__v field on a record, you should update the custom SDK to read this field and check if a study is in Study Migration Mode.

Objects with the Migration Field

The following objects have a study_migration__v field available for use in a clinical Study migration:

budget__v
cdx_agreement__v
central_monitoring_event__ctms
clinical_user_task__clin
crm_activity__v
ctn__v
ctn_data__v
ctn_data_change_log__v
ctn_ip_name__v
ctn_remarks__v
ctn_site_ip__v
cycle_time__v
edl__v
edl_item__v
edl_item_template__v
enrollment_status__ctms
fee__v
fee_schedule__v
fee_schedule_template__v
fee_template__v
form_answer__v
icf_site_effective_tracking__ctms
informed_consent_tracking__ctms
metrics__ctms
metrics_over_time__v
milestone__v
milestone_package_document__v
monitored_informed_consent_form__ctms
monitored_metrics__ctms
monitored_subject__ctms
monitored_subject_event__ctms
monitored_subject_visit__v
monitoring_compliance__ctms
monitoring_event__ctms
monitoring_schedule__v
monitoring_schedule_template__v
payable_item__v
payee_override__v
payment__v
pdv__ctms
procedure__v
procedure_def__v
quality_issue__v
response__ctms
review_comment__v
safety_distribution__v
selected_site__ctms
site__v
site_fee__v
site_fee_def__v
site_sae_tracking__ctms
site_checklist__sys
site_checklist_pal__v
site_section__sys
study_arm__v
study_cohort__v
study_communication_log__ctms
study_country__v
study_critical_data__v
study_critical_process__v
study_organization__v
study_person__clin
study_product__v
study_risk__v
study_risk_assessment__v
study_risk_category__v
study_risk_mitigation__v
study_site_location__ctms
subject__clin
subject_informed_consent_form__v
team_assignment__v
trip_report_question_response__ctms
trip_report_template__ctms
visit__v
visit_def__v