Migrate from Dixa to Zendesk

Dixa Conversations map to Zendesk Tickets as the primary migration unit. Each Conversation's channel type (phone, email, chat, social) maps to the Zendesk ticket's channel via the channel field or ticket form. Conversation status (open, pending, resolved, closed) maps to Zendesk Ticket Status with the original Dixa status preserved in a custom field for reconciliation. Subject and first-message body become Ticket subject and the initial comment. Custom fields on Dixa Conversations map to Zendesk ticket custom fields by matching field name and type — dropdown to single-select, checkbox to boolean, text to text. We export Conversations via Dixa's Exports API using time-range or conversation ID list queries before exporting Messages.

Dixa Messages are children of Conversations and export separately via the Exports API. Each Message references its parent conversation ID which we use to associate the comment with the correct Zendesk Ticket. Message author (agent or customer) determines whether the comment is public (reply from agent) or internal (note). Agent replies become public Ticket Comments; internal notes become Zendesk Ticket Comments marked as internal. We join Messages to Conversations in the migration staging layer so that parent-record dependencies are resolved before any child records are inserted into Zendesk. Message timestamps preserve the original Dixa created_at value for activity timeline ordering.

Dixa Customer profiles (name, email, phone, custom properties, conversation history) map to Zendesk End Users. Email address is the dedupe key. Dixa's customer timeline — displaying conversation history and order history where integrated — does not have a native Zendesk equivalent; we preserve it as a custom field array or as a structured note attached to the End User record. Any Dixa custom properties on the customer profile migrate to Zendesk End User custom fields matched by name and type. We map customers before Conversations so that the requester relationship is satisfied at the moment of ticket import.

Dixa Agent records (name, email, presence status, role) map to Zendesk Agent User records. We match by email address. Agent-to-team assignments from Dixa migrate as Zendesk Group memberships — each Dixa Team becomes a Zendesk Group and the agent's team membership becomes membership in the corresponding Zendesk Group. Any Dixa role (admin, supervisor, agent) maps to a Zendesk role (admin, agent) with the understanding that Dixa's supervisor role has no direct Zendesk equivalent and is documented for the customer's admin to configure post-migration. Agents without matching Zendesk User records go to a reconciliation queue for admin provisioning before record import.

Dixa Teams are organizational units that group agents and own routing queues. Team names and structures export cleanly from Dixa. We map them to Zendesk Groups as the nearest equivalent organizational unit. Dixa team-level SLA settings, operating hours, and queue configurations are Dixa-platform configurations that do not export via API — these are documented during scoping as configuration items requiring manual rebuild in Zendesk Admin (SLA Policies, Business Rules). The customer's admin must recreate queue-level logic as Zendesk Views, Triggers, or Macros post-migration.

Dixa auto-tags every conversation for routing purposes regardless of channel — these tags reflect internal queue logic and customer priority, not external-facing labels. Direct one-to-one mapping to Zendesk Tags is rarely possible because Dixa routing-intent tags have no standard Zendesk equivalent. We map each Dixa tag value explicitly: the customer's admin reviews the Dixa tag inventory during scoping and decides which tags map to Zendesk Tags and which are routing metadata to discard. Any tags used for both routing and reporting are flagged as requiring a dual mapping strategy (tag plus a custom field) to preserve reporting continuity.

Dixa post-conversation CSAT ratings (score, submission timestamp, linked conversation ID) migrate to Zendesk Ticket Satisfaction Rating records linked to the corresponding Zendesk Ticket. Ratings without a linked conversation record are flagged as orphaned and excluded from migration with a count reported in the reconciliation summary. The Zendesk Satisfaction Rating API must be enabled in the destination account before this object migrates.

Dixa Knowledge Base articles (title, body content, category, metadata) export as standalone objects. We map them to Zendesk Guide Articles within the customer's Help Center. Article categories map to Zendesk Guide Sections; top-level categories map to Zendesk Guide Categories. Articles tied to Dixa routing or conversation context carry metadata that does not have a Zendesk equivalent — we preserve this as article notes or comments. Zendesk Guide must be activated in the destination account before article import; Guide hierarchy (Category > Section > Article, up to five levels) must be pre-created to match Dixa's category structure.

Dixa attachments are linked by file path within conversation records rather than stored as standalone binary objects in the export. We preserve file path references and extract binary attachments where accessible via the Dixa API. Attachments migrate as Zendesk Ticket Attachments linked to the corresponding Ticket Comment. Attachments exceeding Zendesk's file size limits or those stored at inaccessible paths are flagged in the reconciliation report. Inline images within article body content migrate as separate file attachments to the Guide Article.

Dixa unifies Phone, Email, Chat, Facebook Messenger, Instagram, Twitter, and WhatsApp as conversation channels, with channel type stored as a field on each conversation record. Zendesk determines channel by the ticket form used, the email address associated with the ticket, or the channel-specific app (Chat, Talk, Messaging) active on the account. We map Dixa channel type to the corresponding Zendesk channel via a lookup table at migration time. If the customer licenses Zendesk Talk or Zendesk Messaging separately, those channels require additional configuration outside the data migration scope.