Implementation of Discovery over an existing CMDB

[pauladams]

Hello Experts,

Our client has a CMDB already which is being populated from multiple sources - a homegrown external system (not discovery), manual updates and imports. The client says the current state of CMDB is very matured and a lot of data has been already populated. However, want to implement ServiceNow's Discovery to eliminate the manual and multiple sources feeding the CMDB.

I would like to what is the best approach for implementing the Discovery, in the following context:

1) The customer has already got a matured CMDB with lot of data in it. Should we stand up another instance run Discovery on it and then migrate the data to their production instance?

2) How about standing up a new instance, clone their current prod. instance (or just CMDB) on to the new instance then run Discovery?

Please share your experience and best practices of implementing Discovery over an existing CMDB.

Thanks

-Pa

[DaveHertel]

Hello Pa -

 They key issue with your scenario is avoiding duplicates -- existing CMDB/CI data being combined with a new implementation of Discovery... the 'success' will rely heavily on how well the existing CI data attributes match with the reconciliation engine/rules.  If the manual/imported/other CI data matches what Discovery finds, you'll avoid duplicates.  Unfortunately, it's unlikely that data brought in from other sources (without regard for Discovery/reconciliation) will avoid the likelihood of CI dups.  

I'd look at some sample attributes of existing CI's (serial #, mac address, etc..) and cross-reference this against a test instance, running Disco against the same machines and attributes.  Is the data the same?  Is there confidence that the majority of existing CI's will match?  If so, you could just add-on Discovery after some thorough testing/validation in a non-prod environment.   If there isn't a strong correlation between existing CI's vs. what Discovery will automatically find & import, your customer will be faced with a decision:  What do you want to do about inevitable CI duplicates (when Disco is added to the mix...).  

Make a copy/clone of PROD to another non-prod instance, add Discovery to the non-prod instance and use this as an evaluation area to figure out how many dup-issues you might have to deal with, then make some business decisions based on those outcomes.

Does this help?  Hope so...

[pauladams]

Thank you Dave for your response.

I think running Discovery on a clone of Prod gives us an opportunity to assess what the impact will be.

Thinking a bit more, what does it look like when it comes to implementing Discovery in the Prod. instance? Do we migrate the data from a non-prod instance (after Discovery has been implemented, tested) before turn-on the discovery on the Prod. instance?

[DaveHertel]

HI Paula -- No, generally speaking, you shouldn't be migrating data between environments.   Instead, your PROD env should be the gold standard, aka "source of truth".   After you are comfortable with Disco in a non-prod env, then create a brand new setup of MIDS, Disco, etc. in prod and run it there... letting Disco do its job naturally to populate the CMDB.

Best practice: non-prod environments should be setup very similar to Prod (for testing/validation/build of future disco capabilities).   And refresh (clone) the non-prod env's from prod on a regular basis so its truly a valid, useful replica of prod... to ensure confidence in building new capabilities in dev & testing in Test env.

Hope this helps?

[JF Muller]

I would recommend to register and browse the following resource:

https://www.servicenow.com/lpwbr/customer-panel-populate-and-maintain-your-cmdb-with-discovery.html

So be consider as well:

https://www.servicenow.com/search-results.html?q=Discovery

Regards

Jef