Migrate from Fernand to Intercom

Fernand Conversations map directly to Intercom Conversations. We preserve status (open, resolved, archived), priority, assignee, and timestamps (created_at, updated_at) as conversation metadata in Intercom. Channel type (email or chat from Fernand's channel field) sets the Intercom conversation channel. Fernand's conversation ID is preserved as a custom attribute or linked via external_id for reconciliation after migration.

Fernand Replies thread inside Conversations and map to Intercom Conversation Parts. We preserve the full reply body, author (agent name and email), creation timestamp, and whether the reply was internal or external. AI-generated draft replies from Fernand are included as Conversation Parts visible to agents; the AI drafting configuration itself is not a migratable artifact.

Fernand Customers (contacts associated with conversations) map to Intercom Contacts. We export name, email, and any custom properties. Email address is the primary dedupe key. Before importing conversations into Intercom, all contacts must exist in Intercom because Intercom's API requires a contact reference for every conversation creation. We create contacts first, resolve the Intercom contact ID, then create conversations referencing that ID.

Fernand conversation tags map to Intercom Tags. We preserve all tag names and apply them as labels during conversation import. Tag counts and usage frequency carry over. Tags on individual conversations migrate as tag assignments on the corresponding Intercom conversation.

File attachments on Fernand conversations and Replies are downloaded and re-uploaded to Intercom as conversation attachments. Image attachments from the Fernand widget are included. We preserve original filenames and MIME types and attach them to the corresponding Intercom conversation at import time.

Fernand Custom Data stores API endpoint URLs, header names, and fetched payloads per conversation. We export the fetched payloads as static key-value conversation attributes in Intercom. The original endpoint configuration (URLs, auth headers, refresh logic) is Fernand-specific and cannot be replicated at Intercom without rebuilding the integration manually. We document the original configuration so the customer's team can rebuild the fetch logic in Intercom's workflow builder.

Fernand's GitHub integration links conversation threads to issues and can auto-reopen conversations when issue status changes. We export the linked GitHub issue URL and status as a static conversation attribute in Intercom. The live sync behavior does not transfer; conversations will not auto-reopen when GitHub issue state changes. We flag this as a manual rebuild item in the handoff documentation.

Fernand's Linear integration mirrors the GitHub pattern: conversations link to Linear issues and can track status changes. We export the Linear issue reference as a static conversation attribute. Issue state sync does not carry over because Intercom lacks the native Linear integration that drives this behavior in Fernand. This automation must be rebuilt using Intercom's workflow builder or a third-party integration.

Fernand supports email and chat channels per conversation. We export the channel type and map it to Intercom's conversation channel field. Email conversations in Fernand create email-channel conversations in Intercom with the customer copied as the message sender. Chat conversations in Fernand create messenger-channel conversations.

Fernand active users (those who can reply to customers) and passive users (collaborators) map to Intercom Teammates. We export user name, email, and active/passive status. Passive users without a destination seat equivalent are noted in the handoff for manual seat assignment. We resolve users by email match during the contact-first import phase.