Migrate from Dixa to Intercom

Dixa Conversations map to Intercom Conversations as the primary migration unit. We extract via Dixa's Exports API using time-range queries or conversation ID lists, preserving channel type (email, chat, phone, social), status, priority, created_at, updated_at, and agent-assignment. The Intercom Conversation ID is generated at insert time and we maintain a Dixa-ID to Intercom-ID cross-reference table for downstream message linking and audit trails.

Dixa Messages are children of Conversations and export separately via the Exports API using the parent conversation ID as the join key. Each message references its parent conversation ID. We resolve the Intercom Conversation ID via the cross-reference table at migration time and insert Parts in correct timestamp order so the conversation timeline in Intercom matches the original Dixa sequence. Unlinked messages (no valid parent conversation ID) are flagged as orphaned and reported separately.

Dixa Customer profiles — including name, email, phone, custom properties, order history where integrated, and conversation timeline — map to Intercom Contacts. We preserve custom property values as Intercom custom attributes, creating the attributes in Intercom before contact import. Customer deduplication uses email as the primary key. Where Dixa stores contact language preference or customer priority tier, these map to Intercom custom attributes for segmentation.

Dixa Agent records — name, email, presence status, role, and team membership — map to Intercom Admins (full access) or Teammates (restricted access). We resolve agents by email match against the Intercom workspace. Agent-to-team assignments from Dixa map to Intercom Team membership. Any Dixa Agent without a matching Intercom user goes to a reconciliation queue for the customer to provision before record migration proceeds.

Dixa Teams are organizational units that group agents and own routing queues. Team names and structures export cleanly from Dixa. We map them to Intercom Teams, but team-level SLA settings, operating hours, and queue inbox configurations are Dixa-configured and non-exportable. We document the team structure from Dixa and flag that inbox routing rules, operating hours, and SLA thresholds require manual reconfiguration in Intercom's Team and Inbox settings.

Dixa unifies Phone, Email, Chat, Facebook Messenger, Instagram, Twitter, and WhatsApp as conversation channels. Channel type is stored as a field on each Dixa conversation record. We preserve channel type as an Intercom Conversation attribute. Note that Intercom's native phone support is available only through beta features and third-party integrations — if the customer uses Dixa's native VoIP, phone conversations migrate as conversation history but ongoing phone support requires a separate telephony integration post-migration.

Dixa auto-tags every conversation for routing regardless of channel. These tags reflect internal queue logic, customer priority tiers, and agent skill routing — not external-facing labels. They do not map one-to-one to Intercom Labels because Intercom Labels are applied manually or via workflow rules rather than automatically per routing logic. We extract the full Dixa tag taxonomy during scoping, present it to the customer, and recommend a value-mapping strategy: routing-intent tags become either Intercom custom conversation attributes or a labeled segmentation scheme rebuilt in Intercom's Workflow Builder. This is a decision point during scoping, not an automatic migration.

Dixa custom fields on conversations and customer profiles are available via the CSV export and API. Field names and types export cleanly. We pre-create equivalent Intercom custom attributes before migration, mapping field types from Dixa (text, number, date, boolean, dropdown) to Intercom attribute types (string, number, boolean, date, list). Destination attribute creation happens in Intercom before data import; type mismatches between Dixa and Intercom attribute models require explicit handling during the transform step.

Dixa post-conversation CSAT ratings — rating score, submission timestamp, and linked conversation ID — map to Intercom Conversation Ratings. We link each rating to its corresponding Intercom Conversation via the cross-reference table. Ratings without a valid linked conversation are flagged as orphaned. Dixa's sentiment detection scores (available on Growth and above) migrate as a custom conversation attribute if in scope.

Dixa Knowledge Base articles are standalone objects with content, category, and metadata. We export them independently of conversations and map to Intercom Articles. Article body content, category assignment, author, and publication status migrate. Articles tied to Dixa routing rules or linked from auto-tag workflows require re-linking in Intercom's Knowledge Hub post-migration. Content formatting (markdown, HTML) is preserved where possible; images migrate as file references.

Dixa's 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. We capture the current routing configuration during the scoping call as a written inventory and deliver it as a configuration document. The customer's admin rebuilds routing rules in Intercom's Workflow Builder post-migration. This is explicitly out-of-scope as a data migration task.

Dixa's Workflow Automation governs routing, escalation, and SLA thresholds. Workflow logic is not exportable via API. We document every active workflow during scoping — trigger, conditions, actions, and delay steps — and deliver a written inventory with recommended Intercom Workflow Builder equivalents. The admin team rebuilds workflows post-migration. This work is separate from data migration scope and we flag it as a distinct workstream with an estimated rebuild timeline.