**Source URL:** https://general.veevavault.dev/safety/migrations/guides/safety

# Migrating Data to Veeva Safety

This guide provides best practices on migrating data into Vaults with the Veeva Safety application. The [general best practices](/safety/migrations/references/migration-best-practices) and [data transformation considerations](/safety/migrations/references/data-transformation) for Vault migrations apply to all application families.

## Use Case

The primary use case for a Safety migration is a [legacy migration](/safety/migrations/overview). This involves migrating safety *Cases* from a legacy system to Vault. This commonly includes migrating the most recent versions of *Cases*, but may include migrating previous versions as well.

## Safety Migration Configuration

Safety Migration Configuration is a feature that allows a designated user to migrate safety data into Vault via ETL [Vault Loader](https://platform.veevavault.help/en/gr/26597) or [Vault API](/safety/vault-api/api-reference/26.2/safety), while ensuring performance and data integrity. This also allows *Cases* to be migrated into a live Vault without altering the migrated data by applying *Case* processing automation (such as calculations or record auto-creations).

### Safety Migration User

The term Safety Migration User will be used consistently in this article, and it will always refer to the user selected as the Migration user in the Safety Migration Configuration.

### Effects

Safety Migration Configuration bypasses most triggers and actions available only for the designated Safety Migration User. Only a small subset of key triggers continue to execute, required for creating object records. This improves the performance of loading in *Case* records. See the list of  for more information.

If the user attempts to execute a trigger that is not allowed during migration, the following error message appears:

`You do not have permission to modify {0} records. Contact your administrator if changes are required.`

### Enablement

To enable the Safety Migration Configuration feature in your Vault, create the *Safety Migration Configuration* (`safety_migration_configuration__v`) object record, change its lifecycle state to *Active*, and assign it to a Safety Migration User.

The *Safety Migration Configuration* object is not shown in Business Admin by default, therefore, you must create an object record using one of the following methods:

*   **Recommended**: Use the direct link to the object tab: Go to `https://{vault_dns}/ui/#object/safety_migration_configuration__v`
*   Use [Vault Loader](https://platform.veevavault.help/en/gr/26597) or the [Create & Upsert Object Records](/safety/vault-api/api-reference/26.2/vault-objects/create-upsert-object-records) endpoint to create a *Safety Migration Configuration* record.
*   To create a record in the UI, navigate to **Configuration > Objects> Safety Migration Configuration** and change the **Show in Business Admin** setting to **Yes**. Some customers may require a change control to modify what is shown in Business Admin.

Safety Migration Configuration records contain the following fields.

| Name | Description | Type |
| --- | --- | --- |
| `name__v` | The system automatically generates a name for the record. | System-managed |
| `user__sys`<Requiredness type="required" /> | Select the *User* record that corresponds to the migration user. | (Unique) Object reference to `user__sys` object |
| `enabled__v` | To activate this configuration and allow this user to bypass triggers for migration, set to *Yes*. | Yes/No |

### Considerations

*   Safety Migration Users cannot import E2B files. When you import a *Case* record using E2B Case Migration, the resulting *Case* is an *Imported Case*. An *Imported Case* is a special type of *Case*, reserved for previously processed and migrated *Cases*. See [Migrate External Cases](https://safety.veevavault.help/en/gr/01217) for more information.
*   Because product triggers are bypassed, you must ensure that core functional elements (versioning, idates, etc.) are populated manually.
*   Only the following user groups have permission to create *Safety Migration Configuration* (`safety_migration_configuration__v`) records:
    *   Vault Owners
    *   App Owner
    *   System
*   A Safety Migration User must already have permission to create the types of records they are migrating.
*   Once data migration is complete, you must perform one of the following actions in your Vault to resume normal access for the migration user:
    *   Edit the *Safety Migration Configuration* record and set the `enabled__v` field to **No**.
    *   Delete the *Safety Migration Configuration* record.

### Bypassing Custom SDK Code

Veeva Safety product triggers are bypassed by default when they are triggered by the Safety Migration User.

Additional code needs to be written for custom triggers to have the same behavior. Failure to do so will result in major performance issues during migrations.

The following Vault Java SDK code demonstrates how to bypass a trigger in migration mode:

```java
@RecordTriggerInfo(object = "case_version__v", events = {RecordEvent.BEFORE_INSERT, RecordEvent.BEFORE_UPDATE})
public class SampleTrigger implements RecordTrigger {
    @Override
    public void execute(RecordTriggerContext recordTriggerContext) {
        final QueryService queryService = ServiceLocator.locate(QueryService.class);

        // Get the current user ID from the context
        final RequestContext context = RequestContext.get();
        final String currentUserId = context.getCurrentUserId();

        // Query safety migration configuration for enabled users
        final String queryMigrationUsers = "SELECT user__v FROM safety_migration_configuration__v WHERE enabled__v='true'";
        final QueryResponse queryResponse = queryService.query(queryMigrationUsers);
        final boolean isMigrationUser = queryResponse.streamResults()
                .anyMatch(queryResult -> Objects.equals(currentUserId, queryResult.getValue("user__v", ValueType.STRING)));

        if (isMigrationUser) {
            return;
        }

        // Perform remaining trigger logic
    }
}
```

### Bypassed Auto-Calculations

The following [auto-calculations](https://safety.veevavault.help/en/gr/01154) do not calculate when using a Safety Migration Configuration:

*   [Case Relatedness](https://safety.veevavault.help/en/gr/01160): Veeva Safety automatically populates the *Relatedness* field at the *Case*\-level, for high visibility of the relatedness (causality) evaluation from the primary *Case Assessment* and its *Case Assessment Results*.
*   [Case Expectedness](https://safety.veevavault.help/en/gr/737264): Veeva Safety assesses expectedness for each *Case Assessment* through system-generated *Case Assessment Expectedness* records.
*   [Dose Latency](https://safety.veevavault.help/en/gr/01159): Veeva Safety automatically calculates the *First Dose Latency* and *Last Dose Latency* on *Case Assessment* records.
*   [Cumulative Dose](https://safety.veevavault.help/en/gr/01157): Veeva Safety automatically calculates the *Cumulative Dose* field on the *Case Product* when the required data points are available.
*   [Case SAE and SUSAR Tags](https://safety.veevavault.help/en/gr/01156): New and revised *Cases* that meet the appropriate seriousness criteria are automatically tagged with *SUSAR* or *SAE* *Case Tags* to aid in ad-hoc reports and data analysis.
*   [Case Watchlist Tags and DME](https://safety.veevavault.help/en/gr/01158): Veeva Safety automatically determines whether a *Case* should be tagged as a Designated Medical Event (DME) or with a preconfigured watchlist tag.
*   [Age Fields](https://safety.veevavault.help/en/gr/01153): Veeva Safety automatically calculates and populates the *Age (normalized)*, *Age at Onset*, and *Age Group* fields.
    *   Imprecise dates (`_idate__v`) to Normalized Dates (`_date__v`)
    *   Patient Date of Birth
    *   Patient Date of Death
    *   Patient Last Menstrual Period Date
    *   Receipt Date
    *   New Info Date
    *   Adverse Event Onset
    *   Adverse Event Cessation
    *   Medical History Start Date
    *   Medical History End Date
    *   Drug History Start Date
    *   Drug History End Date
    *   Case Test Result Test Date
    *   Dosage First Admin Date
    *   Dosage Last Admin Date
*   Localized *Cases* must have all children present
*   Assessments must point to an *Adverse Event* and *Product*
*   *Cases* must have a primary *Product* and *Adverse Event*

---

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