Migrating Ivanti Neurons to ServiceNow takes 2 to 4 weeks, requires strict CMDB load ordering, and is constrained by Ivanti's 100K daily API call limit and 50K row export cap.
Migrating from Ivanti Neurons for ITSM to ServiceNow is a moderate-to-high complexity effort with no native migration path or reverse-direction connector available. Ivanti Neurons uses a flat, endpoint-centric business object model with independent RecId-keyed objects, while ServiceNow employs a CMDB-first relational architecture where all task records inherit from a single task table with sys_id foreign key dependencies. Custom work is required to build crosswalk tables for ID translation, reclassify CIs into ServiceNow's class hierarchy, transform picklist values from display strings to numeric codes, and enforce a strict load order to preserve referential integrity across users, groups, CIs, and tickets.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Quick answer
Migrating from Ivanti Neurons to ServiceNow is a moderate-to-high complexity ITSM migration. It is not a lift-and-shift. Ivanti Neurons uses a flat, endpoint-centric business object model. ServiceNow uses a CMDB-first relational architecture where nearly every record inherits from the task table. The biggest risk is breaking CI-to-incident and CI-to-change relationships during load. Ivanti's 50,000-row Excel export cap and 100,000 daily API call limit make native exports unviable for enterprise datasets. Teams with fewer than 10,000 total records and no complex CMDB can run this in-house. Everyone else should use a managed migration service or allocate a dedicated engineer for 3 to 6 weeks.
Service requests are the most common false 1-to-1 mapping
Ivanti's service request model is subscription-and-parameter driven with its own subscriptionId, serviceReqData, and parameter RecIDs. ServiceNow generates a parent sc_request plus one or more sc_req_item records. If you only load RITMs, you lose the request wrapper and variable context. Design this mapping explicitly. (help.ivanti.com)
Throughput math matters
At 100 records per call and a throttle point of 100,000 API calls per 24 hours, a flat extract tops out at 10,000,000 rows per day on paper. Real ITSM migrations run far below that because journals, attachments, and relationship calls consume the same daily budget. A naive pull of 100,000 incidents plus one journal call per incident already burns about 101,000 calls before you touch attachments. Pre-calculate your total API call count before starting extraction.
For long-running extractions, re-authenticate before each major batch
If you are using session-based auth rather than API keys or OIDC, Ivanti session tokens expire based on tenant timeout settings with no refresh mechanism. Call the logout endpoint after completing each session to avoid exhausting concurrent session capacity.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in Ivanti Neurons ITSM
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because ServiceNow almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in ServiceNow will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated Ivanti Neurons ITSM → ServiceNow timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that ServiceNow is the right target before you commit
Ivanti Neurons ITSM → ServiceNow specifics
- Data model structure
- Ivanti Neurons stores Incidents, Service Requests, Problems, and Changes as independent business objects with RecId primary keys and relationship links. ServiceNow inherits them all from a single task table, meaning every record shares a common schema with type-specific extensions.
- CMDB design
- Ivanti's CMDB is optimized for endpoint and device data fed by passive and active discovery. ServiceNow's CMDB uses a class hierarchy (cmdb_ci and dozens of child tables like cmdb_ci_server, cmdb_ci_win_server) with relationship tables (cmdb_rel_ci) that encode upstream/downstream dependencies. You cannot dump flat CI data into ServiceNow's base tables and expect operational value.
- API architecture
- Ivanti exposes an OData v4 REST API at /api/odata/businessobject/{objectname}. ServiceNow uses a proprietary Table API at /api/now/table/{tableName} plus an Import Set API for bulk loads. The pagination, auth, and throttling models are completely different. (help.ivanti.com)
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the Ivanti Neurons ITSM export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of Ivanti Neurons ITSM satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
Ivanti Neurons ITSM → ServiceNow specifics
- Deleted or merged users
- If an Ivanti ProfileLink_RecID references a user that was deleted or merged before extraction, decide now: map the reference to a placeholder "Migrated User" account in ServiceNow, or null the field. Nulling it loses assignment history. A placeholder preserves the audit trail without creating a real login.
- Decommissioned CIs
- CIs marked as retired or decommissioned in Ivanti should be migrated into ServiceNow with an install_status of "Retired" (7) rather than excluded entirely. Historical tickets reference these CIs, and excluding them creates orphaned cmdb_ci references.
- Deactivated groups
- Import inactive Ivanti Teams as inactive ServiceNow groups (active=false). Historical tickets assigned to these groups retain valid references.
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how Ivanti Neurons ITSM record types land in ServiceNow — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the Ivanti Neurons ITSM → ServiceNow field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If ServiceNow derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a ServiceNow equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its ServiceNow equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the ServiceNow sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to Ivanti Neurons ITSM. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against Ivanti Neurons ITSM. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
Ivanti Neurons ITSM → ServiceNow specifics
- Field-level spot checks
- Sample 2% to 5% of migrated records (minimum 50 records per object type). Verify that picklist values, date fields, reference fields, and free-text fields match the source. Sample across incidents, changes, problems, and service requests — not just one table. Pay special attention to sys_created_on values matching original Ivanti timestamps rather than showing the import date.
- Relationship integrity
- Run these specific queries in ServiceNow:
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in ServiceNow, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while Ivanti Neurons ITSM stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from ServiceNow's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze Ivanti Neurons ITSM and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep Ivanti Neurons ITSM read-only as the archive and rollback path.
-
Delete imported records by import set reference
Every record loaded through the Import Set API retains a reference to its sys_import_set row. Run a background script or scheduled job to delete all records in the target table where sys_import_set matches your migration import sets. Process deletions in reverse load order: attachments → journals → tickets → CI relationships → CIs → groups → users.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Remove migration configuration artifacts
If you built migration artifacts in a scoped app, delete the scoped app. This removes staging tables, transform maps, and migration scripts in one operation. If you used global scope (not recommended), manually delete each artifact.
-
Handle the case where agents have started working in ServiceNow
If agents created new tickets or updated migrated tickets in ServiceNow before rollback is triggered, those records will be lost on rollback. Mitigate this by keeping Ivanti active as a parallel system during the validation window and establishing a clear cutover decision point (e.g., "no rollback after agents have worked 100+ tickets in ServiceNow").
Ivanti Neurons ITSM → ServiceNow specifics
- Revert configuration changes via Update Sets
- If you modified ServiceNow dictionary entries, business rules, or system properties for the migration, capture those changes in a dedicated Update Set before migration. To rollback, back out the Update Set or apply a pre-migration baseline Update Set.
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile Ivanti Neurons ITSM and ServiceNow record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in ServiceNow, and formally retain the Ivanti Neurons ITSM archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
-
Record count reconciliation
Compare total record counts per object type between Ivanti and ServiceNow. Tolerance should be zero for Incidents, CIs, and Users. Break counts down by open vs. closed status, and by records with attachments and linked CIs.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
What is the Ivanti Neurons ServiceNow object mapping
| Ivanti Neurons ITSM field | ServiceNow field | Notes |
|---|---|---|
| Incidents | Incidents | Map state values carefully. ServiceNow uses numeric codes: 1=New, 2=In Progress, 3=On Hold, 6=Resolved, 7=Closed. Keep Ivanti RecId in a trace field. |
| Service Requests | Requested Items (RITMs) | Not 1-to-1. ServiceNow creates a parent request (sc_request) and one or more RITMs per catalog item. |
| Problems | Problems | Direct mapping. Watch for custom problem categories that need picklist translation. |
| Changes | Change Requests | Ivanti Change types must map to ServiceNow's Normal, Standard, or Emergency types. Rebuild planned dates, risk, approvals, and linked CIs explicitly. |
| Configuration Items | CMDB CIs | The hardest mapping. Ivanti CIs must be classified into the correct ServiceNow CI class. Load CIs before tickets. |
| Employees | Users | Ivanti uses RecId as primary key. ServiceNow uses sys_id. Build a crosswalk table. |
| Teams | Groups | Map Ivanti Team membership to sys_user_grmember records. |
| Notes / Journals | Journal Entries | Must be inserted as work_notes or comments on the parent record. Differentiate between customer-visible comments and internal work notes. |
| Attachments | Attachments | Use ServiceNow's dedicated Attachment API. REST payload limit defaults to 10MB. |
| Knowledge Articles | Knowledge Articles | Requires mapping to ServiceNow Knowledge Base and Category structures. |
| Approval Records | Approvals | Map Ivanti approval chain entries to ServiceNow approval records linked to the parent change or request. |
| SLA Records | Task SLA | Active SLA clocks cannot be migrated with accurate elapsed time. Historical SLA data can only be preserved as static fields. Recreate SLA definitions natively. |
| Catalog Categories | Catalog Categories | Map Ivanti service catalog structure to ServiceNow categories before loading RITMs. |
| Cost Centers | Cost Centers | Map before loading users if cost center is a required field on sys_user. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | medium | Core mapping is straightforward, but state values must be translated from Ivanti display strings to ServiceNow's numeric codes, and CI reference fields will be empty if CIs are not loaded first. |
| CMDB Configuration Items | high | Ivanti's flat CI data must be reclassified into ServiceNow's deep class hierarchy with explicit relationship records, making this the most complex and error-prone entity in the migration. |
| CI Relationships | high | Upstream/downstream dependency relationships must be rebuilt in ServiceNow's cmdb_rel_ci table, and any broken CI-to-incident or CI-to-change links will undermine operational value of the CMDB. |
| Service Requests | high | Ivanti's subscription-driven request model requires decomposition into ServiceNow's parent sc_request and child sc_req_item structure, with explicit handling of catalog variables and parameters to avoid data loss. |
| Users and Groups | low | User and group records map relatively cleanly between platforms, but a crosswalk table between Ivanti RecId and ServiceNow sys_id must be built first since these are foundational dependencies for all other records. |
| Journal Entries | medium | Notes must be correctly differentiated into work_notes versus customer-visible comments and inserted against the correct parent record sys_id, requiring the parent ticket to already exist in ServiceNow. |
| Change Requests | medium | Ivanti Change types must be mapped to ServiceNow's Normal, Standard, or Emergency classifications, and planned dates, risk assessments, approvals, and linked CIs must all be explicitly rebuilt. |
| SLA Records | high | Active SLA clocks cannot be migrated with accurate elapsed time; historical SLA data can only be preserved as static fields, and SLA definitions must be recreated natively in ServiceNow. |
| Attachments | low | Attachments can be migrated via ServiceNow's dedicated Attachment API, but the default 10MB REST payload limit may require chunked uploads for larger files. |
| Knowledge Articles | medium | Articles require mapping to ServiceNow's Knowledge Base and Category structures, which may differ significantly from Ivanti's knowledge organization and require content reformatting. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Incompatible Data Model Structures
Ivanti Neurons stores Incidents, Service Requests, Problems, and Changes as independent business objects with RecId primary keys, while ServiceNow inherits all task-type records from a single task table with a shared schema and type-specific extensions, requiring a fundamental structural remapping.
CMDB Reclassification Complexity
Ivanti's flat, endpoint-centric CMDB data must be classified into ServiceNow's deep class hierarchy (cmdb_ci and dozens of child tables) with explicit upstream/downstream relationship records in cmdb_rel_ci, making CI migration the hardest mapping in the project.
Strict Load Order Dependencies
ServiceNow's foreign key architecture requires records to be loaded in precise dependency order—users, then groups, then CIs, then tickets, then journals, then attachments—because loading out of order produces null reference fields that break workflows, reports, and SLA calculations.
Service Request Model Mismatch
Ivanti's subscription-and-parameter-driven service request model does not map 1-to-1 to ServiceNow, which generates a parent sc_request plus one or more sc_req_item records, requiring explicit redesign of the request hierarchy to avoid losing variable context.
Export and API Rate Limits
Ivanti Neurons imposes a 50,000-row Excel export cap and a 100,000 daily API call limit with a maximum of 100 records per OData request, making native extraction unviable for enterprise-scale datasets without complex batching strategies.
Timestamp and Picklist Transformation
Ivanti stores dates as Edm.DateTimeOffset and picklist values as display strings, while ServiceNow expects UTC-formatted timestamps and stores picklists as integers or sys_id references, requiring explicit conversion logic for every affected field to prevent data loss or rejection.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does an Ivanti Neurons to ServiceNow migration take?
Most migrations take 2 to 4 weeks from discovery through post-migration validation. The actual data transfer typically runs 1 to 3 days depending on record volume and API throughput constraints. Small datasets under 50,000 records can complete in a single weekend.
Can I migrate Ivanti Neurons to ServiceNow without losing CMDB data?
Yes, but only if you enforce strict load ordering: Users first, then CIs and CI relationships, then tickets, then journals and attachments. Loading tickets before CIs exist causes empty reference fields that are difficult to backfill without a custom script.
What is the biggest risk in an Ivanti Neurons to ServiceNow migration?
Broken CMDB relationships. Ivanti's flat CI model must be classified into ServiceNow's deep class hierarchy, and every CI-to-ticket link must resolve to a valid sys_id. Incorrect load ordering or failed CI classification causes cascading reference failures across incidents, changes, and service requests.
Is there a native Ivanti Neurons to ServiceNow migration tool?
No. Ivanti provides a ServiceNow connector that pulls data from ServiceNow into Ivanti Neurons. It does not support the reverse direction for a full ITSM migration. The migration must use API extraction, CSV export, or a third-party service.
Does migrating Ivanti Neurons to ServiceNow require downtime?
Not necessarily. A phased migration approach migrates historical data while both systems run, then performs a final delta sync of records created during the migration window. IT agents can continue working in Ivanti until the cutover.