Migrate from ServiceNow IT Service Management to Intercom

ServiceNow Incidents map to Intercom Conversations. The Incident number becomes the conversation ID reference, state (New, Active, On Hold, Resolved, Closed) maps to Intercom conversation state (open, closed, snoozed), priority maps to a custom priority attribute on the conversation, and assignment_group maps to an Intercom Team or Admin assignment via the conversation's assignee field. Child tasks under an Incident map to internal Conversation Parts. We do not preserve SLA breach timers; these require manual configuration in Intercom's SLA rules on Pro and Expert plans.

ServiceNow User records (fulfillers and requesters) map to Intercom Users. Active users with email addresses map directly; we preserve department, location, and manager as custom User attributes. Inactive ServiceNow users are flagged for the customer's admin to review before import. User type distinction (Fulfiller vs. Requester) does not map to an Intercom concept; all migrated users become contacts in Intercom, and the customer decides agent vs. contact classification during Intercom setup.

ServiceNow Assignment Groups map to Intercom Teams. We export group name, group type, and group manager and reconstruct these as Intercom Teams during migration. Group membership (which users belong to which assignment group) is preserved as a custom attribute on each migrated User rather than as a native Intercom Team membership object, because Intercom Teams are inbox routing labels rather than membership lists.

ServiceNow Knowledge Articles map to Intercom Articles. Article text, metadata, and workflow state (active/retired) migrate. Article approval workflows and version history are not migrated; retired articles are flagged as draft in Intercom. Category hierarchies from ServiceNow map to Intercom Article Collections and Sections, but the hierarchy depth may require flattening during migration.

ServiceNow Service Catalog Items with custom variables map to Intercom Products (for item-tracked products) or to Articles (for procedure-based requests). Variable set definitions from ServiceNow require field-level mapping; we inventory all custom variables during discovery and provide a mapping table. Variable-set logic (conditional display, mandatory rules) is not migratable to Intercom and is documented for the admin to rebuild.

ServiceNow Problems have no native Intercom equivalent. We migrate Problem records as Conversations tagged with a 'Problem-KB' label and preserve the problem-incident linkage in a custom conversation attribute referencing the linked Incident number. The problem manager assignment and known error body migrate as internal Conversation Parts. The customer decides whether to treat Problems as Conversations in Intercom or as a separate maintained document.

Change Requests are ITIL artifacts with no Intercom equivalent. We export Change Request records (with risk assessment, approval status, CAB approver list, implementation schedule, and related tasks) as a structured CSV inventory delivered alongside migration. The customer uses this inventory to rebuild change tracking as an external process or as custom fields on the relevant Service Catalog Item in Intercom if change tracking is required.

Configuration Items from the CMDB map to Intercom Products if they represent software or hardware assets tracked by the support team, or to a structured custom attribute export attached to the relevant User or Conversation. CI parent-child relationships and dependency maps are preserved as a relationship table in the export; Intercom does not have a native CMDB, so dependency graphs require an external tool or a rebuild in a dedicated CMDB if required. We flag this gap during scoping.

File attachments on Incidents and Knowledge Articles migrate as file attachments on the relevant Intercom Conversation Parts or Articles. Large attachment volumes require chunked export from ServiceNow's table API and storage consideration; we flag attachments exceeding 10 MB per file for the customer to assess whether they belong in Intercom or in a separate document store.

ServiceNow instance-specific custom fields on Incidents, Problems, or Change Requests are inventoried during discovery and mapped to Intercom custom attributes on the corresponding object (User, Conversation, or Article). Custom field type mapping follows: string to text, choice to dropdown, reference to text (as no lookup relationship exists in Intercom), and boolean to yes/no. We document every unmapped custom field that has no Intercom destination.

ServiceNow SLA records reference business-hour calendars and breach actions. Calendar definitions do not map 1:1 to Intercom SLA definitions, which support only first-response and resolution time metrics. We flag calendar mismatches during mapping and document the SLA breach threshold as an Intercom SLA rule for the customer's admin to configure. SLA breach history (existing breached records) does not migrate; these are historical audit events.