Best Practice use of Key Mappings

This article relates to Service Now instance migrations.

For ServiceNow to ServiceNow migrations always use the Import Set (Scripted) migration method with Migrate Sys-Ids and set the Key Mapping Option to No Key Mappings. Then the Sys-Id will be preserved during migration and can be used as a reliable target record identifier for future updates.

For instance migration, where sys_id's on source and target match (or are required to match after migration) best practice is to:

• explicitly map the sys_id field (using a simple mapping)
• explicitly set the import set (scripted) migration method in the form mapping options.
• For Service Now targets, it is not nessecary to explicitly define the key mapping. If the sys_id is mapped, PB will implicitly use this to correlate source and target records.

If sys_id's do not match, or when migration from a legacy server into Service Now, use the Selected Key Mappings option if any set of mappings can be found in the source/target records where:

1. Values are consistent (for all migrated records) on the source and target server
2. Values represent a unique entry on the target server
3. Values do not (generally) change over time on the source or target server

For target fields used in key mappings, at least one of the fields should be indexed when there are more than 10,000 records in the table in order to improve performance and reduce the risk of timeout errors.

If no suitable key mapping field can be found, one solution is to add a custom field to the target server and map the source record identifier to this field, using this mapping as the selected key mapping. Some tables in Service Now already have a correlation_id field that can be used for this purpose.