By Ian Cox, Founder & CEO of Four Dragons — former ten-year ServiceNow employee.

Most “failed” ServiceNow implementations did not fail at the technology. The platform is running. Licenses are paid. Somebody delivered something. But the CMDB nobody trusts, the Discovery that finds half the estate, the AI agent that never left pilot, the SAM module that still cannot produce a defensible license position — that is not a broken product. It is an implementation that installed features without fixing the data and the discipline underneath them. Rescuing it is a specific, repeatable exercise, not a rip-and-replace. Here is what it actually involves.

First, diagnose honestly — is it the data or the design?

A real rescue starts with a diagnosis, not a statement of work. Nine times out of ten the root cause is the same: the data layer was never made trustworthy, so everything built on top of it inherits the doubt. Duplicate and orphaned CIs, identification-and-reconciliation rules that were never tuned, Discovery credentials and MID Servers that quietly stopped covering whole segments, a CSDM model that exists on a slide but not in the tables. Before anyone writes new automation, you have to know which of your problems are data problems (most of them) and which are genuine design mistakes (fewer than you think).

The rescue sequence that works

Rescues that stick tend to follow the same order, because each step depends on the one before it:

Skip the first step and you are not rescuing anything — you are adding another layer to the pile the next partner will have to dig through.

Why the original partner usually can’t rescue their own work

This is not always true, but it is common enough to name. If the initial implementation was delivered by a layered team — senior names in the sales cycle, junior or subcontracted staff learning on your instance — the same structure cannot fix the deep problems it created, because the depth was never there. A rescue is precisely the kind of work that hinges on ServiceNow-native expertise: someone who has tuned IRE, argued a license position with a publisher, and stood up Service Mapping on messy real-world data. It is a depth problem, not a headcount problem.

The reframe worth keeping

Underneath almost every stalled ServiceNow platform is a skills gap, not technical debt. The instance is rarely as broken as it feels; what is missing is the platform-native discipline to run it well. That is good news for a rescue — it means the fix is closing the gap, not starting over. A specialist restores the data, rebuilds the skipped capability, and hands the discipline back to your team so the recovery holds. You keep the platform, the license spend, and the history — you just make them finally work.

If your ServiceNow program has stalled, the first move is not another feature. It is an honest diagnosis of the data and the discipline underneath it — and then the sequence above, in order. See measurable rescue outcomes from prior engagements.

Four Dragons is a boutique ServiceNow consultancy led by a former ten-year ServiceNow employee, delivering CMDB/CSDM, ITOM, ITAM/SAM, SPM, and Agentic AI outcomes — AI-automated, human-supervised. We fix the data instead of adding features. fourdragons.com

About the author

Ian Cox is the Founder and CEO of Four Dragons, a boutique ServiceNow consultancy specializing in CMDB/CSDM, ITOM, ITAM/SAM, SPM, SecOps, and agentic AI. He spent ten years at ServiceNow before founding the firm and works from Napa, California. Four Dragons fixes the underlying data and closes the skills gap rather than adding features.

Leave a Reply

Your email address will not be published. Required fields are marked *