Has anyone ever worked on any consolidation of ServiceNow instances where two companies are merging (or acquiring one another) and their processes and ServiceNow instances are very different? Any thoughts if this is even technically feasible?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2015 06:28 PM
Has anyone ever worked on any consolidation of ServiceNow instances where two companies are merging (or acquiring one another) and their processes and ServiceNow instances are very different?
Any thoughts if this is even technically feasible?
Thanks,
Marcelo Correia
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-18-2015 01:28 PM
It all depends.
Do they need to be merged? How different? What's the same? Could you just use an integration if data needs to be moved? Is it better to get the best of both processes and build a new fresh instance?
It will also depend on the types of company, development budget, time scales, politics and another 101 things.
But technically, yes, it's feasible.
Pete
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-18-2015 01:40 PM
I have done that 3 times!! Also done Remedy to ServiceNow migration. For SN to SN migration, technically its easy the tough part to harmonize the processes that support functions like service desk, change management processes etc. From technical perspective start by:
1. I am assuming that one of the two instances will be retired, so make a list of critical customization, integration, reports etc. that you want to migrate to the instance that will live
2. Come up with spread sheet templates (servicenow can generate excel template for any form) and transform maps to migrate data
3. Massage the data i.e. align it to fit the skeleton of the living instance like categorization
4. Whole CMDB can also be migrated using excel templates
5. I also did web service integration between the 2 SN instance to create and update the incident as well as requests
6. SLA targets and schedule can be imported using XML...straight forward
7. Knowledge can be imported using XML...straight forward
8. Stick to XML import where ever you can...check for sys_id conflict however they are very rare
9. Most probably service catalog items will have to be recreated
Test & test all the data loads in your test instance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-02-2015 06:40 AM
Thanks Bharat. You are correct, one of the instances should be either retired or repurposed.
Since we have an extra dev instance I'm thinking of using that extra instance as a "green field" instance and merge the two prod instances on that one. That extra dev instance would eventually become our "prod" instance but I might need to clone that over to one of our original prod instances to keep the infrastructure robustness the same (I think we will have performance impacts using a dev instance for prod purposes).
Both business units operate as Service Providers so they both use subtenancy.
One of the instances uses Domain Separation for subtenancy while the other has a subtenancy based of Business Rules, Script Includes and a dependency on Companies and Groups tied to the scripts.
Have you ever done a "merge" between an instance with Domain Separation and another without it?
Thanks again.
Marcelo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-12-2016 03:52 PM
Hi Marcelo , did you get success in the project ? How did you assess and decide what tables to migrate ? I did this in remedy once and had pretty much gone over all the tables to ensure integrity of relationships between records. Another question is about how did you export data from production to import it into your extra dev instance without creating any performance issues ?