Migrate from Brisk Support to Gorgias

Brisk Support Tickets map directly to Gorgias Tickets. The ticket subject, body content, status, priority, channel source (email, phone, chat), timestamps (created_at, updated_at), and agent assignment transfer as 1:1 field mapping. Conversation threads migrate as a chronologically ordered list of message records with the same from/to attribution. Channel metadata (how the ticket originated) is preserved in a custom field src_channel__c to maintain intake attribution at the destination.

Brisk Support Customer records (name, email, phone, company, address) map to Gorgias Customer objects. Email serves as the primary dedupe key across both platforms. We preserve any custom attribute values from Brisk Support Tier 3 as Gorgias CustomField entries using the external_id property to maintain the Brisk Support field name as a cross-reference. Customer-to-ticket associations are resolved by matching the customer email on each message record during thread import.

Brisk Support Agents map to Gorgias Users. Agent identity is resolved by email address as the matching field. We do not migrate Brisk Support role-based access controls because the platform has no documented permissions API and roles are organizational configuration rather than per-record data. Agent assignment history on tickets is preserved by mapping the Brisk Support agent_id to the Gorgias user_id at import time. Agents without a matching email in the Gorgias destination org are held in a reconciliation queue for the customer's admin to provision before migration resumes.

Brisk Support Queues map to Gorgias Teams with a one-to-many relationship because a single Gorgias Team can handle multiple Queues' worth of ticket volume. We map each distinct Brisk Support Queue name to a Gorgias Team, and ticket assignment is re-established by matching the source ticket's queue_id to the destination team's scope. Queue routing rules (weighting, escalation, assignment criteria) are documented as structured notes during discovery but are not migrated as configuration because Brisk Support routing is proprietary and Gorgias Rules use a different trigger model.

Brisk Support KB Articles (title, body content, categories, publication status) map to Gorgias Help Center Articles. Article body content migrates as HTML with images preserved as separate attachment records linked to the Article. Internal hyperlinks within articles that reference other Brisk Support KB URLs are flagged as broken links for manual update post-migration. Publication status (draft, published, archived) maps directly. Article categories migrate as Gorgias Article categories, but folder hierarchy depth may require flattening depending on the destination help center structure.

Brisk Support file attachments attach to the corresponding Gorgias Ticket or Customer record. We check attachment availability during discovery: if the source account is on the Free tier and files are approaching or past the 60-day expiration window, we export those files immediately before migration begins. Attachment URL references in conversation threads are updated to point to the destination-attached file or flagged as expired if the source file is no longer retrievable. Destination attachment storage limits follow the Gorgias plan tier.

Brisk Support Tier 3 custom attributes on tickets map to Gorgias CustomField objects using the external_id property to carry the Brisk Support attribute name as a cross-reference. We pre-create the destination custom fields before ticket import so that attribute values write to typed fields (text, number, date, dropdown) rather than generic note fields. If the customer is on Brisk Support Free or Tier 2 and has no custom attributes, this mapping step is omitted. Custom attribute schema is per-organization on Brisk Support, so field names and data types are captured individually during discovery for each customer.

Brisk Support routing rules (conditions, agent weighting, auto-assignment logic) are non-portable. We document each rule's trigger conditions, agent pool, weighting formula, and escalation path during the discovery call as a structured inventory. The customer's admin uses this document to rebuild equivalent Rules in Gorgias using Gorgias Rules triggers (ticket created, tag added, customer attribute matched). This is a manual rebuild step, not an automated migration of rule logic.

Brisk Support escalation rules define time-based escalation paths (first response SLA, follow-up intervals, manager escalation triggers). These are documented as structured notes during discovery with the original SLA thresholds and escalation recipients. The customer's admin rebuilds these as Gorgias Rules with time-based triggers and notification actions. Escalation recipient email addresses are mapped to Gorgias User or Team assignments at rebuild time.

Brisk Support reports (agent activity, queue activity, response time, resolution time) are exported as CSV aggregates. We deliver these as a standalone exported dataset because Brisk Support's reporting schema is not publicly documented for automated import. Gorgias reporting uses tag-based categorization and exports in CSV or heatmap/table format; the customer recreates reports in Gorgias using the exported baseline numbers as reference. Historical report data is preserved in CSV, not integrated into the Gorgias reporting UI.

Brisk Support internal notes attached to tickets migrate as Gorgias internal notes on the corresponding ticket. Internal notes are visible only to agents and are distinguished from customer-facing messages by message type. Author attribution is resolved by matching the agent email to the Gorgias User mapping. Internal note visibility and permissions are not configurable per-note in Gorgias, so all migrated notes inherit the destination ticket's default visibility.

Brisk Support tags on tickets map to Gorgias Tags as string labels. Tags used for categorization and routing in Brisk Support transfer directly to the destination and are available for use in Gorgias Rules triggers. Tag-based reporting in Gorgias is available once migration completes, allowing the customer to rebuild Brisk Support-style tag reports using the migrated tag set.