Why a Two-Way Connection Between ITSM and CMDB Is Non-Negotiable in 2026
A configuration management database (CMDB) earns its budget line by answering one question: what does this service actually depend on. Enterprise IT teams spend months proving that a CMDB can answer it accurately. Fewer spend the same scrutiny on a second question that determines whether the first answer stays true past the day it was scanned; does the connection between the CMDB and the IT service management (ITSM) platform running daily operations carry data in one direction, or two.
That second question is not a footnote. It decides whether a dependency map describes an estate as it exists right now, or as it existed at the moment of the last import.
The Asymmetry Hiding Inside a Working Integration
University College London (UCL) ran its infrastructure through Xurrent, its ITSM platform, before its Virima deployment closed the gap discussed above. The integration worked, in the narrow sense that asset data moved from Virima into Xurrent on schedule. Mandy Silk, UCL’s Service Management Principal, described the shape of that arrangement plainly: “The existing connector is one way. Assets are passed into Xurrent.”
An integration that only sends data outward looks complete from the sending side. Assets appear where they’re supposed to appear, records populate, dashboards fill in. Nothing about that view discloses what’s missing, because the missing piece isn’t a broken pipe, it’s a pipe that was never built to carry traffic back.
Our Xurrent integration page describes where that second direction is headed generally: the Virima Visual Impact Display (ViVID) is built to complete service maps with overlays of ITSM records, including open incidents and recent or planned changes, and the page states that overlay as something Xurrent users “will soon enjoy” in full. That’s our roadmap for a capability still reaching general rollout. UCL didn’t wait for that rollout. It got a working version of the overlay already, built specifically for its environment.
What a One-Way Feed Cannot Tell an Operations Team
Gartner analysts Roger Williams and Kenneth Gonzales, in a 2023 CMDB data quality study, traced inaccurate configuration item (CI) data in service-view CMDBs to a specific set of causes: gaps in data ownership, in data model scope, and in the tooling connecting systems of record to each other. A connector that moves data in one direction is a tooling gap in exactly that sense. It has an owner on the sending side and no owner tracking what happens to that data afterward.
The practical cost shows up during incidents and changes, not during discovery. A CMDB that only receives asset snapshots knows what existed at import time. It has no visibility into what changed since, which change tickets touched which components, or which incidents already affected a given service. Every one of those events happened on the ITSM side, and none of them traveled back.
Why the Fix Has to Be Structural, Not Periodic
The temptation with a one-way integration is to shorten the sync interval and treat frequency as the solution. That treats a directional problem as a timing problem, and the two are not the same. A nightly sync running one direction still misses every change and incident that occurred between imports; it just misses a smaller window of them.
A 2026 analysis of CMDB decay patterns frames this as an operating-capability question rather than a project milestone. Organizations that treat CMDB accuracy as a one-time initiative see the same outcome regardless of how well the initial rollout went: the map degrades from the moment daily operations resume, because nothing in the architecture feeds real-world events back into it. Organizations that build a closed loop into the architecture itself don’t face the same decay curve, because the map keeps receiving the operational events that would otherwise silently outdate it.
Schedule a demo to see how Virima delivers a closed-loop CMDB-ITSM architecture.
The Requirement Nobody Wrote Into the Original Deal
UCL’s Virima purchase closed on a different, narrower proof point. During a nine-month proof of concept, dependency mapping was the single requirement UCL’s evaluation team had to validate before signing, alongside automated CI discovery and Xurrent integration as baseline requirements. That proof point answered whether our platform could compute accurate relationships across a live, multi-cloud estate. It said nothing about whether operational events would flow back into those relationships once the contract was signed.
The two-way connector was never part of that evaluation. It surfaced afterward, alongside two other post-sale requirements UCL hadn’t scoped in advance. Paula Kirby, UCL’s Director of Service Management, described how those gaps closed: “Virima was very responsive to enhancement requests: Oracle DB discovery, security-compliant scanning, and the Xurrent connector were all iterated collaboratively.”
Two of those three items extended what Virima could discover. The third changed what the integration itself could carry, and that distinction is what separates a wider net from a different architecture.
What Changed Once the Loop Closed
Mandy Silk’s account of the result names the specific change: “What we’re excited about is seeing changes and incidents in ViVID’s maps. That two-way view is what we’ve been waiting for.”
Before the connector was rebuilt, a change ticket or an incident logged inside Xurrent stayed inside Xurrent ITSM. The dependency map computed by Virima had no way to reflect it. After the rebuild, those same events surface inside the map itself, which means the map now describes what is happening to a service, not only what a service is connected to. That is a different instrument than the one UCL evaluated during its proof of concept, built to answer a question the original evaluation never asked.
Ahead of the General Rollout
The ITSM overlay is still a forthcoming benefit at the time this article is published. Paula Kirby’s account of the Xurrent connector being “iterated collaboratively” describes how UCL got there ahead of that general timeline: an integration platform as a service (iPaaS) connection built specifically for UCL’s environment, carrying change and incident events back into Virima’s maps rather than waiting on a wider release.
The requirement itself came from UCL’s own operational reality, discovered after the sale rather than specified before it. Building it for one live deployment, ahead of the capability’s general availability, was the response, a bespoke fix to a gap that no evaluation process could have surfaced in advance.
The Standard the Loop Sets
A one-way CMDB-to-ITSM connection produces a record of what an estate looked like at the last import. A two-way connection produces a record of what is happening to it now, and our integration materials describe that second state as a capability still reaching general availability. UCL didn’t get there on that general timeline. It got there because a live requirement surfaced after the sale and got built ahead of schedule. Enterprise IT teams evaluating a CMDB-ITSM pairing in 2026 are choosing between those two instruments whether or not the RFP asks the question directly, and UCL’s own timeline shows the gap between them tends to surface only after the contract is signed.
Book a demo to see how Virima’s two-way ITSM-CMDB integration works in a live environment.
