Migrate from Ivanti Neurons for ITSM to Zendesk

Ivanti Neurons Incidents map directly to Zendesk Tickets. The source Status field (New, In Progress, On Hold, Resolved, Closed) maps to Zendesk Ticket Status (New, Open, Pending, Hold, Solved, Closed). Priority from Ivanti (Critical, High, Medium, Low) maps to Zendesk Priority. We preserve the original Incident ID in a custom ticket field ivanti_incident_id__c for audit traceability. Conversation threads (public comments and internal notes) migrate as Zendesk Comments with the public/agent distinction preserved. Parent-child linkage to Problems and related Changes migrates to Zendesk Linked Tickets or as custom ticket fields since Zendesk does not natively model Incident-Problem-Chain relationships.

Ivanti Service Requests map to Zendesk Tickets with Type set to 'task' or mapped to a custom ticket field request_type indicating a service request origin. Approval workflow status from Ivanti migrates as a custom field approval_status__c. The associated Cost Center and Financial Owner fields map to custom text fields on the Zendesk Ticket since Zendesk does not have a native financial metadata structure.

Ivanti Change Records carry structured risk assessment, CAB review process, and implementation schedule fields that have no Zendesk native equivalent. We map Change Records to Zendesk Tickets with Type = 'task' and create custom fields for risk_level__c, cab_approval_status__c, implementation_schedule__c, and affected_configuration_items__c (as a text list). For organizations with heavy change management governance, we recommend a separate Zendesk Views filter by Type='task' and a dedicated change queue to preserve the separation from operational incidents and service requests.

Ivanti Problem records link to root-cause Incidents and carry Known Error status. Zendesk has no native Problem object. We create a custom ticket field problem_record__c holding the original Ivanti Problem ID and known_error_status__c for known-error records, then link the associated Tickets via a tag prefixed problem_linked__. This preserves the audit trail and allows agents to filter tickets by known-error association without requiring a separate Zendesk add-on or custom object.

Ivanti Knowledge Articles with rich-text bodies, publication status, and usage statistics migrate to Zendesk Help Center articles via the Help Center Articles API. We chunk large article HTML bodies into Zendesk's API-acceptable payload size, map the Ivanti category and section structure to Zendesk Section and Category hierarchy, and preserve the article's attach_to_incident flag as a custom field or article label. Article-to-Incident linkage is re-established post-migration by tagging Zendesk tickets with the linked article's ID. Publication status (Draft, Published, Archived) maps directly to Zendesk draft vs. published states.

Ivanti Asset records (hardware, software, procurement metadata, Owner, Location, Cost) have no native Zendesk equivalent on standard plans. On Zendesk Suite Enterprise, the Asset Management add-on provides a direct asset record structure. On Team, Growth, and Professional, we map Ivanti Asset data to custom ticket fields on the Ticket (affected_asset__c, asset_tag__c, serial_number__c, location__c) and optionally create a Zendesk Organization custom record structure for asset inventory. Discovered assets via Ivanti Neurons discovery integration are out of scope for the standard migration run.

Ivanti Configuration Items form the CMDB backbone with relationship maps to other CIs, Assets, and Incidents. Zendesk has no CMDB or CI relationship graph. We export the CI relationship graph as a JSON reference file delivered alongside the migration and create custom fields ci_record__c, ci_relationships__c (as JSON or text), and ci_type__c on Zendesk Tickets to preserve the CI linkage. The customer can use this reference file to manually re-establish CI associations in Zendesk or integrate a dedicated CMDB add-on post-migration.

Ivanti Users and Employees map to Zendesk Users (agents and admins) and End Users (requesters). We extract the Employee record fields including organizational assignment and preferred language, then map agents to Zendesk Users and non-agent employees to End Users. LDAP and SSO configuration set in Ivanti must be independently re-established in Zendesk SAML or OAuth settings post-migration. We match records by email address as the dedupe key.

Ivanti Teams define service desk organizational units with queue routing rules and member assignments. Teams map directly to Zendesk Groups. We extract team membership (User records associated to each Team) and create corresponding Zendesk Group membership during the User migration phase. Queue-to-Incident routing rules from Ivanti do not have a Zendesk direct equivalent; we map them to Zendesk Views and, where applicable, to Triggers for automatic assignment.

Ivanti custom business object schemas exported via the Metadata API map to Zendesk custom fields on Ticket for standard plans, or to Zendesk Custom Objects on Suite Enterprise. We handle field-level type mapping (text, number, date, picklist, multi-select, reference) during schema translation. Complex custom object relationships that span multiple Ivanti tables are decomposed into normalized Zendesk custom field structures with a reference ID linkage preserved in JSON custom fields for audit.

Ivanti Tasks subordinate to Incidents, Service Requests, and Changes map to Zendesk Tasks attached to the parent Ticket. We preserve the parent-child relationship by setting the Zendesk Task's ticket_id reference to the migrated parent Ticket. Task naming conventions and custom fields from Ivanti migrate to Zendesk Task custom fields.

Ivanti file attachments associated with business objects migrate to Zendesk Ticket Comment attachments via the Zendesk Attachments API. Files over Zendesk's 20 MB API limit require separate handling through Zendesk's direct file upload workflow with post-migration linkage to the target ticket. Ivanti's 500 MB FTP upload path does not apply to Zendesk; we identify oversized attachments during pre-migration audit and handle them through a supplemental SFTP-to-Zendesk upload pipeline.