Migrate from Service to Intercom

Each source ticket becomes one Intercom conversation. The conversation subject is mapped from the ticket title or first comment body. The conversation state (open, closed, snoozed) is translated from ticket status using value mapping rules. All subsequent comments become conversation_parts in strict chronological order using the original created_at timestamp from each comment record.

Source contacts with email addresses map directly to Intercom contacts of type 'user'. Email is the required identifier. Contacts without email (e.g., anonymous users in the source) land as Intercom leads. We preserve the source contact ID in Source_System_ID__c on the Intercom contact for delta-run deduplication.

Source companies map 1:1 to Intercom companies using domain as the matching key. If a contact's email domain matches an existing Intercom company, we link them via the company_id field. Multi-company associations on a single contact collapse to the primary company with additional domains preserved as custom attributes.

Internal notes from the source ticket do not appear as public messages in Intercom. We map them to conversation_parts with part_type set to 'note' and body containing the note content. The original author (agent) is mapped to the Intercom admin_id; the timestamp is preserved as created_at on the part. Internal notes that mention other agents via @mentions are stored as plain text within the note body.

Public comments from both the customer and the agent become Intercom conversation_parts of type 'comment'. The author_type field is set to 'user' for customer messages and 'admin' for agent messages. HTML-formatted comments are stripped to plain text unless Intercom's allowed HTML subset is used.

Source ticket custom fields require pre-created custom attributes in the Intercom workspace before migration runs. We generate the attribute manifest (name, type, options) during the discovery phase. For pick-list fields, the options array is mapped value-by-value. Date, number, and boolean fields map directly to their Intercom equivalents. Text fields with >255 characters are truncated with a note flag if the source value exceeded Intercom's limit.

Intercom has no native SLA policy object. Source SLA policies and breach timestamps are migrated as custom attributes on conversations (SLA_Policy_Name__c, SLA_Breach_Time__c, SLA_Responded_At__c). SLA-aware escalation can be rebuilt in Intercom using workflow timeouts that trigger reassignment or priority escalation. We export the full SLA definition as a JSON reference file.

Source attachments are downloaded from the source storage URL and re-uploaded to Intercom's file CDN using the Conversations API attachments endpoint. Original file metadata (name, size, content_type, original URL) is preserved in custom attributes on the conversation so auditors can trace the original source. Inline images in notes are extracted, re-hosted, and the note body is updated with the new Intercom CDN URL.

Source agents are resolved against Intercom admins by email address. Matched agents have their source ID stored in Original_Agent_ID__c for audit trail. Agents in the source with no corresponding Intercom admin account are flagged before migration; their records are assigned to a fallback admin so no conversation lands unassigned.

Source ticket tags map directly to Intercom conversation tags. Tags are applied via the /conversations/{id}/tags endpoint after the conversation is created. Tag names are preserved as-is; if a tag exceeds Intercom's 50-character limit, it is truncated and flagged in the migration report.

Workflows, automation rules, escalation paths, and SLA triggers do not have equivalents in Intercom's data model and cannot be migrated as structured data. We export the workflow definitions as a JSON object describing triggers, conditions, and actions so your Intercom admin can rebuild them in Intercom's Workflow Builder. Macros and saved replies are exported separately and provided as a rebuild reference.

If the source platform records CSAT ratings on closed tickets, we map them to Intercom conversation_parts with type 'rating'. The score (1–5 or positive/negative) and optional free-text comment are preserved. Intercom's native CSAT widget generates ratings on new conversations post-migration; historical ratings from the source are stored as part history so the full timeline is visible in the conversation view.