What to do with the CMDB when you leave ServiceNow
Every ITSM migration plan has a line item called "migrate CMDB". It is usually the line that breaks the timeline, and usually the one written with the least thought.
Why it goes wrong
Three properties of a mature CMDB, all uncomfortable:
Most of it is stale. Configuration items for servers decommissioned years ago, applications retired in a merger, environments that no longer exist. Nobody deletes CIs; there is no reward for it and a small risk in doing it.
A lot of it is duplicated. Multiple discovery sources, manual entries, imports from acquisitions. The same host appears three times under slightly different names.
Much of it is never referenced. Records that no incident, change, request or integration has touched in a year. They exist because something once created them.
Migrating that wholesale means paying to move data you would not choose to create, and then maintaining it in a platform you chose to be cleaner.
The rule
Do not migrate the CMDB. Rebuild it, narrower.
This sounds more drastic than it is. You are not throwing anything away — you are archiving the old one and establishing a new one scoped to what your processes actually use.
How to scope it
Work backwards from usage, not forwards from the inventory:
- Which CIs are referenced by a live process? Incidents, changes, requests and problems in the last ninety days. This is the core, and it is usually a small fraction of the total.
- Which are targets of an active integration? Monitoring, discovery, deployment tooling. Each of these has an owner and a reason.
- Which appear in a service definition anyone uses? Service maps that are consulted, not service maps that exist.
- Which are required for compliance or audit? Licence positions, regulated assets. Often satisfied by an archive rather than a live record.
The union of 1–4 is your migration scope. Everything else goes to a read-only archive, exactly as with ticket history.
Rebuild relationships from discovery
Dependency data decays faster than anything else in a CMDB, and hand-maintained relationships decay fastest of all — created during a project, accurate for a quarter, never revisited.
Rebuild relationships from automated discovery in the new platform rather than migrating them. If a relationship is not discoverable, treat it as a claim rather than a fact, and require an owner to confirm it before it is recreated.
This is also the moment to be honest about depth. Many organisations model far more detail than any process consumes. If no workflow, report or impact assessment reads a particular attribute, it is costing you maintenance and returning nothing.
Where it belongs in the plan
In the analysis phase, not the migration phase.
| Phase | CMDB work |
|---|---|
| Analysis | Establish what is referenced; size the real scope; decide archive versus migrate |
| Development | Define the target model — narrower than the old one; configure discovery |
| Migration | Load the scoped set; run discovery; reconcile |
| Go-live | Verify the CIs the service desk actually touches |
| Hypercare | Fix the gaps the first fortnight exposes |
The pattern in migrating off ServiceNow holds here in a sharper form: analysis decides whether the rest is realistic, and the CMDB is where that is most true.
The upside nobody mentions
A replacement is the only realistic opportunity you will get to fix your CMDB.
Nobody funds a project to clean one up. It is unglamorous, it delivers no visible feature, and it is impossible to make a business case for on its own. But during a migration it is unavoidable work — so it is the one moment when doing it properly is free.
Organisations that take that opportunity end up with a smaller, accurate CMDB that people trust. Organisations that migrate wholesale arrive in the new platform with the same data nobody trusted before, having paid to bring it.
Frequently asked questions
- Can we just export and import the CMDB?
- Technically usually yes, and it is almost always the wrong choice. You would be importing years of accumulated staleness and duplication into a clean platform, then paying to maintain it. The export is worth taking as an archive; the import is worth resisting.
- How do we know which CIs matter?
- Work backwards from usage rather than forwards from the inventory. Which configuration items are referenced by an incident, change or request in the last ninety days? Which are targets of a live integration? Which appear in a service definition someone actually uses? What is left over is the candidate list for dropping.
- What about dependency mapping?
- Rebuild it from discovery rather than migrating it. Dependency data decays faster than anything else in a CMDB, and hand-maintained relationships are usually the most decayed of all. If it is not discovered automatically, be sceptical that it is still true.
- How long does this take?
- Longer than the rest of the migration if you leave it late, and much less if you scope it in the analysis phase. It is the workstream most likely to be discovered mid-programme, which is exactly why it should be sized before the plan is committed.