Migrate from Dixa to HubSpot Service Hub

Dixa Conversations map to HubSpot Service Hub Tickets. Each conversation's status (open, pending, resolved, closed) maps to HubSpot Ticket status values. The conversation subject becomes Ticket Subject; the channel type (email, chat, phone, social) becomes the Ticket source field. We pull Conversations via the Dixa Exports API using time-range queries or conversation ID lists and write to HubSpot Tickets via the Tickets API or CSV import. The conversation priority field maps to Ticket priority if the customer's Dixa priority values are defined in the export schema.

Dixa Messages are children of Conversations and are exported separately via the Dixa Exports API. Each message carries a parent conversation ID foreign key. We import Messages after Conversations so the parent mapping is satisfied — without the parent ticket present in HubSpot, messages land as orphaned records that cannot be threaded. Messages authored by the customer become Ticket Conversation entries from the requester; messages from agents become internal or public replies depending on the visibility flag in Dixa's export.

Dixa Customer profiles (name, email, phone, custom properties, order history where integrated) map to HubSpot Contact records. Customer conversation history timeline attaches to the Contact record as a Ticket association. Custom properties on Customer profiles export via the CSV export and map to HubSpot Contact properties — string to string, date to date, boolean to boolean-checkbox. The customer email is the dedupe key during import to prevent duplicate Contact creation.

Dixa Agent records (name, email, role, presence status) map to HubSpot Service Hub Users. We resolve agents by email match. Any Dixa Agent without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Agent-to-team assignments in Dixa map to HubSpot Teams, which must be configured in HubSpot Service Hub settings before migration begins.

Dixa 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 are Dixa-administered and not accessible via the Exports API. We export the team roster and map it to HubSpot Teams, but operating hours and SLA thresholds are documented as a configuration workstream to rebuild in HubSpot Service Hub settings post-migration.

Dixa auto-tags every conversation for routing regardless of channel, storing routing-intent labels that reflect internal queue logic and customer priority rather than external-facing labels. These tags do not have a direct HubSpot equivalent. We explicitly map Dixa tag values to HubSpot Ticket Labels during scoping, preserving any tags that represent real categorization (product area, issue type, language) while flagging routing-only tags that serve no purpose in HubSpot's routing model. Categories are documented as a source of truth for rebuilding as HubSpot Ticket topics or custom picklist fields.

Custom fields on Dixa conversations surface as explicit columns in the CSV export. Field names and types export cleanly, but destination field creation and type mapping require coordination before import. We create the equivalent custom properties in HubSpot Service Hub (string, number, date, checkbox, or picklist) using the HubSpot Properties API, then map source values during import. Custom field creation must precede the conversation import phase.

Post-conversation CSAT ratings from Dixa migrate to HubSpot's survey-based feedback system. We preserve the rating score (numeric or star scale), submission timestamp, and linked conversation ID as a reference field on the HubSpot Ticket. Ratings without a linked conversation record are flagged as orphaned and held for customer review before import.

Dixa Knowledge Base articles are separate from conversations and are exported independently. We handle articles as standalone migration objects with title, body content, category, and metadata. The category hierarchy in Dixa maps to HubSpot Help Desk article folders and sections. Articles tied to Dixa routing rules or workflow triggers are flagged separately because those associations do not migrate — the customer rebuilds the article-to-workflow linkage in HubSpot's automation builder.

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 from the Dixa export and link them to the migrated HubSpot Ticket as file attachments. Any attachments with inaccessible or broken file paths are flagged as a migration gap for customer review. Full binary attachment migration requires confirming that the customer's Dixa storage is still accessible at the time of export.

Dixa's Workflow Automation governs routing, escalation, and SLA thresholds and is not accessible via the Dixa Exports API or Dixa API. We document workflow rules during the scoping call — trigger events, conditions, branch logic, and resulting actions — and deliver a written inventory with recommended HubSpot Service Hub workflow equivalents. The customer's admin rebuilds workflows in HubSpot's automation builder post-migration. This is explicitly outside data migration scope.

Dixa's 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 scoping as a written record and provide an Inbox Rules rebuild guide for HubSpot Service Hub's assignment and routing features. Active routing rules must be disabled in Dixa at cutover to prevent new conversations routing to a system no longer in use.