Migrating from Cisco Intersight ITSM Plugin to Service Graph Connector

[AureaLeaC]

Hi everyone,

We are currently encountering an issue with duplicate CIs in our CMDB after migrating from the deprecated Cisco Intersight ITSM Plugin to the Service Graph Connector for Cisco Intersight, and I would like to ask for recommendations on the best remediation approach.

 

Current Situation:

Previously, we were using the Cisco Intersight ITSM Plugin for discovery/integration. Since the plugin is already deprecated, we replaced it with the Service Graph Connector for Cisco Intersight.

After installing and configuring the Service Graph Connector, it imported all Cisco devices from Intersight into the CMDB. However, most of these devices already existed in our CMDB from the previous plugin integration.

Issue

The newly imported CIs were created as new records instead of updating or reconciling with the existing ones, resulting in duplicate CIs.

One thing we noticed is that:

• In the previous plugin, most Cisco devices were classified under generic classes such as Cisco Servers.
• In the Service Graph Connector, devices are now being created under more specific and different CMDB classes.

Because of this class mismatch:

• Identification and Reconciliation Engine (IRE) did not match them correctly.
• No duplicate CI remediation tasks were created.
• Existing CIs and newly imported CIs are now coexisting in different classes.

Questions

1. What is the recommended approach for remediating these duplicate CIs?
2. Has anyone encountered a similar issue when migrating from the legacy Cisco Intersight ITSM Plugin to the Service Graph Connector?
3. Are there any best practices for preserving relationships, history, and dependent records during remediation?

Any recommendations, migration experiences, or best practices would be greatly appreciated.

Thank you!

[pr8172510]

Hi @AureaLeaC,

This is a common issue during migration from the deprecated Cisco Intersight ITSM Plugin to the Service Graph Connector because the Service Graph Connector uses different CMDB classes and Identification Rules.

• Keep the new Service Graph Connector CIs as the authoritative source
• Retire/remediate legacy plugin CIs gradually
• Review and update IRE Identification Rules
• Avoid manual bulk deletion without validating relationships

Purpose Table

CI Records	cmdb_ci
Relationships	cmdb_rel_ci
Identification Rules	cmdb_identifier
IRE Logs	cmdb_ire_output
Duplicate Tasks	cmdb_duplicate_task

Why duplicates happened

• Old plugin used generic Cisco CI classes
• Service Graph Connector creates more specific CSDM-aligned classes
• IRE could not reconcile across different classes
• Therefore new CIs were inserted instead of updated

 remediation

Validate new Service Graph CIs
        ↓
Map old CI classes to new classes
        ↓
Merge/reconcile relationships
        ↓
Retire old plugin CIs
        ↓
Disable legacy integration jobs

 Use Service Graph Connector as authoritative source
 Align with CSDM classes
Review identification rules before migration
Use IRE-based reconciliation
Retire legacy integrations after migration validation

This is the supported long-term CMDB approach.

[AureaLeaC]

hi @pr8172510  Thank you so much for the explanation and proposed solution.

This issue is currently occurring in our DEV instance, and I still need to perform the same process in our UAT environment. What would you recommend to avoid these duplicate records before I install the SCG in UAT?

[AureaLeaC]

Hi @pr8172510 

Thank you so much for the explanation and proposed solution.

This issue is currently occurring in our DEV instance, and I still need to perform the same process in our UAT environment. What would you recommend to avoid these duplicate records before I install the SCG in UAT?

[pr8172510]

Hi @AureaLeaC,

Before installing SCG in UAT best practice is:

1. Disable/retire old Cisco Intersight plugin jobs first
2. Review existing CI classes used by old plugin
3. Review and tune IRE Identification Rules before first SCG import
4. Ensure serial number / UUID / asset identifiers are populated correctly
5. Run SCG import in small test scope first
6. Validate IRE behavior in:cmdb_ire_output

1. Use Identification Simulation before full load
2. If possible, reclassify legacy CIs to target SCG classes before migration

Duplicates happened because:

• old plugin used generic classes
• SCG uses more specific CSDM-aligned classes
• IRE does not reconcile across different classes automatically
  
  Service Graph Connectors should be used as the authoritative source with properly configured Identification Rules and IRE reconciliation.

      validate:

• class mapping
• identifiers
• reconciliation rules

before production onboarding to avoid duplicate CIs.