We implement and upgrade ServiceNow ITSM, Discovery, Service Mapping and the CMDB. Most of the work is making configuration data accurate enough that incident, change and the newer AI features can rely on it.
Cohash implements and upgrades ServiceNow ITSM, ITOM Discovery, Service Mapping and the CMDB.
We set up Discovery schedules and MID Servers, build service maps, align the CMDB to CSDM 5 and connect identity and HR data to the platform. Brazil is the current family in ServiceNow's documentation, and we plan upgrades with curated paths from Australia, Zurich or Yokohama.
you probably need this if
Change managers approve changes without knowing which services a CI supports.
Discovery creates duplicate servers every time a VM is rebuilt.
The instance is two families behind, and nobody's reviewed the skipped records from the last upgrade.
Instance health report with customizations ranked by upgrade risk
Identification and reconciliation rule set per CI class
CSDM 5 mapping of business applications to application services
+ 3 more documents
who does it
ServiceNow ITOM Discovery engineer (MID Server, patterns)Service Mapping specialistCMDB and CSDM data architect
Certified System Administrator (CSA)
Certified Implementation Specialist - IT Service Management (CIS-ITSM)
05 May 2026ServiceNow Otto announced Now Assist, Moveworks and AI Experience are being combined into one AI experience, with AI Control Tower governing actions. Rolling out across products over the following year. source ↗
10 Sep 2026Brazil family Current release in ServiceNow's documentation, with curated upgrade paths from Australia, Zurich and Yokohama. source ↗
today · Oct 22, 2026
no date yetCSDM 5 relationshipsCSDM v5 uses the Uses::Used By relationship between business applications and application services.source ↗
the story · servicenow estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your ServiceNow estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · servicenow estate3 open
openChange managers approve changes without knowing which services a CI supports.
recurringDiscovery creates duplicate servers every time a VM is rebuilt.
blockedThe instance is two families behind, and nobody's reviewed the skipped records from the last upgrade.
exposure
ITSM implementation and clean-upITOM DiscoveryService MappingCMDB and CSDM 5 alignmentFamily upgradesIntegrations
startrehearsehandover
Instance health check
Data model decisions
Build and clean
Upgrade and handover
we are here
ready to hand over
Each server shows up once, with a clear source of truth, so incidents get routed to the…
Change managers see which services a change touches, and the instance moves to Brazil…
Instance health report with customizations ranked by upgrade risk
Identification and reconciliation rule set per CI class
chapter 01 · where it hurts
Why teams reach out
Change managers approve changes without knowing which services a CI supports.
Discovery creates duplicate servers every time a VM is rebuilt.
The instance is two families behind, and nobody's reviewed the skipped records from the last upgrade.
chapter 02 · what we change
How we solve it
ITSM implementation and clean-up
ITOM Discovery
Service Mapping
CMDB and CSDM 5 alignment
Family upgrades
Integrations
chapter 03 · how it runs
Our approach
Instance health check
Data model decisions
Build and clean
Upgrade and handover
chapter 04 · where you end up
What changes
Each server shows up once, with a clear source of truth, so incidents get routed to the right support group.
Change managers see which services a change touches, and the instance moves to Brazil with the data model in place.
Instance health report with customizations ranked by upgrade risk
Identification and reconciliation rule set per CI class
what we do
Our ServiceNow work
6 kinds of ServiceNow work, each run by engineers who have done it on live tenants.
Incident, problem, change and request configured close to baseline, with custom tables and scripts reviewed so the next family upgrade isn't a rewrite.
MID Server sizing and placement, credentials, IP ranges and schedules set up so Discovery finds what is really on the network and doesn't flood the CMDB with duplicates.
Top-down and tag-based maps for the business services that matter in change and incident, owned by named application teams.
Identification and reconciliation rules, CI class decisions and CSDM 5 relationships such as Uses::Used By between business applications and application services.
Skipped-record review, customizations compared against the new family, and test runs on a cloned instance before each upgrade.
Identity data from Entra ID or Okta, HR data from Workday, and Service Graph Connectors where they fit, so the CMDB has accurate owners.
capability 01 / 06in production
ITSM implementation and clean-up
Incident, problem, change and request configured close to baseline, with custom tables and scripts reviewed so the next family upgrade isn't a rewrite.
MID Server sizing and placement, credentials, IP ranges and schedules set up so Discovery finds what is really on the network and doesn't flood the CMDB with duplicates.
Identification and reconciliation rules, CI class decisions and CSDM 5 relationships such as Uses::Used By between business applications and application services.
We pieced these together from ServiceNow situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Discovery running nightly, CMDB with duplicate servers everywhere
composite · not a client story
Beforethe situation
Discovery runs from four MID Servers and a cloud import adds the same VMs by another name. Rebuilt servers appear twice, and incident assignment uses whichever record it finds first.
What we dothe work
We go through identification rules and source priorities for the server classes, align the cloud import to the same rules, merge duplicates in batches, and add a data quality dashboard the platform team looks at weekly.
Afterwhere you end up
Each server shows up once, with a clear source of truth, so incidents get routed to the right support group.
case file 02
Zurich instance, CSDM adopted on paper only
composite · not a client story
Beforethe situation
The instance runs Zurich. CSDM was signed off two years ago, yet business applications still aren't linked to application services, so change risk gets calculated with no service context.
What we dothe work
We map the top business services with application owners, create the CSDM 5 relationships, build service maps for those services and connect change risk to them. The upgrade to Brazil is rehearsed on a clone in parallel.
Afterwhere you end up
Change managers see which services a change touches, and the instance moves to Brazil with the data model in place.
We don't start a step until the last one has produced something you can check.
step 01
Instance health check
We start with customizations and skipped records from past upgrades, then Discovery schedules, MID Server health, identification rules and the CMDB data quality dashboards.
step 02
Data model decisions
CI classes, identification and reconciliation rules and CSDM 5 relationships agreed with process owners before any clean-up starts.
step 03
Build and clean
We configure Discovery and Service Mapping for priority services, merge the duplicates and retire stale CIs. Owners come from HR and identity data.
step 04
Upgrade and handover
Each family upgrade gets rehearsed on a clone with automated tests before we run it in production. The runbooks and data quality checks are your platform team's to keep.
ai on servicenow
Where AI fits on ServiceNow, and where it needs guardrails.
ServiceNow announced Otto in May 2026, bringing Now Assist and Moveworks together with AI Experience. AI Control Tower governs what it does. Through the MCP Server Console, outside AI apps can call instance tools over OAuth. All of this reads incident and knowledge records and the CMDB, so it's only as useful as that data is good.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
ServiceNowdoes the work
There's an official ServiceNow MCP server, set up through the MCP Server Console. We create an OAuth inbound integration per client and expose only the tools that client needs. Monitoring goes through AI Gateway in AI Control Tower. Record changes stay behind approval workflows.
ServiceNow Otto and Now Assist
Otto is rolling out across products over the year after its May 2026 announcement. Summarization and knowledge use cases go first for us. After that we fix the CMDB ownership and relationship data the answers depend on.
AI Control Tower
AI Control Tower governs Otto actions, and its AI Gateway shows MCP server access and tool metrics. We set it up before agents get write access. That way every agent action has a record.
MCP Server Console
Admins build MCP tools out of what's already there, some Now Assist skills among them, and the Quickstart Server looks up incidents and cases and summarizes them. We publish just the tools a client needs, with one OAuth inbound integration per client.
CMDB clean-up with AI help
Point an AI assistant at Discovery data and change history and it'll propose CSDM 5 relationships and owners. CI owners confirm each change before it's written.
How data reaches the ServiceNow CMDB and who uses it
Discovery probes the network through MID Servers while Service Graph Connectors and identity feeds add cloud and ownership data. The CMDB reconciles it all against identification rules. Incident, change and service maps read from that one record.
01 · Data sources
Data center and cloudservers · VMs · Kubernetes → MID Servers · discovery→ Service Graph Connectors · API import
Entra IDusers · groups → CMDB and CSDM 5 · owners · groups
Workdaypeople · cost centers → CMDB and CSDM 5 · people data
02 · Collection
MID ServersDiscovery probes · patterns → CMDB and CSDM 5 · CIs via IRE
Service Graph Connectorscloud and tool imports → CMDB and CSDM 5 · CIs via IRE
03 · ServiceNow platform
CMDB and CSDM 5IRE · reconciliation → Service Mapping · service maps→ Incident and problem · affected CIs
Service Mappingapplication services → Change management · impact
04 · Processes
Incident and problemimpact · assignment
Change managementrisk · approvals
Read the diagram as text
Data center and cloud → MID Servers: discovery
MID Servers → CMDB and CSDM 5: CIs via IRE
Data center and cloud → Service Graph Connectors: API import
Service Graph Connectors → CMDB and CSDM 5: CIs via IRE
Entra ID → CMDB and CSDM 5: owners · groups
Workday → CMDB and CSDM 5: people data
CMDB and CSDM 5 → Service Mapping: service maps
Service Mapping → Change management: impact
CMDB and CSDM 5 → Incident and problem: affected CIs
use cases
Typical ServiceNow projects
The work teams usually bring us, and the platforms ServiceNow has to talk to while we do it.
SER-01Discovery runs but the CMDB is full of duplicates and stale CIs
common request
SER-02Change approvals ignore impact because service maps don't exist
common request
SER-03The instance is two families behind and nobody wants to own the upgrade
common request
SER-04CSDM was adopted on paper but business applications and services aren't linked
common request
SER-05AI features are on the roadmap and the data underneath them is unreliable
common request
These are working documents, written against your configuration, so your team can run them without us.
report01
Instance health report with customizations ranked by upgrade risk
yours to keep
document02
Identification and reconciliation rule set per CI class
yours to keep
inventory03
CSDM 5 mapping of business applications to application services
yours to keep
plan04
Discovery schedule, credential and MID Server design
yours to keep
document05
Service maps for priority business services with named owners
yours to keep
runbook06
Family upgrade runbook with skipped-record decisions
yours to keep
talent and delivery · servicenow
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.
Put these to anyone bidding on your ServiceNow work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you decide identification rules before cleaning CMDB data?
Cleaning without rules just recreates the duplicates on the next Discovery run. The rules have to come first.
Q2
Our last upgrade left skipped records. How many, and who reviews them this time?
Skipped records nobody reviews mean the baseline fixes never arrive. They stack up, and every upgrade after that is harder than the last.
Q3
Which business services will you map first, and who will own them?
Service maps without owners decay within months. Starting with a few owned services beats mapping everything once.
Q4
How will you place and size MID Servers for our network segments?
Discovery is only as good as the MID Servers' reach, credentials and capacity. A good plan names the network segments, the firewall rules and the load you expect.
Q5
What has to be true in our data before Now Assist or Otto features help us?
AI features work from incident, knowledge and CMDB records. If ownership and relationships are wrong, the answers will be wrong too.
01Which ServiceNow release is current?
Brazil, per ServiceNow's documentation as updated 10 September 2026. There are curated upgrade paths from Australia, Zurich and Yokohama. Release support dates sit in the Now Support knowledge base, so check your instance there before you plan.
02How long does a ServiceNow family upgrade take?
It depends on how many skipped records the upgrade produces, how many custom scripts touch baseline tables and how much automated testing you have. We clone production, run the upgrade, review skipped records and set the plan from that.
03Why is our CMDB full of duplicates?
Usually because data arrives from several sources without agreed identification and reconciliation rules. Discovery, Service Graph Connectors and manual imports each create CIs their own way. We fix the rules first, then clean the data.
04Do we need Service Mapping if we already run Discovery?
Discovery tells you what devices and software you have. Service Mapping tells you which of those make up a business service. If change approvals and incident impact need to know what will break, you'll want maps, at least for the services that matter most.
05Do you staff ServiceNow developers and administrators?
Yes. ServiceNow administrators, developers and ITOM engineers on contract, contract-to-hire or permanent terms. Onsite in the US, nearshore or offshore, any time zone.
services
Related services
Projects on ServiceNow usually end up touching one of these, so they're worth a look.
