Migrate from Seraph to Intercom

Seraph contact records map to Intercom Contact (internally a Contact in the People model). We require at minimum an email address or user_id from Seraph to create the Intercom contact. Custom properties on the Seraph contact profile map to Intercom custom attributes on the Contact, which must be pre-created in Intercom's People Data settings before the contact import phase begins. Any Seraph contact without a resolvable email or user_id is held in a reconciliation queue for the customer's admin to resolve.

Seraph company or organization records map to Intercom Company. The Seraph company domain field maps to the Company website, which Intercom uses for company name resolution and domain-based merging. Company is created before any Contact import so that the Company-Contact lookup relationship is satisfied at the moment of Contact insert. Multiple Seraph companies with the same domain merge automatically in Intercom unless domain-merging is disabled in workspace settings.

Seraph ticket or conversation records map to Intercom Conversation (with the ticket model as an optional abstraction). The Seraph channel field (email, chat, phone, social) becomes the Intercom channel metadata stored as a custom attribute or conversation attribute. The opening customer message becomes the first part of the Intercom conversation. All subsequent replies and internal notes from Seraph agents become additional parts in Intercom, with internal notes stored as part_type=note and customer replies as part_type=user. We preserve created_at and updated_at timestamps from Seraph on the Intercom conversation metadata.

Seraph message entries within a ticket map to Intercom conversation parts. We import the full transcript as a single outbound reply to simulate an inbound message from the customer, which is Intercom's recommended approach for visibility in the Messenger. Each part preserves its original author (agent or customer), timestamp, and content body. Attachment URLs from Seraph are reattached directly in Intercom rather than kept as external links.

Seraph agent or user records map to Intercom Admin. We resolve by email address match against the destination Intercom workspace's admin list. Any Seraph agent without a matching Intercom admin goes to a reconciliation queue for the customer to provision before migration continues. Agents who are inactive in Seraph but have historical assignments map to Intercom Admins set to inactive or Lite seat status on Advanced and Expert plans.

Seraph team or group records map directly to Intercom Team. Team names and membership are preserved. In Intercom, conversations can be assigned to a Team and a specific Admin simultaneously, which provides persistent context for routing and reporting. We recommend configuring this assignment model during the Intercom workspace setup phase before migration begins.

Seraph custom fields on contacts and conversations map to Intercom custom attributes, which must be created in Intercom's People Data and Conversation Data settings before the migration of the associated records begins. We support checkbox, date, number, text, and dropdown types. Multi-value Seraph fields (arrays of values per record) require Intercom custom data attributes rather than standard custom attributes to handle one-to-many value relationships correctly.

Seraph tags on tickets and conversations migrate to Intercom Tags at the conversation level. Tags used for routing, priority, or category are preserved as Intercom tags for segmentation and reporting. Tags that represented SLA state in Seraph are mapped to custom attributes rather than tags since Intercom's SLA functionality is a separate configuration post-migration.

Seraph ticket attachments and inline images migrate as Intercom conversation attachments, reattached directly in Intercom rather than stored as external URLs. This follows Intercom's documented migration approach where attachments must be re-uploaded to Intercom's storage to remain accessible within the platform after cutover. Attachments are imported after all conversation records exist in Intercom to avoid orphaned references.

Seraph macros or saved replies do not migrate directly to Intercom because the trigger and action model differs between platforms. We deliver a written inventory of every Seraph macro with its name, conditions, and body content for the customer's admin to recreate in Intercom's saved replies and Rules engine post-migration. Macros are out of scope for API-level migration due to the structural difference in automation models.

Seraph SLA policies (first response time, next response time, resolution time targets) do not migrate as code to Intercom because Intercom's SLA configuration is a separate workspace-level setup. We document every Seraph SLA policy including its name, targets, business hours setting, and applicable ticket filters so the customer's admin can recreate them in Intercom's SLA settings post-migration.