Migrate from Kustomer to Intercom

Kustomer Customer records map directly to Intercom Contact. The primary match key is email address. We migrate standard fields (name, email, phone, social handles) and all custom properties as Intercom custom data attributes on the Contact. Kustomer's customer-avatar URL migrates as a custom attribute. Customer is created first as the parent dependency for all Conversation imports.

Kustomer Company records map to Intercom Company. Domain from Kustomer becomes the Company website field and is used as the dedupe key during import. Company is created before Contact import so that the company_id reference is satisfied at Contact insert time. If a Kustomer Customer has multiple linked Companies, we create all Companies first, then create Contact-Company associations during Contact import.

Kustomer Conversations map to Intercom Conversations with the conversation state (open, done, snoozed) preserved. We replay the full message sequence within each Conversation in original timestamp order, maintaining the agent-customer attribution and channel attribution. Kustomer's Conversation subject or title becomes the Intercom Conversation title field if populated; otherwise the first message body serves as the thread opener. Status is preserved as Open versus Closed.

Kustomer Messages (agent replies, customer messages, internal notes) map to Intercom Conversation Parts. Message type from Kustomer (message, note, activity, channelmessage) maps to the Intercom part_type (comment, note, activity, assignment). Author attribution (agent vs customer) is preserved. Attachments on messages are extracted, re-uploaded to Intercom, and relinked to the parent Conversation Part.

Kustomer Users map to Intercom Admins. Email address is the primary match key. We extract all agent profiles including display name, role, and avatar URL. The agent must be manually invited to the Intercom workspace by the customer's admin before migration day; we provide a reconciliation list of agents that need provisioning. Agent status (active vs inactive) is preserved as a custom attribute.

Kustomer Teams map to Intercom Teams. We extract team membership for every agent and recreate the team structure in Intercom during the pre-import configuration phase. Conversation assignment rules from Kustomer are documented for recreation in Intercom's routing and assignment workflows.

Tags applied across Kustomer Conversations and Customers migrate to Intercom Tags. Tag names are preserved verbatim. If the customer has more than 500 unique tags, we consolidate tags with fewer than 5 associated records into an 'imported-legacy' tag to avoid tag bloat in Intercom; this is a customer-approved decision made during scoping.

Kustomer's Channel model (email, phone, chat, SMS, social, and any custom channels) maps to Intercom's channel equivalents. We map Kustomer channel types to Intercom channel names (email, chat, sms, voice, whatsapp, facebook, twitter). Non-standard or app-added channels in Kustomer are flagged for the customer to decide whether to map to an Intercom channel or archive the channel association.

Kustomer's KObject schemas are user-defined with custom field types, relationships, and validation rules that have no direct Intercom equivalent. We perform a full schema audit of every KObject definition during discovery, document the field types and relationship graph, then recreate the schema as Intercom custom data attributes on the relevant Contact, Company, or Conversation object. KObject relationship hierarchies (parent-child Klasses) cannot be replicated in Intercom; we flatten them to a primary-linked attribute and note the original relationship for the customer's admin.

KObject records migrate as attribute values on the linked Contact, Company, or Conversation record in Intercom. We resolve the parent record reference (Customer or Conversation) at migration time and insert the attribute values after the parent record exists in Intercom. If a KObject has cross-references to other KObjects, we follow the flattened relationship and insert the linked record ID as a text attribute.

Kustomer Shortcuts do not migrate as reusable content because the field references and action logic are Kustomer-internal. We extract every Shortcut's name, content body, and available-for actions as a written inventory document. The customer's admin rebuilds Shortcuts as Intercom Saved Replies for static content or as Intercom Workflows for dynamic, trigger-based macros.

Kustomer routing rules and SLA policies are platform-specific workflow configurations that cannot be meaningfully migrated to Intercom's different automation model. We deliver a written inventory of every active routing rule and SLA policy with its trigger conditions, target team or agent assignment, time windows, and SLA breach actions. The customer's admin or an Intercom partner rebuilds these in Intercom's workflow builder post-migration.