Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

How to migrate Journal Entries (Work Notes / Comments) from one record to another during data migrat

Puneet Hegde1
Tera Guru

Hi all,

We are currently performing an operational data migration between two ServiceNow instances, and cloning is not an option due to environment restrictions.

As part of this activity, we need to transfer journal entries (work notes and additional comments) from one record in the source instance to a new record in the target instance.

Example scenario:
Due to an earlier configuration issue, internal users were able to create Cases in our old instance. As part of the clean-up and migration aligned with ServiceNow best practices, we are now converting these active Cases into active Incidents in the new instance.

The issue is that while we can migrate the main record data successfully, journal fields are not being transferred — the work notes and comments from the Case do not appear in the corresponding Incident after migration.

Question:
Has anyone implemented or scripted a way to migrate journal entries between records or across instances?

Any guidance, script examples, or lessons learned would be greatly appreciated.

Thanks in advance,
Puneet

1 ACCEPTED SOLUTION

Vishal36
Mega Guru

Hi @Puneet Hegde1

Journal fields can be tough to move because they don’t behave like regular fields- they live as separate records in the background. When the main data migrates, those work notes and comments often stay behind unless they’re mapped explicitly. A few things to keep in mind:

  • Data source: Journal entries sit in the sys_journal_field table, linked to the parent record by element_id. You’ll need to extract and remap them separately.
  • Record linkage: Update the element_id in your migrated data to point to the new record in the target instance.
  • Permissions: Make sure your migration account has rights to write to work_notes and comments.
  • Testing: Run a few test records first for it’s the best way to verify the mappings before doing it at scale.

In this case, you might want to look at OpsHub Migration Manager (OMM). It supports phased or full migrations with no downtime, disruption, or data loss, and with high data fidelity including comments, work notes, attachments, and relationships. As a ServiceNow Partner, OMM is built to handle these journal and related-record migrations cleanly across instances.

Hope it helps! 🙂

 

View solution in original post

2 REPLIES 2

Abbas_5
Tera Sage
Tera Sage

Hello @Puneet Hegde1 ,

Please refer to the link below:
https://www.servicenow.com/community/developer-articles/migrate-data-from-one-instance-to-another/ta...

 

If it is helpful, please hit the thumbs-up button and accept the correct solution by referring to this solution in the future. It will be helpful to them.

 

Thanks & Regards,

Abbas Shaik

Vishal36
Mega Guru

Hi @Puneet Hegde1

Journal fields can be tough to move because they don’t behave like regular fields- they live as separate records in the background. When the main data migrates, those work notes and comments often stay behind unless they’re mapped explicitly. A few things to keep in mind:

  • Data source: Journal entries sit in the sys_journal_field table, linked to the parent record by element_id. You’ll need to extract and remap them separately.
  • Record linkage: Update the element_id in your migrated data to point to the new record in the target instance.
  • Permissions: Make sure your migration account has rights to write to work_notes and comments.
  • Testing: Run a few test records first for it’s the best way to verify the mappings before doing it at scale.

In this case, you might want to look at OpsHub Migration Manager (OMM). It supports phased or full migrations with no downtime, disruption, or data loss, and with high data fidelity including comments, work notes, attachments, and relationships. As a ServiceNow Partner, OMM is built to handle these journal and related-record migrations cleanly across instances.

Hope it helps! 🙂