Migrate from Ivanti Neurons for ITSM to Intercom

Ivanti Neurons for ITSM Incidents map to Intercom Conversations. The Incident title becomes the Conversation subject, and the full analyst-and-customer message thread migrates as individual Message records with author, timestamp, and body preserved. Ivanti's internal analyst notes are imported as internal Intercom notes attached to the Conversation. We use the Intercom Conversations API with batch message insertion, and resolve the Incident's Owner to an Intercom Admin by email match. Closed Incident status maps to a closed Conversation state.

Service Requests in Ivanti Neurons for ITSM map to Intercom Conversations using the same pattern as Incidents. The request title becomes Conversation subject; request details and fulfillment messages become Message records. Approval workflow status and Cost Center fields from Ivanti do not have Intercom equivalents and are preserved as custom Conversation attributes during migration. The customer decides post-migration whether to maintain these attributes manually or close them out.

Change Records carry structured risk assessment, CAB review process, and implementation schedule that have no native Intercom equivalent. We do not migrate Change Records as full records. We create a single Intercom Conversation per active or recently closed Change Record with a summary of the change, its risk level, CAB approval status, and implementation timeline as an opening Message. Historical Change Records are excluded from migration scope. The customer receives a Change Record inventory document listing all excluded records for their records.

Ivanti Problem records carry root-cause Incidents and Known Error status that do not map to Intercom's conversation model. We do not migrate Problem records. We create a summary Conversation for each Problem-Incident linkage graph that documents the known error, its related Incidents, and resolution status. The Problem-Incident linkage graph is preserved as a Message attachment in structured text format. Customers needing full problem management should retain a separate CMDB or continue using a complementary ITSM tool.

Ivanti Neurons for ITSM User and Employee records map to Intercom Contacts. Employee full name becomes Contact name, email becomes Contact email, organizational assignment becomes a Contact attribute, and preferred language maps to Contact language. We resolve contacts by email as the dedupe key. Any Ivanti Employee without an email address is imported as a Contact with a placeholder email and flagged for manual enrichment. SSO and LDAP configuration is not migrated; Intercom identity management is configured separately by the customer's admin.

Ivanti Neurons for ITSM supports Account linking on Incidents and Service Requests. If the tenant uses the Account relationship, we migrate Account records to Intercom Company records with company name, industry, and size preserved as Company attributes. Company-Contact linkage migrates as Intercom Contact-Company relationships. If Ivanti Account data is sparse or unused, we skip Company migration and rely on Contact-only records in Intercom.

Ivanti Knowledge Articles with rich HTML bodies, publication status, and usage statistics map to Intercom Articles within Collections. We export full article HTML content and map it to Intercom's article body format. Publication status (Draft, Published, Archived) maps to Intercom's draft and published states. Article author and last-modified date migrate as article metadata. Large articles exceeding Intercom's article size limits are chunked into segments with cross-links preserved. Article-to-Incident linkage is not migratable and is documented as a manual post-migration task.

Ivanti Knowledge Article categories and section hierarchies map to Intercom Collections and Sections. We extract the category structure during scoping and create equivalent Collections in Intercom before article migration begins. The Collection-Article relationship is preserved by resolving each article to its parent Collection during the import phase.

Ivanti Neurons for ITSM Teams with queue routing rules map to Intercom Teams. Team name and member list migrate, with each Ivanti team member matched to an Intercom Admin by email. Ivanti's queue-based routing rules (which assign Incidents to teams based on category or priority) do not have a direct Intercom equivalent; we document the routing logic in a written handoff and the customer's admin rebuilds routing using Intercom Rules and Inbox assignment post-migration.

File attachments on Ivanti Incidents and Service Requests migrate as Intercom Conversation attachments. We export file binaries and metadata via the Ivanti Attachment API, then upload each file to Intercom's file attachment endpoint linked to the target Conversation. Files over 250 MB exceed Intercom's attachment limit and require direct SFTP upload with post-migration linkage; we identify oversized attachments during pre-migration audit and handle them separately. Large attachment batches are chunked to stay within Intercom's upload rate limits.

Ivanti Tasks subordinate to Incidents and Service Requests (for example, sub-investigation steps or follow-up items) map to Intercom internal notes on the parent Conversation. Task subject, due date, and completion status migrate as note content. Standalone Tasks without a parent Incident are imported as individual Conversations with a summary message noting the original Ivanti Task metadata. Tasks are not first-class objects in Intercom; this mapping preserves the task content within the conversation context rather than as independent records.

Ivanti Neurons for ITSM custom business objects with customer-defined schemas migrate as custom attributes on Intercom Conversations. We export the custom object schema via the Ivanti Metadata API, then create equivalent custom attribute definitions in Intercom. Complex custom object relationships (parent-child lookups, multi-level hierarchies) are flattened into string or JSON attributes because Intercom's data model does not support relational custom objects. Schema mapping is validated in a staging pass before production migration.