Moving to ServiceNow Discovery: Migration Considerations

Switching from an existing discovery tool to ServiceNow Discovery depends mostly on the inventory, the record matching and the overlap period, not on the data load itself. This page helps a team decide what to document about its current tool, which cutover approach fits its risk and what must be settled before the old tool is switched off.

What to Inventory From Your Current Discovery Tool

Before moving to Discovery, document what your current tool does. Catalog all discovery methods: network scanning, SNMP discovery, WMI interrogation, integration with other tools. Document discovery scope: what networks, systems, or regions are scanned? Document discovery frequency: is discovery continuous, daily, weekly, or on-demand? Identify what credentials and permissions are required for current discovery.

Catalog the data your current tool collects: hardware details, software versions, network configuration, performance metrics. Identify which attributes are most important to your organization and which you can drop. Note any custom discovery rules or filters. Document all integrations: does your current tool feed data to a CMDB, ticketing system, or other platform? These integrations will need to be reworked with Discovery.

Also document the users and use cases. Who runs discovery? Who consumes the data? What decisions or actions do they take based on discovery results? This user and use-case map shapes how you configure Discovery and what validation criteria matter.

Data and Process Mapping

Map attributes from your current tool to Discovery’s data model. ServiceNow Discovery stores hardware, software, network, and service data. Not every attribute from your current tool will map directly. Identify which attributes are critical for your use cases and which can be dropped. This reduces migration complexity.

For discovery methods, identify which ServiceNow Discovery patterns match your current methods. ServiceNow Discovery supports network scanning, SNMP, WMI, SSH, integration with cloud platforms, and custom adapters. Map each of your current methods to Discovery capabilities. If a method does not have a direct equivalent, explore whether the outcome is achievable a different way or whether the method is truly needed.

Document integration changes. If your current tool feeds a CMDB, plan how Discovery will feed ServiceNow CMDB. If other systems consume data from your current tool, plan how they will access Discovery data instead. Integration changes often take longer than discovery configuration.

Cutover Options and Risks

A parallel cutover runs your current discovery tool and ServiceNow Discovery simultaneously, comparing results. This is safe but requires running two discovery systems and reconciling differences. Choose this if you have high-volume data or complex dependencies on discovery accuracy.

A phased cutover starts Discovery on a subset of your infrastructure (maybe one data center or business unit), validates results, then gradually expands scope. This lets you tune discovery and fix issues before full migration. The risk is that partial data in Discovery creates incomplete visibility until cutover is complete.

A direct cutover switches entirely at a scheduled date. This is fastest but riskiest. If discovery misconfiguration occurs, you lose visibility into your infrastructure. Mitigation requires thorough validation before cutover and a clear rollback plan if needed.

Risks include that Discovery misses assets your current tool finds (leaving blind spots), that integration to downstream systems fails (blocking dependent processes), or that discovery tuning takes longer than expected (delaying full cutover).

Testing and Validation Steps

Before cutover, run Discovery on a sample infrastructure with known configuration. Compare results to your current tool. Look for discrepancies: assets Discovery found that current tool missed, assets current tool found that Discovery missed, attribute differences. Investigate and tune discovery rules until discrepancy rates are acceptable.

Test integrations. If downstream systems consume discovery data, verify they work correctly with Discovery data. Test data freshness: is Discovery discovering new assets quickly enough? Is stale data being cleaned up?

Test performance. Run full scans at expected frequency and volume. Verify that discovery does not overload your network or the ServiceNow instance. If you have high-volume infrastructure, capacity planning is important.

Validation Steps Before Cutover

Run discovery on increasing scope before full cutover. Start with a single data center or business unit. Validate accuracy, review with asset owners, and get their sign-off. Then expand to more scope. This graduated approach lets you catch configuration issues early.

Validate that integrations work end-to-end. If downstream systems depend on discovery data, validate they receive data correctly and can process it. A broken integration means downstream systems fail even if Discovery works fine.

