Migrate from Dixa to Gorgias

Dixa Conversations map directly to Gorgias Tickets. We pull conversations via Dixa's Exports API using time-range queries or conversation ID lists. Each conversation's created_at, updated_at, closed_at, channel type, status, and priority migrate as ticket metadata. Conversation ID becomes a custom external_id field in Gorgias for traceability back to the source record. Dixa's channel field (phone, email, chat, messaging) maps to Gorgias's channel determination via the integration that received the ticket.

Dixa Messages are children of Conversations and exported separately via the Exports API. Each message carries a parent conversation ID. We join messages to their parent ticket at migration time using this foreign key — if the parent ticket is not yet created, messages land as orphaned records in Gorgias with no parent ticket to attach to. We sequence the Conversation migration phase to complete before the Message phase to prevent orphaned records. Author identity, message body, timestamp, and attachment references all transfer.

Dixa Customer profiles (name, email, phone, custom properties, order history where integrated) map directly to Gorgias Customer. The customer email address serves as the primary dedupe key during import. We map Dixa custom properties on customer profiles to Gorgias custom fields on the Customer object, creating the destination fields before migration begins. Customer conversation history links to the Customer record via email match.

Dixa Agent records (name, email, role, presence status) map to Gorgias Agents. We resolve agents by email address match during migration. Agent-to-team assignments on the source are preserved as Gorgias team membership, which requires the destination Teams object to be provisioned and populated before the Agent import phase runs. Agents without an email match enter a reconciliation queue for the customer admin to resolve.

Dixa Teams map to Gorgias Teams. Team names and structures export cleanly via the Dixa Exports API. We provision Teams in Gorgias before the Agent migration phase because agent-to-team assignments are set during agent import and require the Team object to exist first. Team-level SLA settings, operating hours, and queue configurations in Dixa are non-exportable and must be manually reconfigured in Gorgias team settings after migration.

Dixa Tags are categorical labels stored on conversations and include both manually applied tags and auto-tags generated by Dixa's routing engine for queue assignment. Auto-routing tags reflect internal Dixa logic and have no standard equivalent in Gorgias Labels. We map manually applied tags directly to Gorgias Labels by value. For auto-routing tags, we surface the full taxonomy to the customer during scoping and ask them to designate which tags represent meaningful customer-facing categorization versus internal routing intent. This mapping decision is required before migration begins.

Dixa post-conversation CSAT ratings (score, submission timestamp, linked conversation ID) map to Gorgias Satisfaction records attached to the corresponding Ticket. We resolve each rating to its ticket using the Dixa conversation ID stored on the rating record. Ratings without a resolvable conversation ID in the migration window are flagged as orphaned and reported separately. Rating score values (numeric or star scale) map directly; if the scale differs between platforms, we document the conversion during scoping.

Dixa custom fields on conversations are available in the CSV export and API. We map field names and types to equivalent Gorgias custom fields on the Ticket object, creating the destination fields before migration begins. Field type mapping (text, number, date, dropdown) must be coordinated with Gorgias field type availability. Dixa custom fields that reference other Dixa objects via ID require a lookup step to resolve the corresponding Gorgias record ID at migration time.

Dixa custom properties on Customer profiles map to Gorgias custom fields on the Customer object. Field creation in Gorgias is a prerequisite for this migration step. We extract the full list of custom property names and types from Dixa's admin export during scoping and create the matching fields in Gorgias before data migration begins. Customer-level custom fields that reference company data require cross-object ID resolution at migration time.

Dixa Knowledge Base articles are exported as standalone objects with content, category, and metadata. We export article title, body (HTML or Markdown), category assignments, publication status, and author. Articles are imported into Gorgias Help Center as Help Center Articles via the Gorgias Help Center API or CSV import. Article URLs in Dixa do not automatically redirect in Gorgias; we recommend a URL mapping document for the customer's admin to configure redirects post-migration. Articles tied to specific Dixa routing rules or auto-suggestion triggers are flagged as requiring manual re-association in Gorgias.

Dixa Knowledge Base Categories map to Gorgias Help Center Categories. We export category names, parent-child hierarchy, and article count. The hierarchy is recreated in Gorgias before article import so that articles land in the correct parent category. Category-level settings (visibility, access control) that exist in Dixa are manually reconfigured in Gorgias by the customer admin post-migration.

Dixa attachments are stored as file path references within conversation and message records rather than as standalone binary objects in the export. We preserve the file path and flag any attachments where the referenced file may not be accessible from the migration context. If the customer's Dixa instance stores attachments in a connected cloud storage bucket (S3, Google Cloud Storage), we coordinate access credentials during scoping to retrieve files and re-upload them to Gorgias via the Gorgias Files API.

Dixa Intelligent Routing rules route conversations by skills, language, customer priority, and queue state. Routing logic is Dixa-configured and not accessible via the Exports API or Dixa API. We capture the current routing configuration as part of the scoping discovery call and document it as a separate configuration workstream. Gorgias Rules and Macros provide the replacement automation surface. We do not rebuild routing rules in Gorgias; we deliver a written routing-rule inventory with a Gorgias Rule and Macro equivalent recommendation for each Dixa routing logic block.

Dixa Workflow Automation governs routing, escalation, SLA thresholds, and auto-responses. Workflow logic is not directly exportable via API. We document every active Workflow Automation during the scoping call and deliver a written Workflow inventory with recommended Gorgias Rule and Macro equivalents. The customer admin rebuilds these in Gorgias post-migration. This is explicitly outside data migration scope; the inventory document enables the admin to complete the rebuild efficiently.