Migrate from Fluent Support to Zendesk

Fluent Support Tickets (fs_tickets) map to Zendesk Tickets. The fs_tickets fields title, content, priority, status, customer_id, agent_id, mailbox_id, and product_id translate to Zendesk subject, description, priority, status, requester_id, assignee_id, via_channel, and custom fields. We preserve the original ticket_id in a custom field fluentsupport_ticket_id__c for audit. Status values (open, pending, resolved, closed) map to Zendesk ticket_status with a value translation table agreed during scoping.

Fluent Support conversation entries from fs_conversations map to Zendesk Ticket Comments. Each conversation row carries conversation_type (note vs reply), created_by (agent or customer), and the message content with timestamp. We create Zendesk public comments for customer-facing replies and private comments for agent internal notes, setting the comment author to the migrated Zendesk user record. Conversation ordering is preserved by setting the Zendesk comment timestamp to the original Fluent Support created_at.

Fluent Support Customer records are WordPress users with profile data (email, name, phone, address). We map each WordPress user to a Zendesk end-user via email match, creating the Zendesk User record with the name and email fields from fs_customers. If a WordPress user has multiple roles (customer plus agent), we create separate end-user and agent records in Zendesk rather than a single user with both roles.

Fluent Support Agents are WordPress users with support-role assignments. We map each source Agent to a Zendesk agent account, preserving the agent's role type (admin, agent) as a Zendesk custom field fluentsupport_role__c. Fluent Support agent groups map to Zendesk Groups, and we assign migrated agents to the corresponding Zendesk Group based on the source agent's group membership in fs_agent_roles.

Fluent Support conditional custom fields (text, dropdown, checkbox, date, number, file upload) map to Zendesk custom_field definitions. Field types translate: Fluent Support text to Zendesk text, dropdown to Zendesk tagger, checkbox to Zendesk boolean, date to Zendesk date, number to Zendesk integer. We extract per-ticket custom field values and insert them into Zendesk ticket custom_field_values. Conditional visibility rules on fields are not structured data and do not migrate; we deliver a custom field inventory worksheet listing field names, types, and visibility conditions for manual rebuild in Zendesk.

Fluent Support Mailboxes define incoming email channels tied to a specific WordPress site's domain and email routing configuration. These are not portable across environments. We flag every Mailbox during discovery and document what its routing rules (reply-to addresses, POP/IMAP inbox mappings, ticket creation triggers) should become in Zendesk: either Zendesk email channels with the corresponding email addresses or Zendesk web portal channels. The actual mailbox reconfiguration is a manual step performed by the customer's admin post-migration.

Fluent Support tickets tagged to a Product carry a product_id and product_source referencing a WordPress plugin or integration (e.g., Fluent Forms, a WooCommerce product). Zendesk has no native product entity in the core support model. We map product associations to a Zendesk custom text field product_source__c carrying the original product name, or alternatively to tags prefixed with product_ for reporting segmentation. The customer selects the strategy during scoping.

Fluent Support Tags stored as flat key-value arrays on tickets and customers migrate to Zendesk Tags. Zendesk automatically converts custom field dropdown values to tags on import, so if tags were used for categorization in Fluent Support, they land as native Zendesk tags on the corresponding ticket. Tag prefixes and naming conventions are preserved as-is.

Fluent Support priority fields (normal, high, low) map directly to Zendesk priority values (normal, high, low, urgent). If Fluent Support uses custom priority labels beyond these three, we create a Zendesk custom field priority_level__c with a dropdown containing the source values rather than using the standard priority field which has a fixed set.

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 from fs_conversations (file_path, file_name, mime_type), download each file, and upload to Zendesk using the Zendesk Attachments API. Files are linked to the corresponding Zendesk Ticket or Comment via the upload token returned by the API.

Fluent Support Workflows define sequences of tasks triggered by conditions (ticket created, status changed, agent assigned). The underlying rule logic is not exposed as structured JSON or YAML in the database schema and cannot export directly. We catalog every active Fluent Support workflow by name, trigger type, conditions, and action sequence and deliver a written Workflow Inventory document with each workflow mapped to an equivalent Zendesk Trigger, Automation, or Macros configuration. The customer's admin rebuilds the automation in Zendesk Admin post-migration.

Fluent Support's personal and team reports (Resolve Stats, Response Stats, Ticket Stats) are dynamically computed from ticket data at query time and are not persisted as standalone records. We cannot migrate them as discrete objects. Before migration, we export key report screenshots and aggregate data snapshots from Fluent Support. In Zendesk, the customer rebuilds reporting using Zendesk Explore with the migrated ticket data as the source. Historical comparison against Fluent Support-era metrics requires importing the exported snapshot data into a BI tool or Zendesk Explore as a reference dataset.