Migrate your Dixa data

Conversations are the primary exportable unit in Dixa. We pull them via the Exports API using time-range or conversation ID list queries. All standard fields available in the CSV export are available via API. Each conversation has a unique conversation ID, channel type, status, assigned agent, team, and timestamp.

Messages are children of Conversations and are exported separately via the Exports API using time-range queries. Each message references its parent conversation ID. We join messages to conversations during migration to preserve threading order and conversation context.

Customer profiles include conversation history displayed as a timeline, order history where integrated, and custom properties. We map these to the destination's contact/customer object, preserving profile-level metadata and linking to conversations where the relationship is stored on the conversation record.

Agent records include name, email, presence status, and role. We map agents to the destination's user/agent object and preserve agent-to-team assignments as a separate mapping step.

Teams are organizational units that group agents and own routing queues. Team names and structures export cleanly, but team-level SLA settings, operating hours, and queue configurations require explicit mapping to the destination's equivalent team/routing model.

Dixa unifies Phone, Email, Chat, Facebook Messenger, Instagram, Twitter, and WhatsApp as conversation channels. Channel type is stored as a field on each conversation record, not as a separate object, so migration preserves channel provenance natively within each conversation row.

Dixa auto-tags conversations for routing regardless of channel. Tags are key-value or categorical labels stored on conversations. We map these to the destination's tag or label system, but auto-routing tags that reflect Dixa's internal queue logic may not have equivalents in generic helpdesk systems and require value mapping.

Custom fields on conversations and customer profiles are available via the CSV export and API. Field names and types export cleanly, but destination field creation and type mapping must be coordinated with the customer's admin before migration.

Post-conversation CSAT ratings are exportable via the Dixa API. We preserve rating score, submission timestamp, and linked conversation ID. Ratings without linked conversation records are flagged as orphaned and surfaced for manual review.

Knowledge base articles are separate from conversations and must be exported independently. We handle articles as standalone migration objects with content, category, and metadata. Articles tied to Dixa's AI surfacing rules may require reconfiguration in the destination's knowledge management system.

Dixa's Workflow Automation governs routing, escalation, and SLA thresholds. Workflow logic is not directly exportable — we document workflow rules as part of the migration scoping call and provide a field mapping that applies the same routing intent in the destination system.

Attachments in Dixa are linked by file path within conversation records rather than stored as standalone binary objects in the export. We preserve file path references and flag any attachments that are inaccessible due to permissions or expired URLs.

Intelligent routing rules route conversations by skills, language, customer priority, and queue state. Routing logic is Dixa-configured and not portable via API. We capture the current routing configuration during the scoping call and map the intent to the destination's equivalent routing or assignment model.