Extract Dixa history via API, load into Zendesk's Ticket Import API with timestamps preserved. Bottlenecks: Dixa's 3 req/min message limit and manual Flows-to-triggers workflow rebuild.
Migrating from Dixa to Zendesk requires translating a conversation-centric, offer-based routing platform into a ticket-lifecycle, view-based system — there is no native migration path between the two. Dixa's Exports API enables extraction of conversations, messages, contacts, tags, and custom attributes, while Zendesk's Ticket Import API accepts historical tickets with preserved timestamps, making the data transfer path well-defined but rate-limited (10 requests/min for conversations, 3 requests/min for messages, 31-day query windows). The most time-consuming work is the workflow redesign: Dixa's visual Flow Builder with branching logic must be manually decomposed into Zendesk triggers, automations, SLA policies, views, and Omnichannel Routing rules, with a complex Flow typically translating into 8–15 triggers plus additional automations.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
TL;DR Conversation history, contacts, tags, and custom attributes extract cleanly from
TL;DR Conversation history, contacts, tags, and custom attributes extract cleanly from Dixa via API and load into Zendesk via the Ticket Import API with timestamp preservation. Dixa's Exports API caps at 10 conversation requests per minute and limits each query to a 31-day window — plan extraction accordingly. Zendesk's import endpoint accepts batches of 100 tickets and does not fire triggers or automations on imported records. The workflow redesign (Dixa Flows and Queues → Zendesk triggers, views, and Omnichannel Routing) is the most time-consuming task. Realistic timeline for ~30 agents and 100K conversations: 3–6 weeks including planning, test migration, workflow rebuild, and validation.
Zendesk Sell is being retired
Zendesk announced on June 19, 2026 that Sell will retire on August 31, 2027. If your migration plan includes CRM data going to Zendesk Sell, consider alternative targets. Companies, leads, and deals are Sell-specific objects — treat Support and Sell as separate scoping exercises. (support.zendesk.com)
Throughput math
At 700 req/min (Enterprise) with 100 tickets per batch, you can theoretically import 70,000 tickets per minute. In practice, factor in user creation, attachment uploads, and error handling — realistic throughput is 5,000–15,000 tickets per hour.
Key difference
Dixa's offer-based routing presents one conversation at a time and waits for agent acceptance. Zendesk's Omnichannel Routing auto-assigns tickets to agents based on availability and capacity — there is no accept/reject step. This changes agent behavior and may require training to prevent cherry-picking via views.
This is a structural outline
A production implementation needs retry logic with exponential backoff, persistent state tracking (so you can resume after failures), concurrent extraction where rate limits allow, and comprehensive error logging. Budget 2–3 weeks of engineering time for a production-grade implementation.
If Dixa KB content is outdated or inconsistent, the migration is a natural trigger for a
If Dixa KB content is outdated or inconsistent, the migration is a natural trigger for a content audit. Migrate structure via API, then review and update content in Zendesk Guide's editor rather than migrating stale content as-is.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Establish why you are moving, what "done" means, and who signs off.
Objective A written scope with agreed success criteria, a named owner per workstream, and a budget approved by finance.
Keep these open
-
Pull the real numbers out of Dixa
Export counts for tickets (open and closed separately), contacts, organisations, attachments, macros, triggers, automations, views and SLA policies. Note the oldest ticket date — history depth drives the whole timeline. Estimating from memory is the single most common cause of a blown migration window.
Data Profiler Get real record counts instead of estimating from memory -
Decide what history actually moves
Agree a cut-off with the support lead: all history, last 24 months, or open tickets plus a read-only archive. Every extra year of closed tickets adds API time and cost without adding much agent value. Get this in writing — it is the decision people relitigate mid-cutover.
A "move everything" default is what turns a two-week migration into a two-month one.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Confirm Zendesk can hold your support model
Walk your current workflow through Zendesk: multi-brand, business hours, SLA targets, CSAT, side conversations, public vs internal notes, and any channel you depend on (voice, chat, WhatsApp, social). List anything with no native equivalent — those are project risks, not configuration details.
-
Build the business case
Model licence delta, migration effort, agent retraining, and the cost of staying put (Cost of Inaction). Executives approve a number, not a plan, and you will be asked for it again at the go/no-go.
Helpdesk Migration Planner Turn ticket volume into a dated Dixa → Zendesk timeline -
Name owners and set the go/no-go date
One named owner each for data, configuration, integrations, and agent enablement, plus a decision-maker who can call a rollback. Put the go/no-go meeting in calendars now, 48 hours before the freeze.
Dixa → Zendesk specifics
- Marketplace ecosystem
- Zendesk's marketplace lists over 1,500 apps (zendesk.com/marketplace). Dixa's integration library is significantly smaller — under 100 native integrations as of 2025. If your stack depends on deep third-party connections (Jira, Salesforce, Shopify analytics), Zendesk covers more ground.
- Reporting depth
- Zendesk Explore provides custom report building with a drag-and-drop query builder, pre-built dashboards, scheduled delivery, and cross-channel analytics including custom metrics and calculated attributes (support.zendesk.com/hc/en-us/articles/4408821475098). Dixa's native reporting supports standard metrics but lacks comparable customization and drill-down capability.
- Knowledge base maturity
- Zendesk Guide supports categories, sections, community forums, content versioning, and multi-brand knowledge bases. Dixa Knowledge (acquired via Elevio) has fewer content hierarchy features for complex documentation structures.
- Enterprise compliance
- Zendesk offers FedRAMP LI-SaaS authorization and a HIPAA BAA path on Suite Enterprise and above (zendesk.com/trust). Dixa holds SOC 2 Type II and is GDPR-compliant but does not publicly advertise HIPAA compliance or ISO 27001 certification as of mid-2025.
- Platform consolidation
- When the broader org already runs Zendesk for other teams, maintaining a separate Dixa instance creates data silos, duplicate reporting, and integration overhead.
Don't move on until
- Record counts confirmed for tickets, contacts, organisations and macros
- Success criteria signed off by the support lead
- Freeze window provisionally booked with the business
02 Data Audit Find out what is actually in the data before you try to move it.
Objective A profiled, cleaned export with every quality defect either fixed at source or explicitly accepted.
Keep these open
-
Take a full Dixa export and profile it
Export to CSV or JSON and profile every file: row counts, null rates per column, distinct values, and type consistency. Compare row counts against the API totals from Discovery — a gap here means your export is silently truncated, usually by pagination.
Data Profiler Profile the Dixa export for nulls, outliers and type drift -
Validate file structure before anyone writes a transform
Check delimiters, quoting, encoding (expect UTF-8, watch for BOMs and Latin-1), duplicate headers, and embedded newlines in ticket bodies. Ticket descriptions with raw newlines and commas break naive CSV parsers and silently shift columns.
A single unescaped quote in one ticket body can shift every subsequent column without any error.
CSV Validator Catch broken headers and ragged rows in the raw export -
Inventory PII and set retention
Scan for emails, phone numbers, payment card fragments, national IDs and anything else regulated in ticket bodies and custom fields — support tickets are where customers paste things they should not. Decide what gets migrated, masked, or dropped, and record the legal basis.
Ticket bodies and attachments routinely contain card and ID data that never appears in a structured field.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Quantify duplicates, orphans and dead references
Count duplicate contacts (same email, different casing), tickets whose requester no longer exists, organisations with no members, and attachments whose parent ticket is gone. Fix these in Dixa where you can — migrating them just moves the mess.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Clean and normalise the export
Trim whitespace, drop empty rows and columns, normalise casing on emails and tags, and standardise every timestamp to UTC ISO 8601. Timezone drift is invisible at load time and shows up weeks later as SLA reports nobody can reconcile.
-
Produce a masked copy for sandbox work
Generate a realistic but fake version of the export for testing and for any vendor who needs sample data. Loading real customer PII into a sandbox is a breach in most jurisdictions, and sandboxes are rarely covered by your DPA.
PII Masker Generate a safe copy for sandbox and vendor testing
Don't move on until
- Export parses cleanly with no ragged rows or encoding errors
- PII inventory complete and retention decisions recorded
- Duplicate and orphan records quantified and triaged
03 Field Mapping Turn two schemas into one signed-off mapping spec.
Objective A reviewed field-level mapping covering every object, with an explicit decision for every field that has no target.
Keep these open
-
Generate the first-pass Dixa → Zendesk field map
Start from an automated match on both schemas, then review every row by hand. Automated matching gets the obvious 70% right and is confidently wrong on the rest — especially anything named "type", "status" or "custom_field_1".
Schema Mapper Opens pre-loaded with the Dixa → Zendesk field pair -
Map status, priority and channel values, not just field names
Enumerate every value in each picklist on both sides and map them explicitly. Value-level mismatches are the defect class that survives all the way to production because the field itself mapped fine — a ticket that should be "Pending" arriving as "Open" reopens SLA clocks.
Statuses with no target equivalent (on-hold, pending-customer) need a policy decision, not a best guess.
-
Decide how custom fields land
Create the target custom fields first, matching type exactly (a dropdown mapped to free text can never be mapped back). Where Zendesk has no equivalent, decide between a new custom field, a tag, or a note appended to the ticket body — and record which.
-
Resolve identity and threading
Decide how source IDs are preserved — most platforms will not let you set the primary key, so keep the original ID in a custom field. Without it, reconciliation becomes fuzzy matching and every future support question about an old ticket is unanswerable.
Losing the original ticket ID makes reconciliation and rollback effectively impossible.
-
Plan attachments, inline images and threading order
Confirm size limits, allowed MIME types, and whether inline images survive as attachments or need rehosting. Decide the comment ordering and author attribution rules: comments loaded out of order, or all attributed to the API user, destroy the conversation history agents rely on.
-
Freeze and sign off the mapping spec
Version the spec, walk the support lead through it row by row, and get explicit sign-off. Any change after this point goes through change control — mid-flight mapping edits are how partial loads happen.
Dixa → Zendesk specifics
- Custom field values
- Verify dropdown values, dates, and numeric fields transferred correctly. Check for empty custom fields that should have values.
- Dixa Conversations
- (email, chat, phone, Messenger, WhatsApp, contact form) → Zendesk Tickets. Each Dixa conversation becomes one Zendesk ticket. Dixa's unified conversation model is channel-agnostic; Zendesk tickets carry channel metadata but work the same way across channels. (developer.zendesk.com)
- Dixa Messages
- (customer replies, agent replies, system messages) → Zendesk Ticket Comments. Each message becomes a comment with correct author_id, created_at, value, and public flag to preserve threaded history. (developer.zendesk.com)
- Dixa Internal Notes
- → Zendesk Private Comments. Internal notes live under conversation_wrapup_notes in Dixa's conversations export, not in the message export. If you only use message_export, you lose internal notes. (docs.dixa.io)
- Dixa Contacts
- → Zendesk End Users (requesters). Zendesk end-users are unique by email address. Dixa may have duplicate contacts with the same email — define a merge strategy before import. Per-user custom attributes require the single-user endpoint (GET /v1/endusers/{userId}), not the list endpoint. (docs.dixa.io)
Don't move on until
- Every source field is mapped, deliberately dropped, or parked in a custom field
- Status, priority and channel value maps agreed with the support lead
- Mapping spec version-controlled and signed off
04 Test Migration Prove the pipeline on a small, representative slice.
Objective A pilot load into a Zendesk sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Zendesk sandbox that matches production config
Create the custom fields, groups, brands, business hours and SLA policies first. A pilot into a default sandbox tests nothing, because the failures you care about are all configuration mismatches.
-
Pick a deliberately nasty pilot sample
Take 500-1000 records chosen for difficulty, not convenience: the longest ticket threads, tickets with the most attachments, non-Latin character sets, merged and split tickets, deleted requesters, and every status value. A clean random sample proves only that easy records are easy.
-
Run the load with masked data and instrument everything
Log every API request and response with its source record ID. When 40 records fail out of 10,000 you need to know exactly which ones and why, without re-running the whole batch.
PII Masker Never load real customer PII into a sandbox -
Measure real throughput against the rate limit
Record achieved records-per-hour under Zendesk's actual rate limits, including retries and backoff. Extrapolate to the full volume: if the maths says the full load exceeds your freeze window, you fix that now, not on cutover night.
Published rate limits are ceilings, not throughput. Assume real-world rates are meaningfully lower once retries and backoff are counted.
-
Reconcile the pilot and triage every failure
Diff source against target on record counts and field-level values. Every discrepancy gets a root cause and a fix — "probably fine" at pilot scale becomes thousands of broken records at full scale.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Put real agents in front of the pilot data
Have two or three agents work sample tickets end to end in the sandbox. They find the things reconciliation cannot see: unreadable threading, missing context, macros that no longer make sense. Fix the mapping, then re-run.
Dixa → Zendesk specifics
- Production
- Apply lessons from tests. Run during low-traffic hours (typically weekends or overnight). Have rollback plan ready.
- Field-level spot checks
- Check custom fields, tags, and ticket statuses across a random sample (minimum 50 tickets). Sample across channels and date ranges, not just recent email tickets.
- Attachment/recording checks
- Open random phone tickets (minimum 10) and verify recordings play correctly or links resolve.
- Agent UAT
- Have 2–3 agents work a real day in Zendesk using rebuilt views, macros, and routing. Focus on the workflow shift from offer-based assignment to view-based pulling.
- Email threading test
- Send test replies to old email threads and verify they create or append correctly.
Don't move on until
- Pilot batch reconciles to 100% on record counts
- Agents have reviewed sample tickets and confirmed they are workable
- Measured throughput extrapolates to a viable full-load window
05 Cutover Execute the switch inside a controlled, reversible window.
Objective All in-scope data live in Zendesk, agents working in the new system, and a rollback path that stayed available throughout.
Keep these open
-
Pre-load history before the freeze
Load closed tickets and contacts days or weeks ahead while Dixa stays live. Only open tickets and the final delta need to move inside the freeze — this is the single biggest lever on window length.
Helpdesk Migration Planner Size the freeze window from Zendesk's real API limits -
Publish the runbook with times, owners and abort criteria
A timed sequence: freeze start, final export, delta load, channel switch, smoke test, go/no-go, agent switch. Name who does each step and the explicit condition that triggers a rollback. Decide the abort criteria before the night, when nobody wants to be the one to call it.
-
Freeze Dixa and take the final delta
Stop new ticket creation, let agents finish in-flight replies, then export everything changed since the pre-load. Announce the freeze to the whole business, not just support — someone always tries to raise a ticket during it.
Tickets created during an unenforced freeze land in the old system and are the most common source of permanently lost data.
-
Load the delta and open tickets
Run the delta load, then reconcile counts before touching any channel. Do not repoint email until the delta has verified — an inbound ticket arriving mid-load is far harder to untangle than a few extra minutes of freeze.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint channels and verify with live traffic
Switch email forwarding and MX or connector settings, update chat widgets and web forms, and re-authorise integrations. Then send real test tickets through every channel and confirm each lands, routes and triggers the right automation.
Email forwarding changes can take up to a full DNS TTL to propagate — check the TTL days in advance and lower it if needed.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Run the go/no-go and switch the agents
Walk the exit criteria with the decision-maker, call it explicitly, then move agents over with a named person on hand for the first few hours. Keep Dixa read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
-
Document the revert path for each channel
If Zendesk routing fails, agents must know how to log into Dixa and resume operations within 30 minutes.
-
Set a rollback decision deadline
Typically 5 business days after go-live. If critical issues are unresolved by this date, revert to Dixa and reschedule migration.
Dixa → Zendesk specifics
- Maintain email forwarding, not MX record changes, during the first week
- Forward incoming email to Zendesk while Dixa remains capable of receiving. Switch MX records permanently after validation.
Don't move on until
- Full historical load complete and counts matched
- Inbound channels repointed and verified with live test tickets
- Rollback decision point passed explicitly, not by default
06 Validation Prove the migration is complete, then close it out.
Objective Documented evidence that data, workflow and reporting all survived, and a signed acceptance.
Keep these open
-
Run the full reconciliation
Compare source and target on every object: total counts, counts by status, counts by group, attachment counts, and field-level spot checks on a random sample. Produce one report you can hand to an auditor.
Migration Validation Tool Reconcile Dixa and Zendesk record-for-record -
Verify field completeness, not just record counts
Re-profile the loaded data and compare null rates per field against the source profile. Matching record counts with a field that silently arrived empty is the failure mode counts alone will never catch.
Data Profiler Prove field completeness held up through the load -
Rebuild reporting and compare against baselines
Recreate your core dashboards — volume, first response time, resolution time, CSAT — and compare to pre-migration figures for the same period. Explain every variance; a changed SLA calculation is a real finding, not a rounding error.
SLA and first-response metrics are usually recalculated from the loaded timestamps, so they will differ if any timestamp mapping was approximate.
-
Test the workflow layer end to end
Fire every trigger, automation, SLA escalation, macro and notification with a live ticket. Workflow does not migrate — it gets rebuilt — so it is untested until someone has actually watched it run.
-
Confirm compliance and produce the audit trail
Re-scan the loaded data for regulated fields, confirm retention and deletion policies are configured in Zendesk, and file the evidence with your PII decisions from the audit phase.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Sign off, then decommission on a schedule
Get written acceptance against the Discovery success criteria. Keep Dixa read-only for an agreed period (30-90 days is typical), take a final archive export, and only then cancel. Diarise the decommission date so it does not quietly renew.
-
Record count reconciliation
Compare Dixa conversation count (by status, by channel) against Zendesk ticket count with imported_from_dixa tag. Tolerance: 0% variance — every conversation should be accounted for (migrated, excluded by scope, or logged as error).
-
Keep Dixa active in read-only mode for 8–12 weeks post-migration
Do not cancel the Dixa subscription at go-live. Agents should not work in Dixa, but it remains available as a reference archive and fallback.
Dixa → Zendesk specifics
- Field-level validation
- For a random sample of 100+ tickets, compare every mapped field — status, assignee, requester, timestamps, tags, custom fields — against the Dixa source. Automate this with a script that reads both APIs and diffs the values.
- Comment threading
- Verify message count per ticket and chronological ordering for a sample set. Check that created_at timestamps on comments match the source within 1 second.
- Attachment verification
- Download and verify file sizes and counts match on sample tickets. Check for broken inline image URLs.
- Agent assignment check
- Verify assigned agents in Zendesk match the original Dixa assignment. Flag any tickets assigned to the "Deactivated Agent" placeholder.
- Private note integrity
- Confirm internal notes (including wrap-up notes) migrated and are marked private. Verify they are not visible to end-users.
Don't move on until
- Full reconciliation report attached to the project record
- Reporting baselines match pre-migration figures within agreed tolerance
- Formal acceptance signed and archive retention scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Data Category What to Count
| Dixa field | Zendesk field | Notes |
|---|---|---|
| Conversations | Total count by channel (email, chat, phone, social) | Phone conversations may only contain metadata + recording URLs |
| Messages | Total messages across all conversations | Internal notes are separate from messages |
| End Users (Contacts) | Active and archived contacts | Check for duplicates by email |
| Agents | Active and deactivated agents | Deactivated agents still own historical conversations |
| Tags | Active and deactivated tags | Deactivated tags may still appear on historical conversations |
| Custom Attributes | Conversation-level and end-user-level | Note data types: text, dropdown, number, date |
| Teams & Queues | Team structure and queue routing rules | Queues map to Zendesk Groups + Views |
| Knowledge Base | Articles, categories, sections | Dixa Knowledge → Zendesk Guide is a separate migration |
| Flows | Active Flows and their routing logic | Must be rebuilt manually in Zendesk |
| Attachments | Estimate total size | Zendesk caps at 50MB per attachment for most plans |
Object Equivalent
| Dixa field | Zendesk field | Notes |
|---|---|---|
| Conversation | Ticket | 1:1 mapping. Status maps to ticket status. |
| End User | User (end-user role) | Match on email. Create if not exists. |
| Agent | User (agent role) | Must exist in Zendesk before ticket import. Map Dixa agent roles to Zendesk roles: Agent, Admin, or Light Agent (read-only, available on Suite Growth+). |
| Company / Account | Organization | Normalize name, domains, custom attributes. |
| Team | Group | Similar purpose, different routing model. |
| Queue | Group + View + Omnichannel Routing Rule | Dixa queues combine routing + visibility + priority. Zendesk separates these into three distinct configuration layers. |
| Tag | Tag | Dixa tags may have spaces and colors; Zendesk tags are plain text, lowercase with underscores. |
| Custom Attribute (Conversation) | Custom Ticket Field | Type mapping required (see below). |
| Custom Attribute (End User) | Custom User Field | Same type mapping. |
| Message (inbound) | Ticket Comment (public, author = requester) | Preserve created_at. |
| Message (outbound) | Ticket Comment (public, author = agent) | Agent must exist as Zendesk user. |
| Internal Note / Wrap-up Note | Ticket Comment (private) | Wrap-up notes live on the conversation object, not in messages. |
| Conversation Rating | Ticket Satisfaction Rating | Zendesk CSAT is binary (good/bad); Dixa may use different scales. |
| Flow | Triggers + Automations + SLA Policies + Omnichannel Routing Config | No automated migration path. Manual rebuild required. |
| Knowledge Article | Zendesk Guide Article | Separate migration project. |
Dixa Agent Roles Zendesk Roles
| Dixa field | Zendesk field | Notes |
|---|---|---|
| Admin | Admin | Full configuration access |
| Agent | Agent | Standard ticket handling |
| Agent (read-only / limited) | Light Agent or Contributor | Light Agents can add private comments but cannot be assigned tickets. Available on Suite Growth and above. Contributor role replaces Light Agent on some newer plans. |
Dixa Zendesk
| Dixa field | Zendesk field | Notes |
|---|---|---|
| conversation.id (csid) | ticket.external_id | Store for traceability and delta syncs |
| conversation.created_at | ticket.created_at | ISO 8601 — pass via Ticket Import API |
| conversation.status | ticket.status | Map: open→open, pending→pending, closed→solved |
| conversation.channel | ticket.via.channel | widget_chat→chat, phone→voice, email→email |
| conversation.requester_id | ticket.requester_id | Requires ID mapping table |
| conversation.assigned_to | ticket.assignee_id | Requires agent ID mapping |
| conversation.queue_id | ticket.group_id | Requires queue→group mapping |
| conversation.tags [] | ticket.tags [] | Lowercase, replace spaces with underscores |
| conversation.customAttributes{} | ticket.custom_fields [] | Map attribute UUID → Zendesk field ID |
| message.content.value | comment.body or comment.html_body | Handle HTML vs plain text |
| conversation_wrapup_notes | Comment (private) | Create as last private comment |
| End User displayName | User name | Direct mapping |
| End User email | User email | Primary deduplication key |
| Rating score | Satisfaction Rating | Map to good/bad binary |
Cus m Attribute Type Mapping
Dixa's custom attributes must be mapped to Zendesk custom fields with matching field types, and nested attribute hierarchies may not have direct equivalents in Zendesk's flat custom field model.
| Dixa field | Zendesk field | Notes |
|---|---|---|
| Text | Text | Direct mapping |
| Dropdown (single select) | Drop-down | Recreate all option values in Zendesk first |
| Dropdown (nested) | Drop-down | Zendesk does not support nested dropdowns — flatten to single level (e.g., "Payment - Card - Visa") |
| Number | Decimal or Integer | Choose based on whether decimals are needed |
| Date | Date | Verify format compatibility |
| Boolean | Checkbox | Map true/false |
Feature Needed Minimum Zendesk Plan
| Dixa field | Zendesk field | Notes |
|---|---|---|
| Ticket Import API | All plans (Team+) | API access required; enabled by default |
| Multiple ticket forms | Suite Professional | Suite Team supports only 1 form |
| Skills-based routing | Suite Professional | Required to replicate Dixa's agent skill/proficiency model |
| Omnichannel Routing | Suite Professional | Needed for Dixa-style real-time assignment |
| Zendesk Talk (voice) | Talk Team (add-on) | IVR and callback require Talk Professional |
| Custom SLA policies | Suite Professional | Required if Dixa uses per-queue SLA overrides |
| Zendesk Explore (custom reports) | Suite Professional | Suite Team gets pre-built dashboards only |
| Sandbox environment | Suite Enterprise | For dry-run migration testing (see below) |
| Custom agent roles | Suite Enterprise | If Dixa uses granular permission sets |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Conversation History | low | Dixa's Exports API provides full conversation and message extraction by time range, and Zendesk's Ticket Import API accepts historical tickets with timestamp preservation in batches of 100. |
| Contacts / Users | low | Contact data extracts cleanly from Dixa's API and loads into Zendesk via the Users and Organizations APIs with straightforward field mapping. |
| Tags | low | Tags transfer directly between platforms as both systems support flat tag structures with no hierarchical complexity. |
| Custom Attributes / Fields | medium | Dixa's custom attributes must be mapped to Zendesk custom fields with matching field types, and nested attribute hierarchies may not have direct equivalents in Zendesk's flat custom field model. |
| Attachments | medium | Attachments can be migrated via the API-based approach but are lost in CSV exports, and large attachment volumes significantly increase extraction time due to rate limits. |
| Call Recordings | high | Dixa's native voice recordings have no direct import path into Zendesk Talk, and preserving call recordings may require storing them externally and linking to tickets as attachments or URLs. |
| Routing Rules / Queues | high | Dixa's offer-based queue and routing logic cannot be exported or automatically converted and must be manually rebuilt as Zendesk Omnichannel Routing rules, triggers, and group assignments. |
| Flow Builder Workflows | high | Dixa's visual Flow Builder configurations with branching logic have no migration path and must be manually decomposed into 8–15 Zendesk triggers plus automations and SLA policies per complex flow. |
| IVR Configuration | high | Dixa's native IVR trees built within the Flow Builder must be completely rebuilt in Zendesk Talk's separate IVR system with its own configuration model and pricing. |
| Internal Notes | low | Internal notes can be preserved through the Ticket Import API as private comments with correct author attribution and timestamps. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Offer-Based to View-Based Routing
Dixa's real-time push-based routing using agent presence and skills must be rebuilt using Zendesk's Omnichannel Routing, unified agent statuses, skill-based assignment, and views — a fundamentally different workload distribution model requiring explicit configuration.
Flow Builder Workflow Reconstruction
Dixa's single drag-and-drop Flow Builder canvas handling queue assignment, IVR, auto-replies, priority, and escalation must be manually decomposed into Zendesk's distributed system of triggers, automations, SLA policies, macros, groups, and Talk settings with no automated conversion path.
API Rate Limit Extraction Bottleneck
Dixa's Exports API caps at 10 requests/min for conversations and 3 requests/min for messages with a 31-day query window, meaning extraction of 500K conversations can require 40+ hours of continuous API calls.
Native Voice Channel Parity
Dixa includes phone, IVR, callback, and call recording natively in every plan, while Zendesk Talk is a separate product with its own pricing and configuration layer, requiring additional setup and cost to achieve equivalent voice functionality.
Timestamp and Metadata Preservation
Preserving original created_at, updated_at, and solved_at timestamps requires use of Zendesk's Ticket Import API rather than standard creation endpoints, and CSV imports default timestamps to import date unless the API is used.
Batch Import Trigger Suppression
Zendesk's Ticket Import API does not fire triggers or automations on imported records, which simplifies historical loading but means any post-import workflow rules must be validated separately against newly created tickets.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Expiring call recording URLs
Dixa-hosted recording URLs are not guaranteed to persist. Download all recordings before migration and re-upload as Zendesk ticket attachments. Private recordings require authenticated retrieval from files.dixa.io. (docs.dixa.io)
Queue-based SLA overrides
Dixa allows per-queue SLA configurations. Each override becomes a separate Zendesk SLA policy with matching conditions (priority, group, form, tags).
Disposition/wrap-up codes
Zendesk has no native wrap-up code object. Create a custom dropdown ticket field with all disposition values pre-populated before import.
Duplicate contacts
Dixa may have contacts with the same email address. Zendesk end-users are unique by email. Resolve duplicates before import; Zendesk rejects rows when an email matches more than one user.
Internal notes in the wrong export
If you only use Dixa message_export, you lose internal notes. Pull them from the conversations export under conversation_wrapup_notes. (docs.dixa.io)
Dropdown field mapping by label vs. tag
If you map Dixa dropdown fields by display label instead of Zendesk option tags, imports fail or mis-land. (developer.zendesk.com)
Multi-channel conversations
A single Dixa conversation that spans chat and email may not map cleanly to a single Zendesk ticket channel type. Decide whether to preserve as one ticket with mixed comment types or split.
31-day export window
Dixa's Exports API limits each query to 31 days. For a 3-year history, that is ~36 sequential API calls per data type minimum. (docs.dixa.io)
50 MB attachment limit
Zendesk's attachment-based workflow has a 50 MB file limit. Large call recordings may need compression or external hosting. (developer.zendesk.com)
Agent skills
Dixa's agent skill proficiency model does not transfer. Recreate using Zendesk's Skills-based routing on Suite Professional+.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a Dixa to Zendesk migration take?
For ~100K conversations, expect 3–6 weeks total: 1 week for planning and data audit, 1–2 weeks for test migrations and field mapping, and 1–2 weeks for production migration and validation. The Dixa Exports API rate limit (3 req/min for messages) is the primary time constraint for data extraction.
Can I preserve timestamps when migrating from Dixa to Zendesk?
Yes. Zendesk's Ticket Import API (POST /api/v2/imports/tickets/create_many) lets you set created_at, updated_at, solved_at on tickets and created_at on individual comments. The standard ticket creation API does not support this — you must use the import endpoint.
Does Zendesk run triggers on imported tickets?
No. Tickets created via the Ticket Import API do not fire triggers, automations, or notifications. This is by design and prevents duplicate emails during migration. Triggers only resume on subsequent updates to imported tickets that are not in closed status.
What Dixa data cannot be migrated to Zendesk?
Dixa Flows (routing logic) have no automated migration path and must be rebuilt as Zendesk triggers, automations, and SLA policies. Call recordings require external hosting. Nested custom attribute dropdowns must be flattened. Dixa's satisfaction rating granularity may be lost since Zendesk uses binary good/bad CSAT.
What are the Dixa API rate limits for data export?
The Dixa Exports API allows 10 requests per minute for conversations and 3 requests per minute for messages, with each query limited to a 31-day window. The Dixa API v1 (for contacts, tags, etc.) allows 10 requests per second per token with a daily ceiling of 864,000 requests. Dixa does not send a Retry-After header on 429 responses.