ITOM Development and Deployment Process – MID Server, Discovery & Service Mapping

[corelabspac]

Hi everyone,

I’m currently learning ServiceNow Discovery and other ITOM products, and I’m trying to understand how ITOM development and deployment are typically handled in real-world projects.

I understand that a MID Server needs to communicate with the infrastructure it is discovering, and this made me wonder how the development and testing process works across environments.

For example:

- Is the MID Server normally connected directly to the Production ServiceNow instance?

- If we are developing and testing Discovery, Service Mapping, or other ITOM functionality, do organizations have separate development/test infrastructure for this?

- How is the MID Server setup handled across DEV, TEST/UAT, and PROD instances?

- Are Discovery schedules, credentials, patterns, probes, sensors, Service Mapping configurations, etc. developed and tested in a non-production environment and then promoted to Production?

- If Discovery needs to actually communicate with servers/network devices to validate the configuration, what does the typical test infrastructure look like?

- How are MID Server configurations and infrastructure credentials managed during this process?

I’m particularly interested in understanding the end-to-end ITOM development → testing → deployment process, rather than just how to configure Discovery technically.

If anyone has experience implementing ITOM in a real enterprise environment, I’d really appreciate an explanation of the typical architecture and workflow.

Thanks in advance!

[chrisjones2]

We have a separate VM running MID server for each environment, I'm sure I saw this was recommended in discovery guidance.

When implementing discovery (via ACC and network discovery) our approach was:

• Build a specific test server as initial discovery target
• Configure discovery from ServiceNow Dev environment targeting only the specific test server
• Review gathered data, refine as required (pattern updates etc.)
• Expand discovery targets to a wider pool of non-prod servers, ensuring a representative spread of different OSs / hosting environments / applications / network segments
• Review gathered data, refine as required (pattern updates etc.)
• Replicate discovery config from Dev to Test
• Validate that results are same as in Dev environment
• Replicate discovery config from Test to Prod, expanding to cover all servers

Hope this helps!