Migrating operational data PROD A→PROD B without clone. what is the best method?

[Puneet Hegde1]

Context:
We’re consolidating two production instances (servicenow Instance A → ServiceNow Instance B). A clone is not possible due to tenant isolation and timing constraints. We only need to move operational data (not configuration) and keep the destination’s existing configuration intact.

Goal:
Migrate the following from A (prod) to B (prod) while preserving relationships and history where feasible:

• incident, change_request, sn_customerservice_case, sc_request, sc_req_item, 

• Related/child data: sys_journal_field (work notes/comments), attachments (sys_attachment + sys_attachment_doc),  streams, and key related lists.

Constraints / Requirements

• No outage window long enough for a full export/import freeze; may need an incremental cutover.

• Preserve sys_ids where possible so references stay intact.

• Prefer to retain timestamps (sys_created_on, sys_updated_on) and authors if supported.

• Volumes are mid-to-high (hundreds of thousands of tasks + journal entries).

• Destination does not contain live data.

• This is a one-time transformation as we are migrating from instance A to instance B

Question:
Given these constraints, what is the best and most reliable method to migrate this operational data between two production instances while maintaining data integrity, relationships, and history?

Additionally, are there any ServiceNow-recommended best practices or documented runbooks for performing this type of production-to-production operational data migration?


Thank you,
Puneet

[Puneet Hegde1]

HI Bhuvan,
i have checked out IDR, and as this is one time transformation as we are migrating instance a to instance B. Is there any other way?

Thank you,
Puneet

[Bhuvan]

@Puneet Hegde1 

Sorry, missed to read between the lines as IDR would not be the right approach for one time migration.

You can use below methods for one time migration of data & configuration based on your preferences

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1523057

https://www.servicenow.com/docs/bundle/zurich-integrate-applications/page/administer/import-sets/ref...

If this helped to answer your query, please mark it helpful & accept the solution.

Thanks,

Bhuvan

[Ankur Bawiskar]

@Puneet Hegde1 

IDR can be used but it's paid plugin.

It can be used for 1 time migration or it can sync continuously data between those 2 instances

OR

If you don't want to use Paid Plugin then you will require a custom integration to be done between those 2 instances.
you can setup bi-directional integration between the tables

ServiceNow to ServiceNow Integration using REST API and PUSH and PUT methods with Business Rule 

You can also explore on Ebonding Spoke with less scripting

ServiceNow eBonding spoke 

Refer the below link which has the approach with example shared by me.

Integration hub ebonding spoke 

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

[Ankur Bawiskar]

@Puneet Hegde1 

Thank you for marking my response as helpful.

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

[Anand2799]

Hi @Puneet Hegde1 ,

If you need to migrate data from one instance to another, consider the following approaches:

• Instance Data Replication (IDR): This option is not practical for a one-time migration.
• Import/Export XML Files: A straightforward method for smaller datasets.
• Custom Integration Between Instances: This approach is highly flexible but can be complex and time-consuming.

I successfully migrated approximately 400k records and 500k attachments for a customer by building a custom integration between both instances.

Key Considerations:

1. Effort & Testing: Extensive planning and testing are required before moving data into production.
2. Integration Hub Usage: The process consumes a significant number of integration hub transactions—monitor usage carefully.
3. Multiple Actions: You may need separate actions for each table to import/export data.
4. Referenced: If your users data does not have same sys_ids in another instance than you need to map it to correct user to preserver the relationship.
5. Attachments Handling: Use the Attachment API to process attachments one at a time.
6. Comments & Work Notes: To preserve details like author and timestamp, additional scripting is needed to create journal entries and audit data.
7. Duration: Data transfer is a continuous process and can take hours or even days depending on record volume and attachment size. In my case, it took 4–5 days to complete the migration.

Thanks

Anand