Guidance Required on Exporting ServiceNow Data with Attachments While Preserving Record Relationship

RoniwilliamC
Tera Contributor

Hello Team,

I have a requirement to temporarily export all data from ServiceNow (for example, Incident and related tables) along with their associated attachments, store it externally, and then re-import it when needed.

Could you please advise on the recommended approach and step-by-step method to achieve this using ServiceNow capabilities such as Export Sets, REST APIs, or other out-of-the-box tools?

Specifically, I would like to understand how to export both records and their attachments efficiently, ensure that the relationship between each record and its attachments (using fields like sys_id and table_sys_id) is preserved and not broken, handle large attachment volumes in a scalable way, and store the data in a suitable format so that it can be re-imported without any data or linkage issues.

Any guidance or best practices would be greatly appreciated.

Thank you.

1 REPLY 1

Naveen20
ServiceNow Employee
XML export is the OOB format that retains sys_ids. Attachments live in two tables — both are required.
Steps (small/medium volumes)

 

Records: From the list (e.g., incident.list), right-click header → Export → XML.
Attachment metadata: Open sys_attachment.list, filter table_name=incident → Export XML. The table_name + table_sys_id fields carry the linkage.
Attachment binary: Export sys_attachment_doc (holds Base64 chunks). Both tables are needed — exporting only sys_attachment produces a corrupt file on download.
Re-import: System Definition → Load Data, in order: target table → sys_attachment → sys_attachment_doc.

 

For large volumes, XML export hits practical size limits. Use the REST Attachment API (/api/now/attachment) to stream binaries to external storage, and the Table API (/api/now/table/{table}) for records — store sys_id, table_name, and table_sys_id alongside each file so linkage can be rebuilt on import (POST to /api/now/attachment/file?table_name=…&table_sys_id=…).
Caveats: reference fields (users, groups, CIs) will break if those records do not exist on the target. REST is the supported path. If both endpoints are ServiceNow instances, instance clone is simpler.