Document what you learned about your infrastructure during discovery. Discovery often reveals assets nobody knew existed, network topology that is different from expectation, or software that is not licensed correctly. Use this information to inform cutover and post-cutover improvements.

Post-Migration Responsibilities

After cutover, monitor discovery completeness and accuracy. Set up monitoring to alert if discovery stops finding assets or if discovery scan times degrade. Establish procedures for validating discovery accuracy periodically. Some organizations do annual validation with asset owners; others build validation into incident response (if an incident affects an asset, validate that asset details in Discovery are current).

The hard part is matching records, not moving them

Teams planning a move from another discovery tool tend to focus on how the old data gets loaded. The harder work starts when both tools have seen the same server and describe it differently. One names it by host name, the other by serial number. One records a virtual machine as a separate item, the other folds it into its host. If the two records are not matched by an agreed identity rule before cutover, the new platform will show duplicates, the old platform will show records that the business still relies on, and reports built on either will disagree. Settle the identity rule first, then migrate. Doing it the other way round means the rule gets written around the data that happened to load.

The identity rule should name the attributes used for matching, the order in which they are tried, and what happens when none of them agree. For many estates the answer is a combination: a stable hardware identifier where one exists, a host name where it does not, and a manual review queue for the rest. Keep the queue visible. It is the measure of how much of the estate the rule cannot yet explain.

Reconciling the two sources during the overlap

Where both tools run for a period, the overlap is where most of the risk sits. Two practices make it manageable. First, compare the record sets on a schedule, not as a one-off. A weekly comparison of counts by class and by site will show drift early, and it gives the team a chance to decide which tool is authoritative for each class before the cutover date arrives. Second, record every decision to accept a difference. A difference that is accepted without a note will be questioned again during the audit that follows.

1. Agree the identity rule and the authoritative source for each device class.
2. Load a representative sample into the new platform and match it against the old records by the agreed rule.
3. Review the unmatched sample and classify each case as a rule gap, a stale record or a true missing item.
4. Adjust the rule once, then run the full comparison and record the results by class and site.
5. Repeat the comparison on the schedule agreed until cutover, and hold the cutover decision until the unmatched count is explained.

Retiring the old tool without losing history

Switching off the old discovery tool is not the same as deleting its data. Historical records are often needed for audits, for incident reviews that cover the period before cutover, and for trend reports that the business has already built. Decide what history must be kept, in what form, and for how long, before the old tool is shut down. An export to a read-only store is usually more reliable than leaving the old tool running in a degraded state, because a degraded tool keeps generating expectations that nobody maintains.

Dependencies people forget

Ask who receives exports from the old tool. A finance team that imports a monthly asset list, a security scanner that reads a host file, or a change board pack built from a spreadsheet may all depend on the old tool without appearing in any architecture document. The safest method is to watch the old tool’s outbound activity for a period before cutover and to ask the owners of each destination to confirm what they consume. An export that nobody reads can be dropped. An export that someone reads every month needs an owner in the new design.

Questions about moving discovery between tools

Should the team migrate history or only current records?

Current records are the working set. History is usually better kept in the archive described above than loaded into the new platform, where it can distort counts and trend views. Load history only where a named consumer needs it in the new tool.

Can the old and new tools run against the same targets?

Yes, for the overlap, but check the load. Two tools scanning the same segments on the same schedule can cause performance problems on targets and in the network, and can produce the appearance of duplicates that is really just double collection.

What is a reasonable sign that cutover can happen?

The unmatched count is explained, every destination has confirmed what it consumes, and the rollback path has been tested. None of these is a number to hit. Each is a condition that the approver can check.

Plan the move with a migration specialist

If you are replacing an existing discovery tool, the identity rule, the overlap and the dependencies are the three things to agree before anything is switched off. The migration services page describes what the service covers. The note on migration reconciliation controls covers the comparison method in more detail, and the note on validation before cutover is useful for the approval step. The Discovery integration patterns page covers the patterns Discovery uses for inbound data.