
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2020 06:05 AM
Good Morning,
My team has been challenged with a very limited time frame (3 weeks) to move incident, change and request data out of a production instance and to merge that data with out own. We have concerns with maintaining record relationships and data integrity, for audit purposes especially for request variables, journal entry.
We are also concerned with avoiding issues in regards to numbering schema and sys_id.
We have considered the following options:
- Starting the users fresh in our Instance, backing up the existing data to a MSSQL server
- Importing each record and re-numbering
- This is where we have the biggest concerns in regards to maintaining relationships
- Utilizing the Archive module to flatten the data and import to a fresh table within our instance.
- Again we have some concerns in regards to how does this affect request variables, user journal etc.
Is there a good guide or suggestions or guidance anyone can give on how to best achieve this?
Solved! Go to Solution.
- Labels:
-
Best Practices

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-08-2020 06:05 AM
All,
Thank you for your responses, for now we have decided to not bring over any historical data. When the instance is decommissioned we will retrieve a MYSQL backup from SN of the instance and set that up for data retention and audit.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2020 06:11 AM
Hi,
If you don't mind, can you give us a bit more information? Is this other instance also ServiceNow? What modules are active in this instance right now? Just ITSM? Is there a reason you aren't moving Problem or Knowledge?
If so, are you able to clone the data? You can remove any preservation or exclusion tables and pretty much do a full clone.
Or are you not wanting to really carry that data down as this was the problem in the first place?
This sounds roughly like a classic scenario where: instance A was in existence, but wasn't operating "well"...and then it was "acquired" but you already had another SN contract and so you're wanting to bring "some" of the data over, but not all of it.
Something like that? lol
Please mark reply as Helpful/Correct, if applicable. Thanks!
Please consider marking my reply as Helpful and/or Accept Solution, if applicable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2020 06:23 AM
Hi Allen,
This is due to an acquisition, the other team has an instance that is not as developed as our own and are currently working to move their processes in to our system.
ITSM and ITOM with discovery are the 2 main modules they have, Discovery however we are implementing from scratch as they have some setup problems their side.
Knowledge we don't have to worry about as at this time they utilize an external knowledge base and will work to migrate that at a later date.
Problem is one of the other areas we need to bring across, I missed that.
We understand there will be some issues due to users and assignment groups being imported from LDAP meaning they have different sys_ids.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2020 06:48 AM
I would suggest you to follow data import process suggested by ServiceNow on Developer Site
You need to create transform map for your target instance. Everything is explained on sections starting from " Data Import Process " section

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-02-2020 11:27 PM
Hi Simon,
I did read your question as a task to merge two servicenow instances - correct?
If you talk about INC, PRB and CHG
... how about the related information contained within? Like Attachments, CI Records, Change Task, etc? Will you require all these?
... how about configurations contained? Like categories, resolution codes, state values, etc. Will you merge these values first?
There is a whole bunch of topics to go through prior moving data.
What are the main use cases after the merge? Is the data required purely for reporting / history or will you also need to move active - still in progress - records? If only history, I would vote to move the data to a form of an archive. Removes the burden to merge configurations.
Daniel