Migrate from Ivanti Neurons for ITSM to Salesforce Service Cloud

SLA targets do not migrate — Entitlement and Milestone must be rebuilt

Ivanti stores SLA target definitions as fields on Incident and Service Request records (such as First Response Target Hours and Resolution Target Hours) and also maintains separate SLA business objects for complex entitlement setups. Salesforce Service Cloud implements SLA time-tracking through Entitlement records linked to Cases via the EntitlementId field, combined with MilestoneType definitions that specify which milestones apply to which Case record types and the associated time triggers. There is no direct field-to-field map between Ivanti's SLA target values and Salesforce's Entitlement model. FlitStack exports the SLA configuration as a structured reference document (JSON export of Ivanti SLA business objects with field names, operators, and target values) that a Salesforce admin can use to recreate Entitlement Processes and Milestone Types in Salesforce. The actual time-tracking does not carry over — the clock starts from the moment the Case is inserted in Salesforce.

Assignment Groups require Salesforce Queues pre-created before migration

Ivanti Assignment Groups are the primary routing mechanism for incidents and service requests. When an incident is assigned to a group, the group's queue of agents receives the work. Salesforce uses a separate Queue object for this purpose, and every unique Ivanti Assignment Group name must map to a Salesforce Queue that is created and populated with the correct User members before records are inserted. If a Queue does not exist when FlitStack attempts to set OwnerId, the record insert fails. FlitStack generates a queue-creation script from the Ivanti Assignment Group roster during the planning phase, but the actual Queue creation in Salesforce must be performed by a Salesforce admin with the appropriate permissions. Unresolved Assignment Groups (groups deleted or renamed in Ivanti) are flagged and default to a fallback owner.

Ivanti's 100,000 API calls/day rate limit may throttle large exports

Ivanti Neurons for ITSM enforces a per-tenant rate limit of 100,000 API calls per 24-hour rolling window. For migrations exceeding approximately 50,000 total records across Incidents, Service Requests, Problems, Changes, Assets, and custom objects, FlitStack's export job may approach or exceed this limit depending on the number of API calls required per record (relationship lookups, attachment downloads, and metadata fetches all count against the limit). If the rate limit is encountered, FlitStack pauses the export job, waits for the rolling window to reset, and resumes. This extends migration timelines. FlitStack mitigates by batching reads efficiently and caching metadata responses, but organizations with very large Ivanti tenants should plan for a multi-day export window or explore Ivanti's database export alternative.

Custom business objects require Salesforce schema pre-creation

Ivanti's REST API exposes all customer-defined business objects alongside the standard objects. These custom business objects often contain fields that are critical to the organization's service process — such as regulatory compliance flags, service credit tracking, or project codes. Salesforce requires custom objects to be explicitly created with the __c suffix before data can be inserted via the API. FlitStack reads the Ivanti Metadata API to enumerate all custom business objects and their field schemas, then generates a Salesforce schema-creation plan (object names, field names, data types, pick-list values) that a Salesforce admin must execute in the target org before the migration data runs. Custom object creation is a separate step from data migration and cannot be performed by FlitStack automatically because it requires Salesforce UI or Tooling API access that is org-specific.

Knowledge articles migrate as data only — article structure must be rebuilt

Ivanti Knowledge Articles are published records with article type, title, summary, body content, and metadata such as article ID and last-modified timestamp. Salesforce Knowledge uses a structured article model with ArticleType (which defines the available fields per article category), KnowledgeArticleVersion (the published record), and a publishing workflow (draft, review, published states). Migrating Ivanti article content directly into Salesforce Knowledge requires the ArticleType schema to already exist, and the content lands as draft records that still need to go through Salesforce's publishing workflow. Additionally, Salesforce Knowledge URL names are system-generated and cannot be set to match Ivanti article IDs. FlitStack exports Ivanti article content to a custom Knowledge_Reference__c object where the full article body is stored as a long-text field, preserving the content for reference. The Salesforce admin must rebuild the article structure and republish using Salesforce's native Knowledge authoring tools.