Migrate from Fluent Support to Gorgias

Fluent Support tickets (fs_tickets) map 1:1 to Gorgias tickets. We extract ticket_id, customer_id, agent_id, mailbox_id, product_id, priority, status, title, content, and source fields and write them to the Gorgias /tickets endpoint. The fs_tickets created_at and updated_at timestamps are preserved as the Gorgias created_at and last_updated timestamps. Any WordPress-site-specific mailbox_id and product_source strings are flagged as requiring manual reconfiguration to point to the Gorgias inbox channel and the connected e-commerce store.

Each Fluent Support ticket has one or more conversation entries in fs_conversations. We preserve the full back-and-forth including timestamps, author type (customer vs agent), message content, and attachments. Messages migrate as Gorgias Message objects with the author mapped to either the Customer or Agent created in the destination. The conversation ordering is preserved by created_at timestamp so the ticket timeline reads in the correct sequence.

Fluent Support customer records are WordPress users with profile data including name, email, and contact information. We map the WordPress user ID to a Gorgias Customer record using the customer's email as the primary key. Customer-specific custom field values from Fluent Support migrate to the corresponding Gorgias customer attribute. Any Customer notes or tags from Fluent Support carry over as Gorgias Customer notes and tags.

Agents in Fluent Support are WordPress users with the Fluent Support agent role. We map source WordPress user IDs to Gorgias Agent accounts by matching email addresses. We recommend provisioning the Gorgias agents before migration so that the email-match lookup resolves all agent assignments during ticket import. Any WordPress users who were agents but do not yet have a Gorgias account go into a reconciliation queue for the customer's admin to provision before the migration resumes.

Fluent Support Mailboxes define the incoming channel sources (email, portal) tied to the specific WordPress site's domain and email routing configuration. These are not portable because they reference WordPress-site-specific MX records, SMTP settings, and domain bindings. We flag every Fluent Support Mailbox during discovery, identify the source routing logic (reply-to addresses, POP/IMAP inbox mappings), and document what channel configuration the customer must set up manually in Gorgias (Settings > Channels > Email or Chat). This is a post-migration step, not part of data migration.

Fluent Support tickets can be tagged to a Product with a product_id and product_source string referencing a WordPress plugin or integration such as Fluent Forms. These references are WordPress-environment-specific and have no direct Gorgias equivalent because Gorgias connects to e-commerce stores (Shopify, BigCommerce) rather than WordPress plugins. We document every Product association found in the source tickets and map them to a Gorgias Product or connected-store reference based on whether the customer connects their storefront during Gorgias setup.

Fluent Support conditional custom fields are extracted with their field definitions (name, type, options) and their current per-ticket values. The conditional visibility rules that control when field B appears based on field A's value are stored as UI preferences and are not exportable as structured configuration. We provide a Custom Field Inventory worksheet listing every field name, type, and the conditional logic that controlled its visibility, so the customer's Gorgias admin can rebuild the same behavior in Gorgias using Rules and ticket attributes.

Fluent Support Workflows are defined through a UI builder with triggers (ticket created, status changed, agent assigned) and action sequences. The underlying rule logic is not exposed as structured JSON or YAML in the database schema. We catalog every active Fluent Support Workflow by name, trigger type, conditions, and action sequence and deliver a written Workflow Inventory document. The customer's admin rebuilds these in Gorgias as Rules (for ticket routing and auto-assignment) and Macros (for templated responses). We recommend scheduling the rebuild during a post-migration validation window of at least one week.

Tickets carry priority values (normal, high, low) in Fluent Support's priority and client_priority fields. These map directly to Gorgias ticket priority levels (low, normal, high, urgent) with configurable value translation if the destination uses a different scale. We preserve the source priority value in a custom ticket attribute for audit trail purposes.

Fluent Support supports tagging on tickets and customers for categorization. We migrate tags as flat key-value arrays and map them to Gorgias tags on the corresponding Ticket and Customer records. Tags are preserved as-is since both platforms use string-based labeling without a defined taxonomy.

Files attached to tickets and conversations are stored in the WordPress media library or the plugin-specific upload directory. We extract attachment URLs and file metadata, download each file, and re-upload to Gorgias as ticket attachments via the Gorgias API. Large attachment sets (over 10 GB total) may extend migration time and are scoped separately during discovery.

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 stored as discrete database records. These cannot be migrated as discrete objects. We recommend capturing screenshots of key Fluent Support report views before migration cutover and rebuilding the reporting cadence in Gorgias using the built-in ticket analytics dashboard and exported CSV data after cutover.