Moving to ServiceNow CMDB: Migration Considerations

CMDB Scope and Current State Assessment

The Configuration Management Database (CMDB) is the authoritative record of IT infrastructure: servers, applications, databases, storage, networks, and their relationships. Before migrating to ServiceNow’s CMDB, inventory what configuration data you manage today. Is it in a spreadsheet? A legacy tool? Multiple disconnected sources (some spreadsheets, some in a monitoring tool)?

Assess data completeness and accuracy. For each server in your inventory, does the record include OS version, installed software, network configuration, and owning team? For applications, are dependencies on infrastructure documented? If data quality is poor in the source, CMDB migration will expose those problems.

Inventory and Data Mapping

Create a detailed inventory of configuration items (CIs): how many servers (physical, virtual, cloud), how many applications, how many databases, how many network devices. For each CI type, define what attributes must be recorded (name, IP address, OS version, owner, location) and where the data comes from (discovery tool, manual entry, monitoring system).

Map source data to ServiceNow CI schemas. ServiceNow has predefined CI tables such as cmdb_ci_server, cmdb_ci_appl and cmdb_ci_database.. Each source field must map to a ServiceNow field. Some source data may not have a direct equivalent; decide how to handle it: map to the closest field, create a custom field, or store in notes.

Data Cleansing and Preparation

Before migration, clean source data. Fix obvious errors: duplicate records (same server entered twice), missing required fields, incorrect relationships. Standardise naming: if servers have inconsistent naming conventions (server-01 versus server_01), choose one and normalise. Categorise CIs consistently: if some servers are marked as “Production” and others as “Prod” or “Live,” standardise to one value.

This cleansing is labour-intensive but essential. Migrating dirty data into ServiceNow just moves the problem; you still have to fix it, but then it is scattered across a larger platform. Invest in data quality before migration.

Cutover Strategy

Parallel running: for a period, maintain configuration data in both the source system and ServiceNow. This allows teams to learn the new system without committing to it. If something goes wrong, you can revert to the source system. Parallel running should last as long as teams need to validate the new system.

Big-bang cutover: on a specific date, all configuration management shifts to ServiceNow. This is faster but riskier. Use this approach when you have high confidence in data quality and team readiness, or when the source system is being retired.

Integration and Data Synchronisation

After cutover, configuration data should flow into ServiceNow from authoritative sources. Discovery automatically finds infrastructure and populates the CMDB. Monitoring systems can push configuration changes. External systems (cloud platforms, virtualization systems) can be integrated via APIs. These integrations ensure CMDB stays current without manual entry.

Identify which data flows will be automated: discovery findings (servers, applications), monitoring system changes (hostname changes, software updates), change management approvals (configuration changes are captured in the CMDB). This reduces manual data entry and keeps data fresh.

Configuration Data Ownership

Establish who owns configuration data for each CI type. The infrastructure team owns server configuration, the applications team owns application configuration, the database team owns database configuration. These owners are responsible for data accuracy and for authorising changes.

Document data governance: what changes require approval, who can modify each CI type, what audit evidence must be retained, how often data is validated? This governance prevents accidental corruption and enables audit.

Validation and Acceptance

Before production cutover, validate the migrated CMDB. Sample configurations: select 20 servers at random and verify that all attributes are correct (name, IP, OS, owner, location match reality). Check relationships: if a relationship is documented between an application and a database, is it correct? Spot-check a few services and their infrastructure dependencies.

Calculate data completeness: how many required fields have valid data? Critical CIs should have complete records. If completeness is below target, investigate: are certain CI types missing data, or is the data across all types incomplete?

Post-Migration Maintenance

After cutover, CMDB quality depends on ongoing maintenance. As infrastructure changes, the CMDB must be updated. This happens through automation (discovery, monitoring integration) and through change management (when changes are approved, the CMDB is updated). Establish review cycles: quarterly or semi-annually, sample CIs and verify they are still accurate. If accuracy is drifting, investigate the cause and improve data entry processes.

Deciding what to carry across and what to rediscover

The first migration decision is not technical. It is whether each category of data should be copied from the old store or rebuilt by discovery once the new platform is connected. Copying preserves history and any hand-entered context, such as business ownership and criticality, that discovery cannot find. Rebuilding gives you current infrastructure facts without carrying forward errors that accumulated in the old store. Many estates need both, and the split should be made category by category rather than as one global choice.

A workable rule is to copy the attributes that represent human judgment, such as owner, service mapping and criticality, and to rebuild the attributes that represent observed fact, such as operating system, installed software and network addresses. Owner records copied from a spreadsheet that has not been reviewed in a long time need a check before they are trusted, but they are still more valuable than a blank field that nobody can fill from a scan.

A mapping table that makes the gaps visible

The mapping exercise is where many surprises are found. A short table, built per source and per class, shows what will move, what will be transformed and what has no home. Build it before any data is loaded, and review the rows with the people who use the old data every day, since they will know which columns are actually consulted.

Sequencing the load so that relationships are not orphaned

Relationships depend on the items they connect, so the order of loading matters. Loading applications before the hosts they run on produces relationships that point at nothing, and some loaders can quietly drop them. A sound sequence is to load the foundational items first, confirm their identity keys have resolved, then load the items that reference them, and only then create the relationships. After each stage, count the items and the relationships against the mapping table and stop if the numbers do not reconcile. It is far cheaper to halt at the first mismatch than to untangle a loaded estate later. For the field-level detail the loader should respect, the access design is where to check which account may write which fields.

1. Load locations, owners and business services, and confirm each one exists exactly once.
2. Load hardware and platform items, then check the identity keys against the source inventory.
3. Load applications and their components, linking them to the owners loaded in the first step.
4. Create relationships in dependency order, and record every rejected row with the reason it was rejected.
5. Reconcile the counts of items and relationships against the mapping table, and clear every rejected row before the next stage.

Cutover criteria written before the date is chosen

A cutover date chosen by the calendar rather than by evidence is a common cause of failed migrations. Write the criteria first. They should cover the proportion of critical services whose relationships have been validated, the number of open rejected rows, the state of the identity keys, and whether the change and incident teams have been trained on the new view. Agree who can call a halt and what would trigger a rollback to the old store, and make sure that rollback is still possible at the point you need it, because after the old store is switched off it often is not.

Freeze changes to the old store for the cutover window, or capture them in a delta load that is replayed and checked. Teams that keep updating the old spreadsheet during the migration can end up with two sets of truth and no clear way to decide which one is right.

Is a migration the right moment to fix long-standing data problems?

Fix the ones that would stop the load or corrupt a critical relationship, and defer the rest to a remediation list with owners. The data quality rules are a practical way to decide which of those defects need to block the load. Trying to fix everything during the move can turn a technical project into an open-ended clean-up.

Should we migrate history from retired systems?

Only the history that a live decision depends on, such as the previous owner of a service that is still running. Archive the rest in its original system, with a reference from the CMDB where needed, rather than loading years of retired records that can inflate counts.

What if discovery finds far more items than the old store held?

That is useful information, not a failure. Decide which of the new items belong in scope for the services you manage, and record the rest as deliberately excluded so the difference does not reappear as an unexplained gap in the next report.

When is a fresh build better than a migration?

When the old store is small, poorly governed and not used for real decisions, rebuilding through discovery and a short interview with each service owner is faster and produces a cleaner model. The effort of migrating records nobody trusts is often larger than it looks.

Related guides: ServiceNow CMDB Testing and Acceptance Checklist.