ITOM Discovery Pitfalls: How to Avoid Them

Preparing to roll out Discovery inside of ServiceNow's IT Operations Management suite? Most Discovery gotchas aren’t technical… they’re planning, credential, or expectation-related. If you lock down credentials, connectivity, MID configuration and scope clarity, your rollout avoids 80% of common pitfalls.

Credentials Management

Discovery success lives or dies on credential coverage.

The Gotcha: Teams underestimate how hard it is to gather, validate, and maintain credentials across a diverse environment (Windows, Linux, databases, network devices, cloud APIs).

The Impact: Incomplete discovery, orphaned devices, and inconsistent CMDB population.

Avoid it:

• Build a credential inventory early.
• Involve security teams for vault integration.
• Test credentials with the Credential Affinity tool.

Firewall & Network Segmentation

Even with correct credentials, blocked ports, proxies, or network ACLs can silently break Discovery.

The Gotcha: Teams assume Discovery will “just work” without proper firewall rule reviews.

The Impact: Unreachable hosts, missed subnets, and wasted troubleshooting cycles.

Avoid it:

• Map required ports/protocols before rollout.
• Run test probes from MID Servers to critical subnets.
• Document exceptions with network/security teams.

MID Server Setup

MID Servers do all the heavy lifting so we need to make sure that scaling, bandwidth, and placement are appropriate.

The Gotcha: No consideration for load, placement, and redundancy.

The Impact: Slow or incomplete discovery, queue bottlenecks, unreachable hosts, stale configuration items.

Avoid it:

• Right-size MID Server CPU/memory.
• Distribute load across multiple MIDs by function or region for bandwidth and redundancy consideration.
• Host architecture session(s) to determine placement and quantity needed

Discovery Scope & Expectations

Many customers expect “Discovery will find everything” out of the box.

The Gotcha: Not aligning scope (what’s in-network, what’s discoverable, what’s in cloud APIs, what’s out of scope) and not managing stakeholder expectations.

The Impact: Frustration when unsupported devices/apps aren’t discovered, or when the business wants app/service maps without proper configuration or integrations.

Avoid it:

• Define what’s in scope (on-prem, cloud, network devices, etc.).
• Share Discovery’s supported technologies list.
• Phase rollout—start with high-value, high-coverage areas… consider the 80/20 rule.

Lack of Stakeholder Ownership & Process Alignment

Discovery isn’t just a technical exercise—it feeds ITSM, ITOM, Security, and Asset processes.

The Gotcha: Nobody owns the CMDB data lifecycle, so updates from Discovery conflict with manual updates, or there’s no process for handling new/retired CIs.

The Impact: Even if Discovery is technically successful, the CMDB quickly becomes stale, inconsistent, or mistrusted by downstream processes.

Avoid it:

• Assign data owners for CI classes.
• Align Discovery updates with ITSM, ITAM, and SecOps processes.
• Establish CI review/attestation routines.

Discovery success is 80% planning, 20% execution. Nail down credentials, connectivity, MID server configuration, scope, and ownership… Discovery becomes a reliable foundation for ITOM, ITAM, and beyond.