How to migrate data records while retaining the sys_id

[bonsai]

The sys_id of user and group records will change when they are migrated using an import set such as Excel or CSV.
This has a major impact when using an update set to migrate features that have user or group reference fields in the destination, such as notification records.

I usually export records in XML format and import them into the destination instance.
This is because the sys_id will be the same when migrated in XML format.

I recently learned that migration can also be done using update sets.
This is something of a secret trick, but I think it is convenient because you can migrate in bulk.

To migrate data records while retaining the sys_id, is it better to use an update set or to export and import using XML data?

[Chaitanya ILCR · Accepted solution]

Hi @bonsai ,

exporting data as xml is the correct way to retain the sys_ids

you can also add the data to update sets with

GlideUpdateManager2 API 

there is a already well developed functionality around this

you can check the below project and import the update set and commit  in your instance

https://developer.servicenow.com/connect.do#!/share/contents/9824957_add_to_update_set_utility?v=8.7...

move data via update set is a convenience when you are working on a project and want to move the data instead of taking the xmls you could just add the data to update set and move everything at once 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Ankur Bawiskar · Accepted solution]

@bonsai 

groups should always be exported via XML

Adding Users to Group should be a manual activity in the higher instance.

Why you wish to capture them in update set?

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Chaitanya ILCR · Accepted solution]

Hi @bonsai ,

exporting data as xml is the correct way to retain the sys_ids

you can also add the data to update sets with

GlideUpdateManager2 API 

there is a already well developed functionality around this

you can check the below project and import the update set and commit  in your instance

https://developer.servicenow.com/connect.do#!/share/contents/9824957_add_to_update_set_utility?v=8.7...

move data via update set is a convenience when you are working on a project and want to move the data instead of taking the xmls you could just add the data to update set and move everything at once 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Ankur Bawiskar · Accepted solution]

@bonsai 

groups should always be exported via XML

Adding Users to Group should be a manual activity in the higher instance.

Why you wish to capture them in update set?

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Mark Manders · Accepted solution]

No. It is useful when you create a group on DEV and logic around it, but not as a rule. Use the XML which will always give you the most recent information. If you created that group and added it to your update set, and later see a typo in the name, you will have to add it again, otherwise the previous version will be migrated (including the typo). It's a manual action on every change. And that also means that if the group has users and roles, you will (again, manually) have to add the sys_user_grmember and sys_group_has_role records to the update set as well. It works if it's part of some functionality (when it's just one or a couple of records), but for data migration, use the xml.

It also isn't an OOB feature, by the way -> it's often added in implementations as a global ui action. And since there are many version out there, also check if yours is correct. I have seen ui actions adding records to update sets in the wrong scope, causing commit issues.