# Record Migration Mode Record Migration Mode allows you to migrate large numbers of object records by only enforcing minimal constraints such as data type and length. You can create records in any lifecycle state and manually set standard and system-managed fields such as _Name_, _ID_, or _Created By_. You can apply Record Migration Mode when creating or updating object records using the Vault API, Vault Loader, the Vault Loader Command Line Tool, configuration migration packages, and test data packages. You must have the _Record Migration_ permission to apply migration mode using these options.
When Record Migration Mode is enabled, Vault allows you to set or edit values for fields that are normally not editable when creating and updating records. However, you cannot set formula fields with Record Migration Mode. | Item | Requirements | | --- | --- | | Standard and custom fields | Must be a valid data type and length. Any other type of validation is bypassed.

Record Migration Mode applies default values to omitted fields. To make a field value blank, include the field but leave the value empty. | | ID | Supported in _Create_ actions only.

Must be a unique sequence of 15 uppercase alphanumeric characters, where the first three characters are the object prefix in the target Vault and the fourth character is 'Z' to prevent conflicts with Vault-generated IDs.

For example, `00PZA1B2C3D4E5F`. | | Global ID | Must be valid and in the format `{vault id}_{record id}.` | | _Created By_ (`created_by__v`)
_Modified By_ (`modified_by__v`)
_Created Date_ (`created_date__v`)
_Modified Date_ (`modified_date__v`) |If you include either _Created By_ or _Modified By_, you must include both.

If you include either the _Created Date_ or the _Modified Date_, you must include both, and neither date can be in the future. The _Created Date_ must be earlier than or equal to the _Modified Date_.

If omitted, _Created By_ and _Modified By_ default to the currently authenticated user, and _Created Date_ and _Modified Date_ default to `Now()`. | | Picklist values | Must exist but can be inactive. | | Object type fields | Fields must exist on the Object Type. | | Object references | Must exist but can point to inactive records. | | Lifecycle, lifecycle state, and lifecycle stages | Must exist but can be inactive. If omitted, Record Migration Mode applies default values. The default value for a lifecycle state is its initial state.

If you include any lifecycle stage fields, you must include all lifecycle stage fields.

Status changes on a parent record, such as changing _Active_ to _Inactive_, do not cascade to its children. Ensure status changes are updated on both the parent and child record. | | Lookup fields | Must be the correct data type.

You must include the related record ID. For standard volume objects, if a Lookup field value does not match the source record, Record Migration Mode does not overwrite the field value until the related record ID is updated. Raw objects always overwrite the field value with the correct lookup value. | | Roll-up fields | Must be the correct data type.

If a Roll-up field value does not match the specified child records, Record Migration Mode does not overwrite the field value until the child records are updated. | ## Considerations with System-Managed Record Names Use the following considerations when using Record Migration Mode with system-managed object record names. ### Migrating to New Objects When migrating records using Record Migration Mode, we recommend clearing the _System manages field value (read-only)_ setting during migration if you do not want Vault to generate the _Name_ of the migrated records. Once migration is done, you can enable this setting again and set the appropriate _Starting Number_. If it's not possible to clear _System manages field value (read-only)_, we recommend leaving the _Starting Number_ unchanged until the migration is completed. ### Migrating to Existing Objects with Records Be aware that even if you provide your own _Name_ using Record Migration Mode, the auto-generated number in system-managed record names increments with each new migrated record. For example: * The _Product_ object's _Name_ field is system managed with a _Value Format_ of _VV-{######}_ and a _Starting Number_ of _1_. * Record Migration Mode is used to create a _Product_ record with the _Name VV-000002_. * Another _Product_ record is created without Record Migration Mode. In this case, Vault fails to create the second record since the first record incremented the _Starting Number_ from _1_ to _2_. Therefore, _VV-000002_ is the next _Name_ in the sequence and is already in use by the previous record created in Record Migration Mode. If the record creation is retried, the next system-managed _Name_ generated is _VV-000003_. This behavior occurs since failed record creation attempts increment the auto-generated number. To avoid this issue, create all necessary records in Record Migration Mode. Then, update the _Starting Number_ to a number greater than the number used to create the record in Record Migration Mode. Using the example above, updating the _Starting Number_ to _3_ after _VV-000002_ is created prevents the _Name_ conflict and ensures the next record created uses _VV-000003_ as the _Name_. ## How to Use Record Migration Mode You must have the _Record Migration_ permission to apply migration mode using these options.
### Create Object Records API Use the Vault API's Create Object Records and set the `X-VaultAPI-MigrationMode` header to `true`, which applies Record Migration Mode to any object record created or updated in that request. Set the `X-VaultAPI-NoTriggers` header to `true` to bypass triggers when Record Migration Mode is enabled. Before using this parameter, learn more about [bypassing triggers][1]. ### Vault Loader API Use the Vault API's Load Data Objects endpoint and set the `recordmigrationmode` parameter to `true`. To also bypass record triggers, set the `notriggers` parameter to `true`. Before using this parameter, learn more about [bypassing triggers][1]. ### Vault Loader UI When creating or updating records in bulk with Vault Loader, select the **Record Migration Mode** checkbox to apply migration mode. The _No Triggers_ option allows you to bypass record triggers. Before using this parameter, learn more about [bypassing triggers][1]. ### Vault Loader CLI Use the `-recordmigrationmode` parameter in the Vault Loader Command Line tool. To also bypass record triggers, use the `-notriggers` parameter. Before using this parameter, learn more about [bypassing triggers][1]. ### Configuration Packages & Test Data Packages When editing the settings for a data object in a configuration migration package or test data package, select the **Record Migration Mode** checkbox to apply Record Migration Mode. ## Bypassing Triggers {#no-triggers} When using Record Migration Mode with Vault API, Vault Loader, or Vault Loader CLI, you can optionally configure Vault to skip all trigger execution. This includes custom Vault Java SDK triggers, Action Triggers, standard triggers, and system triggers which work to deliver various Vault functionality. Because standard and system triggers are generally expected to run, bypassing these triggers may have unexpected consequences. We do not recommend bypassing triggers on the following objects: * _User Role Setup_ (`user_role_setup__v`) * _User Role_ (`user_role__sys`) * _User Task_ (`user_task__v`) * Objects assigned the _User Task_ object class As a best practice, always run your record migration in a sandbox Vault and test for expected functionality before running in production. ## Considerations with System-Managed Names If Record Migration Mode is used to create a record on an object with a system-managed name, you may encounter an error creating additional records without Record Migration Mode. For example, let's say _Product_ object's _Name_ field is system managed with a _Value Format_ of _VV-{######}_ and a _Starting Number_ of _1_. Let's say Record Migration Mode is used to create a _Product_ record with the _Name VV-000002_. Then, another _Product_ record is created without Record Migration Mode. In this case, Vault prevents the record creation since a record was created and the autonumber has incremented from a _Starting Number_ of _1_ to _2_. Therefore, _VV-000002_ is the next _Name_ in the sequence and is already in use by the previous record created in Record Migration Mode. If the record creation is retried, the next system-managed _Name_ generated is _VV-000003_. This behavior occurs since failed record creation attempts increment the auto-generated number. To avoid this issue, update the _Starting Number_ to a number larger than the number used to create the record in Record Migration Mode. Using the example above, updating the _Starting Number_ to _3_ after _VV-000002_ is created prevents the _Name_ conflict and ensures the next record created uses _VV-000003_ as the _Name_. [1]: #no-triggers