**Source URL:** https://limited.veevavault.dev/medical/migrations/overview.md

# Vault Migrations Overview



A Vault migration refers to the loading of large volumes of data or documents into Vault. This article is intended for customers considering a Vault migration project. It provides suggestions and best practices for planning, developing, and executing a Vault migration.

The two common migration use cases are:

* **Legacy Migration**: When replacing a legacy system with Vault, it is common to migrate data from the legacy system into Vault. This type of migration usually occurs during the Vault implementation project for a new Vault, but can also happen when implementing a new application in an existing Vault.

* **Incremental Migration**: Any business event which requires adding new data to Vault may require incremental migration. For example, a phased rollout, system consolidation, or a company acquisition. Incremental migrations occur independent of an application implementation and can affect a live production Vault application.

While there are [general best practices](/migrations/references/migration-best-practices) and [data transformation considerations](/migrations/references/data-transformation) that apply when migrating data to Vault, see the following guides for specific application families:

* [Veeva Safety](/safety/migrations/guides)

* [Veeva Clinical Operations](/clinical/migrations/guides)

* [Veeva Quality](/quality/migrations/guides)

* [Veeva RIM](/regulatory/migrations/guides)

## Approach {#approach}

At a high level, data migration into Vault generally requires the following steps:

<Steps>
1. Extracting data from a legacy system

2. Transforming data into the target format

3. Resolving data quality issues

4. Staging data and files from the production Vault in a sandbox Vault

5. Performing dry runs for loading and verification of data and files in a sandbox Vault

6. Performing a validation run for loading and verification of data and files in a sandbox Vault

7. Loading and verifying data and files in a production Vault

</Steps>
The complexity, effort, and timing of these steps vary depending on the data volume, data complexity, system availability requirements, and tools. Choosing the correct approach is the key to a successful migration project.

<Aside>It is critical that you select an approach that is appropriate for the size and complexity of your migration project. Migrations can be performed by customers or with assistance from Veeva Migration Services and [Certified Migration Partners](https://www.veeva.com/meet-veeva/partners/migration/) who use validated tools and have experience performing Vault migrations. We recommend speaking with your Veeva account team to understand these options prior to starting your project.

</Aside>

## Planning {#planning}

The migration plan should consider dependencies between the Vault configuration and data preparation and provide adequate time for testing and validation. It is important that you conduct performance testing to properly estimate the time it will take to complete migration activities.

<Aside type="caution">Before carrying out a migration, it is necessary to inform Veeva at least three business days in advance or at least one week for large migrations by completing the [Vault Migration Planning Form](https://forms.gle/RPKBidGc4SHCX2tC6). This notifies Veeva technical operations and support teams of your migration project and allows them to prepare. Fill out this form for any migration that includes over 10,000 documents, 1,000 large (greater than 1 GB) documents (like videos), 500,000 object records, or any migration where the customer or services has concerns. Complete the form for each environment you will be migrating into.

</Aside>

### API Threading {#api-threading}

Migrations using multiple threads are not supported, and we strongly recommend factoring this into project timelines, including the execution time for migration runs. While we support multi-threading on file staging downloads, the following restrictions apply when executing API calls during a migration:

* The document API endpoints support a maximum of one thread.

* The object API endpoints support a maximum of two threads.



---

**Next:** [Guides](/medical/migrations/guides)