**Source URL:** https://limited.veevavault.dev/clinical/migrations/guides/clinical

# 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](/clinical/migrations/references/migration-best-practices) and [data transformation considerations](/clinical/migrations/references/data-transformation) for Vault migrations apply to all application families.

## Use Case

The primary use case for a clinical *Study* migration is an [incremental migration](/clinical/migrations/overview). 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](https://platform.veevavault.help/en/lr/761685).

### 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  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](https://clinical.veevavault.help/en/lr/4345/#managing-archived-studies).

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

*   For new *Study* records:
    *   For all , use [Vault Loader](https://platform.veevavault.help/en/lr/26597) or [Vault API](/clinical/vault-api/api-reference/26.3/clinical-operations/enable-study-migration-mode) 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](/clinical/vault-api/api-reference/26.3/clinical-operations/enable-study-migration-mode).

### 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](/clinical/vault-api/api-reference/26.3/clinical-operations/enable-study-migration-mode) 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`

---

**Previous:** [Guides](/clinical/migrations/guides)  
**Next:** [References](/clinical/migrations/references)