Migrate from Front to Intercom

Front Conversations are the primary migration unit. Each Front Conversation (including all message segments, channel attribution, assignee, status, Inbox, and timestamps) maps to an Intercom Conversation or Ticket. We flatten message segments into a single thread body in the first Intercom comment, preserving author, timestamp, and content for each segment in sequence. The channel source (email, chat, SMS) is stored as a custom conversation attribute since Intercom represents channel in the conversation object type rather than as a separate channel object. Front's conversation state (open, snoozed, archived) maps to Intercom's open, closed state with custom attributes carrying snooze dates.

Front Contacts map directly to Intercom Contacts by email. We export name, email, phone, company, custom properties, and contact handles across channels. Front contact handles (social handles, in-app usernames) that are not email addresses require a custom data attribute in Intercom since Intercom Contacts require at minimum an email or user_id for identification. Linked Front Company records map to Intercom Companies and are linked via the contact-to-company association. We resolve the Company reference before importing Contacts so that the association is established at insert time.

Front Teammates map to Intercom Admins by email match. We export name, email, role, and assignment preferences. Custom role names from Front (Team Lead, Support Manager, Escalation) may require mapping to Intercom's admin roles or custom role permissions in Intercom's Admin permissions panel. Any Teammate referenced on a Conversation that has not yet been provisioned as an Intercom Admin is held in a reconciliation queue; we cannot assign conversations to Admins that do not yet exist in Intercom.

Front Inboxes define which channels land where and which Teammates have access. We map each Front Inbox to an Intercom Team, preserving the Inbox name as the Team name. Complex permission inheritance across Inboxes (Inbox A accessible to Team X plus individual agents from Team Y) requires manual post-migration configuration in Intercom because Intercom's team inbox model handles agent-to-team membership differently. We document the access matrix during discovery so the customer's Intercom admin can replicate the assignment logic.

Front Tags applied at conversation level migrate as flat labels into Intercom Tags. We export the full tag list and map each tag by name to an equivalent Intercom tag. Tag hierarchy and tag-group organization from Front (tags grouped under categories for taxonomy) do not carry over as structured groupings in Intercom; they become a flat list. The customer chooses during scoping whether to maintain tag hierarchy by encoding it into tag naming conventions (e.g., product-bugs-severity-high) or to treat it as informational content for manual reorganization.

Each message within a Front Conversation is a distinct segment with author, timestamp, body, and optional attachment references. When importing into Intercom, we write the first message segment as the initial conversation body and append subsequent segments as part records ordered by timestamp. Author attribution is preserved by linking each Intercom part to the Admin or Contact who authored it. Note that internal Front comments (visible only to teammates) do not have a direct Intercom equivalent; we write them as internal notes in Intercom so they remain teammate-only.

Front Channels (email, chat, SMS, social) represent the communication source. Intercom does not have a separate Channel object; channel is a property on the conversation itself. We store the original Front channel as a custom data attribute on each migrated Intercom conversation (e.g., channel_source: email, channel_source: chat). Starter-plan customers on a single channel have all conversations attributed to one channel; Starter customers who used multiple channels will have gaps corresponding to channels they were not permitted to use on their plan.

Front supports custom fields on Conversations. We export custom field definitions and values and map them to Intercom conversation data attributes. Intercom supports text, number, date, boolean, and list attribute types. When Front uses a field type that Intercom does not support (e.g., Front's structured JSON field), we store the value as a text string. Character limits and type coercion are surfaced during the pre-migration field comparison review. We do not create custom data attributes in Intercom automatically — the customer approves the attribute creation list during scoping.

Front Contacts support custom properties that map to Intercom Contact custom attributes. We export the full contact property schema, excluding Front system properties (created_at, updated_at, _links). Mapping requires a pre-migration type comparison because Intercom's custom attribute types (string, int, float, date, boolean, list, currency) do not all match Front's property types one-to-one. Truncation risk exists for long-text Front properties imported into Intercom string fields with character limits.

Notes attached to Front Conversations or Contacts export with text content and attribution (author, timestamp). We import them into Intercom as internal note parts on the relevant Conversation, preserving author and timestamp. Notes that are attached only to a Contact (not tied to a Conversation) are written as internal notes on the Contact timeline in Intercom. Notes from Front are not visible to customers in Intercom by default, matching Front's teammate-only note behavior.

Front Automation Rules are event-condition-action triggers with conditional logic, delays, and multi-step actions that are not exposed in the Front API as reusable templates. We export every active Rule during discovery with its full configuration (trigger event, conditions, actions, and delay steps) and deliver a written inventory document specifying the Intercom Workflow equivalent for each Rule. The customer's Intercom admin rebuilds the Rules in Intercom's Workflow builder post-migration. This is manual work outside the data migration scope.

Front Workflows are multi-step process automations distinct from simple Rules, often involving branching logic, condition nodes, and multi-step sequences. We export the Workflow structure (step types, connections, condition branches) as a written specification document. Rebuilding in Intercom requires recreating the logic in Intercom's Workflow builder, which uses a different node-based model. Workflows with complex branching may require simplification or redesign in Intercom. This is outside standard data migration scope.