1. Boiling the ocean on day one
The most common mistake is pointing Discovery at every subnet in the estate and hitting go. It feels efficient. It produces a flood of half-populated CIs, credential failures you cannot triage, and a data set so noisy that nobody can tell signal from garbage — and then the project stalls while someone tries to clean up tens of thousands of rows by hand.
Scope Discovery the way you would scope any delivery: in slices you can verify. Start with one well-understood datacenter segment or one application’s infrastructure, prove the credentials and MID Server reach work end to end, confirm the CIs land in the right classes, and only then widen the net. A narrow, correct first pass earns more trust than a broad, messy one — and it gives you a working pattern to repeat.
2. No credential and service-account strategy
Discovery is only as complete as the doors it can open. Miss the SSH key for a Linux fleet, the WMI rights on Windows, or the SNMP community string on the network gear, and those CIs come back as shells — an IP address and not much else. Worse, teams often find the credential gaps one failed probe at a time, weeks in, after the schedule is already committed.
Treat credentials as a workstream, not an afterthought. Inventory the credential types each target class needs before you scan, get a dedicated service account provisioned with least-privilege rights, and keep secrets in the credential vault rather than scattered across the platform. Run a credential-affinity test on a sample of each OS and device type early, so you find the gaps while there is still time to fix them.
3. Ignoring MID Server placement and network reach
The MID Server is where Discovery physically touches your environment, and it can only see what the network lets it see. Drop a single MID Server in one segment and expect it to reach every firewalled zone, and you get a CMDB that is confidently complete about the fraction it can reach and silent about the rest. The gaps do not announce themselves — the map just looks a little thin.
Map MID Server placement to your network topology, not to convenience. Every isolated segment, DMZ, and cloud VPC needs a MID Server that can actually route to its targets on the required ports. Size and cluster them for the scan load, plan the firewall rules as part of the project, and validate reachability before you schedule production scans rather than discovering a blind spot in a post-incident review.
4. Letting duplicate CIs breed
Nothing erodes confidence in a CMDB faster than three records for the same server. Duplicates come from a weak identification and reconciliation strategy — when Discovery, an import, and a cloud integration each create their own CI because none of them agree on what makes a host unique. On modern ServiceNow this is the job of the Identification and Reconciliation Engine (IRE); leave it at defaults while feeding in multiple sources and duplicates are not a risk, they are a guarantee.
Decide your identifier strategy deliberately: which attributes uniquely identify each CI class, and which source is authoritative for which fields. Configure IRE identification and reconciliation rules to match, so a re-scan updates the existing CI instead of spawning a new one and a lower-priority source cannot overwrite better data. Then watch the CMDB Health duplicate dashboards — catching duplication early is far cheaper than a de-dup project later.
5. Discovering infrastructure but never mapping services
Plenty of implementations get horizontal Discovery working — servers, databases, network devices — and stop there. The result is a warehouse of components with no story. When an incident hits the payment service, nobody can answer “what does this actually run on?” because the infrastructure was discovered but never connected to the business services that depend on it.
The value of a CMDB lives in the relationships, not the row count. Plan for Service Mapping — or at least well-maintained application services and dependency relationships — as a first-class part of the effort, and anchor the model to the Common Service Data Model (CSDM) so classes, services, and relationships line up with ServiceNow’s intended structure. Infrastructure tells you what you have; the service layer tells you what it is for, and that is what change and incident teams actually use.
6. Treating Discovery as a project instead of an operating process
Discovery gets funded as a project, delivered as a project, and then abandoned like one. The scans that ran beautifully at go-live drift out of schedule, credentials expire, new subnets appear that nobody added, and eighteen months later the CMDB is a snapshot of a datacenter that no longer exists. Data decays every single day, and a CMDB with no owner decays fastest.
Stand up the operational muscle before you call it done: named CMDB data ownership, scheduled scans with monitored completion, alerting when a scan fails or coverage drops, and a regular data-certification cadence so owners confirm what Discovery cannot infer. CMDB Health dashboards for completeness, correctness, and staleness turn “is it still good?” from a hopeful assumption into a number you check. Discovery is not a milestone you pass; it is a system you run.
7. Skipping the data-model and governance groundwork
Under schedule pressure, the CMDB class model and governance rules are the first things to get waved through — and the most expensive to fix later. CIs land in the wrong classes, custom attributes multiply, relationship types are used inconsistently, and there is no gate on who can create CIs or change the model. By the time the mess is visible, it is woven through thousands of records and dozens of integrations.
Do the unglamorous groundwork up front. Agree the class structure and align it to CSDM, define which relationship types you will use and what they mean, and put governance around CI creation, model changes, and integration onboarding so every new data source has to earn its place. Governance feels like overhead on day one and looks like foresight on day one hundred — it is the difference between a CMDB that scales and one you quietly rebuild in two years.