We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Network inventory migration approach from legacy system to ServiceNow TNI

SY8
Tera Contributor

2 hours ago

What is the recommended or best-practice approach for migrating TNI data from a legacy system to ServiceNow, particularly for network inventory, circuits, and related relationships? Would you recommend using a staged ETL approach (e.g., Import Sets/IntegrationHub ETL with IRE) rather than direct data loads?
0 Helpfuls
  • 37 Views
1 REPLY 1

Vikram Reddy
Tera Guru

19m ago

Hello @SY8,

 

Staged ETL, not a direct load, every time. I've worked telecom migrations before and the direct-load shortcut always looks faster in week one and costs you a re-migration in month three. Here's why and how I'd plan it.

TNI's core classes, Network Site (cmdb_ci_ni_site), Telco Equipment Holder (cmdb_ci_ni_equipment_holder), Telco Equipment (cmdb_ci_ni_equipment), Physical Connection (cmdb_ci_ni_physical_link), and Logical Connection (cmdb_ci_ni_logical_path, this is where your circuits live end-to-end), all sit on the CMDB and get de-duped through the Identification and Reconciliation Engine (IRE). Only IntegrationHub ETL runs through IRE automatically. A raw import set/transform map load skips it unless you hand-code the IRE call, which almost nobody does correctly on the first pass, and re-running the migration (or letting Discovery touch the same CIs later) then creates duplicate equipment and orphaned cmdb_rel_ci relationships instead of clean updates.

Plan it in this order:

  1. Profile and clean the legacy extract first: dedupe circuit records, normalize site codes and equipment naming, this is cheaper to fix in a spreadsheet than in a polluted CMDB.
  2. Define IRE identification rules per TNI class before the first load, natural keys like site code, serial number, or slot position, not just name.
  3. Load in dependency order: sites and equipment holders, then equipment, then physical connections, then logical connections/circuits last, since connections need both endpoints to already exist.
  4. Set reconciliation rules so it's explicit which source (your migration job vs. later Discovery or a network element manager feed) is authoritative for each attribute going forward.
  5. Dry-run the full staged load in a sub-prod instance, check what else already references the legacy identifiers (work orders, other integrations, reports) before you cut over, and keep an export of the source data as a fallback during hypercare.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls