Migrating records between ServiceNow instances while preserving Sys IDs & avoiding duplicate records

[ggnanasaikr]

Hi,

We have a migration requirement between two ServiceNow instances and are looking for the best approach.

Current Scenario:
Instance A (Source): Contains developed/configured data that needs to be migrated.
Instance B (Target): Already contains some of the same records/data.
Requirement:
1) We want to migrate records from Instance A to Instance B while

2) Preserving the same Sys IDs from Instance A in Instance B.
3) Avoiding the creation of duplicate records in Instance B.
4) Updating existing records in Instance B if the same record already exists.

Approaches Tried:
1. Import Set + Transform Maps (Excel Import)

Imported data from Instance A into Instance B using Transform Maps.
Records were migrated successfully.
However, new Sys IDs were generated in Instance B, which does not meet our requirement.
2. XML Export/Import

Exported records from Instance A as XML and imported them into Instance B.
This preserved the original Sys IDs.
However, since some records already exist in Instance B, the import creates duplicate records instead of updating existing ones.

Questions
1) What is the recommended approach for migrating data between ServiceNow instances while preserving Sys IDs?
2) Is there a way to make XML imports update existing records instead of creating duplicates?
3) Has anyone handled a similar scenario where the target instance already contained partial data?
Any guidance or best practices would be greatly appreciated.

Thanks!

[Ankur Bawiskar]

@ggnanasaikr 

the important question is what you want to migrate?

Core data such as User, Group, Group Membership, Location, Company etc usually come from AD and 1 time data load

[Tanushree Maiti]

Hi @ggnanasaikr 

Points 2 and 3 appear to contradict the recommended approach.

First and foremost, it is generally not recommended to bring the same sys_id values from one ServiceNow instance into another instance. There is a high risk that existing records may become redundant or conflict with records already present in the target instance, which can potentially impact system stability.

A safer migration approach would be to avoid manually carrying over sys_id values unless there is a specific and well-justified requirement. Instead, use proper migration practices that allow ServiceNow to manage record relationships and identifiers appropriately.

Migration considerations:

• Use Correlation ID & Correlation Name: Populate these fields during migration to store the source instance (from where you will bring data) record identifier and related details. This provides a reliable way to track records across instances without overwriting or forcing sys_id values.

• Export Data via XML:  Exporting records using the List view’s right-click Export > XML option preserves the original 32-character sys_id. However, importing these records with the same sys_id into another instance should only be done after carefully validating that there are no existing records with conflicting identifiers.
• Use Coalesce in Transform Maps: When using Import Sets, configure the Transform Map with appropriate coalesce fields. While coalescing on sys_id can update matching records instead of creating duplicates, it should be used cautiously because relying on source-instance sys_id values across instances can introduce data integrity risks. In most cases, business keys or other unique identifiers are preferred for matching records.