Migrate from Fluent Support to Intercom

Fluent Support Tickets map to Intercom Conversations with an attached Ticket entity for structured case management. The source ticket title and content become the initial conversation message. We preserve source ticket status (open, pending, closed, archived) as an Intercom conversation state and ticket status value. Priority levels (normal, high, low) map to Intercom Ticket priority attributes with configurable value translation.

Each Fluent Support Conversation entry maps to an Intercom conversation_part record with author attribution (agent vs customer), timestamp, and message content preserved. Message-by-message migration provides the highest historical fidelity but inflates API calls 10-100x per ticket compared to a flat-ticket migration. We confirm the fidelity-versus-cost preference during scoping and note that Intercom recommends flat-ticket migration for teams that need data primarily for reporting consistency rather than per-message context.

Fluent Support Customer records (WordPress users with support profile data) map to Intercom Contacts. The WordPress user ID becomes a custom contact attribute rather than a primary identifier. Email address serves as the primary dedupe key. Contact privacy settings from Fluent Support migrate as HasOptedOutOfEmail flags. Any customer timezone, language, or custom profile data maps to Intercom custom attributes.

Fluent Support Agents (WordPress users with support roles) map to Intercom Teammates. We resolve agents by email match against the destination Intercom workspace. If a source Agent has no matching Intercom Teammate account, we flag them for provisioning before migration. Team assignment in Fluent Support maps to Intercom Team structure, which drives inbox routing and SLA assignment.

Fluent Support Mailboxes define incoming channel sources tied to the WordPress site's domain and email routing. Mailbox associations carry mailbox_id values that reference the specific WordPress environment and are not portable across environments. We flag every Mailbox association during discovery, document what each maps to in Intercom (typically a specific Inbox or shared inbox), and flag email routing rules (reply-to addresses, POP/IMAP inbox mappings) as requiring manual reconfiguration post-migration.

Fluent Support custom field definitions and their per-ticket values migrate to Intercom custom attributes on the Contact or conversation. Field types (text, dropdown, checkbox, date) map to equivalent Intercom attribute types. Conditional visibility logic (show field B only if field A equals value X) does not export as structured rules because Fluent Support stores this as UI preferences rather than portable configuration. We deliver a custom field inventory worksheet listing field names, types, and conditional logic so the admin can rebuild visibility conditions in Intercom.

Fluent Support Tickets tagged to a Product carry a product_id and product_source referencing a specific WordPress plugin (e.g., Fluent Forms). These source references are not portable. We extract product_id values and product names, map them to Intercom custom data attributes on the Contact, and flag which Intercom Inbox or routing rule should handle each product context post-migration.

Fluent Support tags on tickets and customers migrate to Intercom tags as flat key-value labels. Tags are preserved as-is without conditional logic. We map tags at the conversation level for routing context and at the contact level for segmentation.

Ticket priority fields (priority and client_priority) with values like normal, high, or low map directly to Intercom Ticket priority values (urgent, high, medium, low, none). We apply a configurable value translation table if the destination uses a different priority vocabulary than the source.

Files attached to Fluent Support tickets and conversations are stored in the WordPress media library or plugin-specific upload directories. We extract attachment URLs and file metadata, download files to a staging environment, and re-upload them to Intercom as conversation attachments. We flag the file type restriction: Intercom blocks .exe, .sys, .scr, .shb, .wsf, and other potentially malicious file types. If the source contains blocked types, we document which files require manual delivery post-migration.

Fluent Support Workflows are defined through a UI builder with triggers and conditions stored as UI preferences rather than structured JSON or YAML. We catalog every active workflow by name, trigger type, and action sequence during discovery and deliver a written inventory with a recommended Intercom Rules equivalent for each. The admin rebuilds rules in Intercom's Rules engine post-migration. We do not migrate workflows as executable code.

Fluent Support reports (Resolve Stats, Response Stats, Ticket Stats) are computed dynamically from ticket data at query time and are not stored as discrete database rows. They cannot be migrated as objects. We recommend exporting key report screenshots and data snapshots before migration and rebuilding the reporting cadence in Intercom's native analytics and SLA reporting tools after cutover.