CSDM Is Not a Project You Finish. It's a Direction You Commit To.
Every organization that has successfully built a service-aware operational model went through the same progression — not because somebody designed a clever implementation plan, but because there is no shortcut from "we have a CMDB" to "our AI can reason about service impact." The path runs through four stages. Here's the map.
The Gap Between Having a CMDB and Having a Service Model
Most organizations that have been running ServiceNow for more than a year will tell you they have a CMDB. Ask them whether their CMDB accurately reflects service dependencies, and the confidence drops noticeably. Ask whether it's connected to business capabilities, and you get a different kind of silence — the kind that means "we've talked about doing that."
There's no shame in this. A CMDB that tracks infrastructure assets is genuinely useful. It's also a long way from a service model that allows operations teams to instantly understand which business capabilities are affected by a failing server — and that allows AI systems to reason about incident patterns, predict service disruptions, and recommend safe automated remediation. The gap between those two things is not a tool gap. It's a maturity gap.
ServiceNow describes the journey in four stages: Crawl, Walk, Run, and Fly. Each stage is a meaningful operational leap, not just a label. And the organizations that try to skip stages — jumping straight to AI-driven operations without the foundational service architecture — are the ones that buy impressive technology and produce mediocre operational outcomes.
✦ ✦ ✦
The Problem
Why Organizations Stay Stuck in Crawl
The Crawl stage is where most CSDM journeys begin and, for a significant number of organizations, where they quietly stall. The foundational work is done — infrastructure discovery is running, configuration items are populated, basic governance is in place. The CMDB is accurate enough to be useful for asset management. And then nothing happens. The organization moves on to the next initiative and the CMDB sits at Crawl indefinitely.
Why the Stall Happens
The Crawl stage produces a CMDB. The Walk stage requires service ownership — named humans accountable for maintaining service relationships, not just infrastructure records. That accountability shift is harder than the technical work. It involves organizational change, team agreements, and ongoing discipline. Organizations that treat CSDM as a technology implementation rather than an operational practice hit this wall and stop moving.
The cost of staying at Crawl is invisible until something goes wrong — a major incident where nobody can quickly determine which services are affected, an AI initiative that produces outputs the operations team doesn't trust, a modernization program that can't identify which legacy systems are load-bearing. The cost accrues silently. The invoice arrives at the worst possible moment.
The antidote is understanding the full progression — what each stage requires, what it enables, and what becomes possible that wasn't possible before. That understanding is what motivates the organizational investment to keep moving.
The Explanation
What Each Stage Actually Requires and Enables
Crawl: Getting the Foundation Right
The Crawl stage is about one thing: trust. Before any operational or AI capability can rely on the CMDB, the CMDB has to be reliably accurate for infrastructure assets. Discovery tools run, configuration items are populated, reconciliation rules are established, and the organization learns — often the hard way — how to keep discovered data from drifting.
The most important output of Crawl isn't the data itself. It's the governance discipline that keeps the data current. Organizations that implement discovery and then stop maintaining it don't graduate from Crawl. They have a CMDB snapshot that grows increasingly wrong over time and an operations team that learns not to trust it.
Walk: Service Context Changes the Conversation
The Walk stage is where CSDM begins to earn its name. Infrastructure components get associated with the application services they support. Application services get linked to business applications. Ownership becomes explicit — not just "this server exists" but "this server belongs to this service and this person is responsible for keeping that relationship accurate."
The operational payoff begins immediately. Incidents start being associated with services rather than just hardware. Change managers can start asking "what service does this affect?" as a standard part of review. Alert correlation improves because the event management layer has something to correlate against. The CMDB stops being just an inventory and starts being a map.
Run: Operations and the Service Model Become Inseparable
At Run, service architecture is woven into every major operational workflow. Change management evaluates impact through the service dependency chain as a matter of course. Incident management routes by service and communicates in service terms. Observability platforms pipe alerts into event management that groups them by service. The CMDB is no longer something operations teams consult occasionally — it's the substrate every operational decision runs on.
Automation carries more of the maintenance burden at Run. Service Graph Connectors pull authoritative data from cloud platforms, observability tools, and development environments. The service model stays current because systems update it, not just because humans remember to.
Fly: The Stage Everything Else Was Building Toward
At Fly, the service model is comprehensive, current, and trusted across the organization. This is the stage where AI-driven operations become genuinely useful rather than technically interesting. AIOps platforms can correlate complex multi-service incidents because the dependency map is accurate. Predictive models can identify which services are at risk because historical incident patterns are mapped to specific service lineages. Automated remediation can execute safely because the blast-radius analysis is grounded in real service relationships.
Portfolio governance also matures at Fly. Leadership has a real-time view of which business capabilities are healthy, which technology assets are risk-concentrated, and where modernization investment is most needed — not from a quarterly report, but from a live service model.
"Crawl isn't failure. Crawl is the only honest starting point. The organizations that try to skip it are the ones who rebuild it later — under pressure, during an incident, with everyone watching."
The Solution
Moving Forward: The Three Things That Drive Stage Progression
Organizations don't stall at Crawl because they lack ambition. They stall because the path to Walk, Run, and Fly is less about technology than it is about three organizational commitments that don't fit neatly into a project plan.
Ownership accountability, not just data entry. Each stage requires more people to be personally accountable for the accuracy of the service model. Crawl needs discovery administrators. Walk needs application service owners. Run needs cross-functional governance. Fly needs the whole organization operating in service terms. The progression is also a widening circle of accountability, and that circle has to be deliberately drawn and maintained.
Governance that survives personnel changes. The CMDB accuracy problems that plague organizations at Crawl almost always trace back to the same cause: a person who understood the system left, and nobody maintained what they built. Service model governance has to be institutionalized — documented, certified, audited — not carried in someone's head. The governance process is what makes the maturity sustainable rather than fragile.
Automation that keeps pace with the environment. At Crawl, humans mostly populate the CMDB. At Fly, automation does most of the work — Service Graph Connectors pull from authoritative sources, discovery tools maintain infrastructure relationships, integrations with observability platforms keep service health current. Investing in automation isn't optional at higher maturity stages. Manual maintenance cannot scale to the relationship density a Fly-stage service model requires.
How You Know You're Ready for the Next Stage
Maturity models are only useful if you can assess where you actually are. Here's the honest version of what each stage completion looks like:
Ready to leave Crawl when: your infrastructure discovery is running continuously and your team trusts the CMDB's infrastructure data enough to use it in incident response without double-checking against a separate inventory.
Ready to leave Walk when: more than 70% of incidents are associated with application services rather than just infrastructure CIs, and service owners are actively maintaining relationships rather than just being named in a spreadsheet.
Ready to leave Run when: change impact assessments routinely surface downstream service dependencies without manual investigation, and alert correlation is reducing noise rather than adding to it.
At Fly when: AI-generated recommendations are trusted by operations teams, predictive models flag service risks before incidents occur, and portfolio governance can read service health in business capability terms without a reporting project to assemble the data.
Summary
The Journey Is the Point
The organizations running AI-driven, service-aware operations today didn't get there by deploying a mature CSDM implementation on day one. They got there by completing Crawl, building the ownership structure that Walk requires, wiring service context into every operational workflow at Run, and arriving at Fly with a service model that AI systems can actually trust.
Each stage takes longer than anyone expects and produces more value than anyone anticipated. The CMDB that operations teams actually use for incident response. The change review that catches dependencies nobody remembered to ask about. The alert correlation that reduces a 200-alert flood to six meaningful events. These are Walk and Run outcomes — and they compound into the Fly-stage capabilities that make intelligent, autonomous operations possible.
Wherever your organization is on the journey, the question isn't whether the destination is worth reaching. It's whether you're treating the progression as a real organizational commitment or as a technology project that somebody else is responsible for. One of those gets you to Fly. The other keeps you at Crawl indefinitely.
Know your stage. Move to the next one. Repeat until you're flying.
