Migrate from iService to Intercom

iService Tickets map to Intercom Conversations. Each iService ticket ID becomes a reference stored in a custom attribute iservice_ticket_id__c on the Intercom Conversation for audit traceability. The iService ticket status (open, pending, resolved, closed) maps to Intercom's open, snoozed, or closed state. Priority from iService migrates to an Intercom conversation priority attribute. Custom ticket fields from iService map to Intercom custom conversation attributes (custom_attributes on the conversation object), with field type conversion applied: dropdown becomes single-select string, multi-select becomes comma-separated string, date fields use ISO 8601 format.

iService Conversation messages inside each Ticket map to Intercom Conversation Parts. Each message body, timestamp, and author (agent or customer) transfers to the Conversation Part structure. We preserve the original message author email and name as intercom_author_name and intercom_author_email attributes on the part for reconciliation. HTML-formatted message bodies are sanitized to plain text or markdown depending on whether the customer chooses a rich-text or plaintext Intercom inbox.

iService Customer records map to Intercom Contacts. Email, name, phone, and any custom contact properties transfer. The iService customer ID is stored in a custom attribute iservice_customer_id__c on the Intercom Contact. Custom properties on iService customers map to Intercom contact custom attributes with type conversion. We resolve the lookup between iService customers and their associated Companies during import so that each Contact has the correct company_id in Intercom.

iService Company records map directly to Intercom Companies. Company name, domain, and custom company properties transfer. The iService company ID is stored in iservice_company_id__c on the Intercom Company. We pre-create all Companies before importing Contacts so that the Intercom company_id relationship is satisfied at Contact insert time. Company-level custom properties map to Intercom company custom attributes with equivalent type handling.

iService Live Chat Sessions map to Intercom Conversations with type = chat. We flag chat sources during the data audit phase because iService chat sessions from the embedded portal widget and from integrated third-party channels may have different transcript formats. Portal-originated chats typically have complete transcript history; third-party integrated chats may have metadata only without full message history. We document which chats have full transcripts versus partial metadata during scoping and migrate what is available, noting any gaps in the reconciliation report.

iService KB Articles migrate to Intercom Articles within Collections. Article content exports as HTML or markdown from iService and imports into Intercom's article editor format. We map iService KB categories to Intercom Collections, preserving the hierarchy where it exists. Article attachments migrate as files attached to the article in Intercom. Portal visibility settings from iService (public, authenticated, restricted) do not have a direct Intercom equivalent; we default migrated articles to published status and the customer's admin sets article access permissions in Intercom after migration.

iService KB categories map to Intercom article Collections. We preserve category names and any parent-child hierarchy as nested Collection structures in Intercom. If iService categories have visibility rules (public, internal-only), we document these for the customer's admin to configure in Intercom's article settings post-migration.

iService custom ticket fields vary by tenant configuration. We audit every distinct custom field name and data type during scoping. Each custom field maps to an Intercom custom attribute on the Conversation (if the field is ticket-specific) or on the Contact (if the field is customer-specific). We create the destination custom attribute schema in Intercom before migration begins. Multi-select fields from iService become comma-separated strings in Intercom; date fields use ISO 8601; boolean fields map to true/false strings.

iService Agent accounts (email, name, role, team assignment) map to Intercom Teammates. We match agents by email address against the Intercom workspace's user table. If an iService agent does not have a corresponding Intercom Teammate, they go to a reconciliation queue for the customer's admin to provision before ticket import begins, because agent assignment on conversations requires a valid Intercom teammate_id.

iService Tags migrate to Intercom Tags. Tags attached to tickets become tags on the corresponding Intercom Conversation. Tags on KB articles become tags on the corresponding Intercom Article. We preserve tag names exactly and remap the tag associations to the parent object. If the same tag name exists in Intercom from a prior import, we merge rather than duplicate.

File attachments on iService tickets migrate as Intercom conversation attachments. We preserve the original filename and link each attachment to the correct conversation in Intercom. Attachments are uploaded as blobs and attached via the Intercom Attachments API to the relevant conversation part. Attachment files larger than 10 MB are flagged during scoping because Intercom's attachment size limit requires chunked handling.