Migrating operational data PROD A→PROD B without clone. what is the best method?
						
					
					
				
			
		
	
			
	
	
	
	
	
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
If this helped to answer your query, please mark it helpful & accept the solution.
Thanks,
Bhuvan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Did you get a chance to review this as I believe the information provided should answer your question.
If my response helped to guide you or answer your query, please accept the solution.
Thanks,
Bhuvan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Bhuvan,
We are currently figuring out the steps and prerequisites of data migration. I have kept it in my notes, and I will update the post once our data migration is completed.
Thank you,
Puneet
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
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
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
