ServiceNow family upgrades, CMDB health and CSDM
We upgrade ServiceNow instances to the current family and fix the CMDB while we're there. Skipped records and customizations get reviewed, Automated Test Framework suites get built, and sub-production goes first. After that, CMDB health. We set identification rules, clear duplicate CIs and stale data, and line business applications and application services up with CSDM 5, so upgrades get boring and AI features can trust the data.
- 01Customization and skipped record review
- 02Test automation
- 03Upgrade in sub-production
- 04CMDB data sources and identification
- 05CSDM alignment
The story
Told without the client's name or anything that could identify them.
An insurer's ServiceNow team was still on Yokohama and dreaded each upgrade, because skipped records piled up unreviewed and every patch was tested by hand. Change approvals ignored the CMDB, since Discovery, Intune and a cloud connector each created their own copy of the same server. It became urgent when Now Assist started giving wrong answers built on missing services and owners. We reviewed customizations and skipped records first, built Automated Test Framework suites, and repeated the sub-production upgrade until it ran clean before production went to Brazil. Then we set identification rules per data source and modeled the critical services under CSDM 5 with named owners.
why it was urgentBrazil is ServiceNow's current family, and there are curated upgrade paths to it from Australia, Zurich and Yokohama. Two other changes matter. CSDM 5 redraws how business applications relate to application services. And in May 2026 ServiceNow announced Otto, which puts Now Assist and Moveworks into one AI experience with its actions governed by AI Control Tower.
- openEach upgrade leaves hundreds of skipped records that nobody reviews.
- recurringChange approvals ignore the CMDB because nobody trusts it.
- blockedThe same server shows up three times, once each from Discovery, Intune and a cloud connector.
- openNow Assist answers are wrong because services and owners are missing.
The estate, before and after
Before: an old family and a CMDB nobody trusted
Three data sources wrote CIs into the CMDB without identification rules, so the same server appeared several times. Change approvals stopped using the CMDB, Now Assist answered from incomplete data, and each upgrade was tested by hand.
Read the diagram as text
- ServiceNow Discovery → CMDB: creates CI
- Microsoft Intune → CMDB: creates duplicate
- Cloud connector → CMDB: creates duplicate
- Manual upgrade testing → Yokohama instance: manual regression
- CMDB → Change approvals: not trusted
- CMDB → Now Assist: missing owners
After: Brazil with reconciled CIs and a CSDM 5 service model
We put identification and reconciliation rules on every data source, and now each server lands as one CI on the Brazil instance. The CSDM 5 service model feeds owners and impact to change, Now Assist and the CMDB Health dashboard.
Read the diagram as text
- ServiceNow Discovery → Identification rules: CI payload
- Service Graph Connectors → Identification rules: CI payload
- Identification rules → ServiceNow Brazil: update existing CI
- ATF suites → ServiceNow Brazil: upgrade checks
- ServiceNow Brazil → CSDM 5 service model: service mapping
- CSDM 5 service model → Change risk and approval: impact analysis
- CSDM 5 service model → Now Assist and Otto: owners and services
- ServiceNow Brazil → CMDB Health dashboard: health metrics
How we run it, phase by phase.
5 phases take you from ServiceNow on Yokohama, Zurich or Australia to ServiceNow Brazil with a CSDM 5 aligned CMDB. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Customization and skipped record review
Pull the list of out-of-box records you've customized, and every skipped record from past upgrades. Revert whatever no longer needs to differ. A change survives only if someone owns it and can explain why it's there.
- phase 02
Test automation
Build Automated Test Framework suites for incident, change and request, and for the key integrations. That way every upgrade and patch gets the same checks.
- phase 03
Upgrade in sub-production
Upgrade a clone of production first. Fix what breaks, skipped records and failed tests alike, and repeat until a run is clean. Then schedule production.
- phase 04
CMDB data sources and identification
We map each data source, set up identification and reconciliation rules, and fix duplicates, so Discovery and Service Graph Connectors update one CI instead of creating new ones.
- phase 05
CSDM alignment
Put business applications, application services and technical services into CSDM 5, each with an owner and support group, and track completeness and staleness on the CMDB Health dashboard.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every upgrade and patch runs the same automated checks
We built Automated Test Framework suites for incident, change, request and the key integrations, and they run on a sub-production clone before any production upgrade gets scheduled.
- result 02
Skipped records get a decision instead of a backlog
We reverted the customizations nobody could own or explain. Skipped records from each upgrade now get reviewed, one by one, and kept or reverted.
- result 03
One server shows up as one CI
We set identification and reconciliation rules per data source. Discovery and Service Graph Connectors now update the CI that's already there instead of creating another.
- result 04
Business applications and services have owners
We put each critical system into CSDM 5 as a business application, application service or technical service, with an owner and a support group.
- result 05
CMDB health is measured, with a backlog to fix it
We set a CMDB Health dashboard baseline for completeness and staleness, and made the remediation backlog visible to the change and incident teams who rely on the data.
Risks we plan for
-
Skipped records pile up
Unreviewed skipped records mean features silently stay on old versions. They grow with each upgrade until one upgrade breaks something visible.
-
Duplicates from multiple sources
Add a data source without identification rules and you get duplicates. Those duplicates break impact analysis and change risk scoring.
-
AI on bad data
Now Assist and agents route, summarize and recommend from CI and service data. Missing owners or wrong relationships produce confident but wrong answers.
Where AI helps, and where it needs guardrails
ServiceNow Otto combines Now Assist, Moveworks and AI Experience, and AI Control Tower governs what its agents do. Those agents ask the CMDB who owns a service and what a change will hit, so a bad CMDB makes for bad answers. External agents or MCP servers calling ServiceNow should use an integration user with ACLs scoped to just the tables they need. Any change they raise goes through the normal change approval path.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- report01
Customization and skipped record review with decisions
yours to keep - tests02
Automated Test Framework suites for core processes
yours to keep - runbook03
Upgrade runbook and sub-production results
yours to keep - design04
Identification and reconciliation rule design per data source
yours to keep - design05
CSDM 5 service model with owners
yours to keep - plan06
CMDB health baseline and remediation backlog
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we upgrade first or fix the CMDB first?
Usually the upgrade first, with skipped records cleaned up, because it reduces the version gap. CMDB work then runs on the current family. If the CMDB is so bad that change management is unsafe, we start both together.
02Do we have to adopt CSDM 5?
No, not in one go. We begin with the business applications and application services behind the systems change and incident care about most, and work outward.
03Can you run upgrades for us every release?
Yes. Once the test suites exist, we run each upgrade as a planned service, and we staff ServiceNow developers and CMDB engineers on contract too.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study4f18202f - 01ServiceNow docs: Brazil release notesservicenow.com ↗
- 02ServiceNow docs: Upgrades and release familiesservicenow.com ↗
- 03ServiceNow docs: CSDM CI relationshipsservicenow.com ↗
- 04ServiceNow newsroom: ServiceNow Otto (5 May 2026)newsroom.servicenow.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it