---
title: "Zendesk to Dixa Migration: The Complete Technical Guide"
slug: zendesk-to-dixa-migration-the-complete-technical-guide
date: 2026-07-01
author: Roopi
categories: [Zendesk, Dixa, Migration Guide]
excerpt: "Complete guide to migrating from Zendesk to Dixa — object mapping, API rate limits, Flow design, telephony transition, and what can't be moved."
tldr: "Zendesk to Dixa is moderate complexity for data (API-based, timestamps preserved) but high complexity for workflows — triggers, views, and SLAs must be rebuilt as Dixa Flows manually."
canonical: https://clonepartner.com/blog/zendesk-to-dixa-migration-the-complete-technical-guide/
---

# Zendesk to Dixa Migration: The Complete Technical Guide


A Zendesk to Dixa migration moves your team from a ticket-centric, pull-based support platform to a conversation-centric, push-based routing system. The data layer is moderate complexity — Zendesk's well-documented APIs make extraction straightforward, and Dixa's `POST /v1/conversations/import` endpoint accepts historical conversations with original timestamps. The hard parts are the workflow layer: consolidating Zendesk's triggers, automations, and views into Dixa's visual Flows and Queues, auditing your Zendesk marketplace apps against Dixa's smaller integration ecosystem, and accepting that some Zendesk capabilities — Custom Objects, Explore dashboards, multi-action macros — have no direct Dixa equivalent.

> [!NOTE]
> **TL;DR** Ticket history, contacts, tags, and custom fields extract cleanly from Zendesk and load into Dixa via API with timestamp preservation. The routing redesign (Zendesk triggers and views → Dixa Flows and Queues) is the most time-consuming task. Custom Objects (Enterprise) have no Dixa destination. Realistic timeline for ~40 agents and 200K tickets: 4–8 weeks including planning, Flow design, test migration, and validation. Simple Zendesk configurations can be migrated in-house; teams with complex trigger stacks, heavy Explore usage, or many marketplace app dependencies should use a managed service.

For a broader look at Zendesk export methods, see [How to Export Tickets from Zendesk: The Complete Step-by-Step Guide](https://clonepartner.com/blog/blog/how-to-export-tickets-from-zendesk/). For post-migration testing, see [Post-Migration QA: 20 Tests to Run After Your Help Desk Data Migration](https://clonepartner.com/blog/blog/help-desk-data-migration-qa-checklist/).

## Why Teams Migrate from Zendesk to Dixa

A Zendesk to Dixa migration replaces a multi-product, highly-configurable helpdesk with a simpler, opinionated omnichannel platform built around real-time conversation routing. Teams switch for specific architectural reasons:

- **Unified agent workspace.** Zendesk spreads work across Support, Chat, Talk, and Guide as separate products. <cite index="35-28">Dixa puts voice, email, chat, and social in one workspace with full customer history, order data, and AI suggestions visible instantly.</cite>
- **Push-based routing.** <cite index="36-5,36-6">In a ticketing system, messages sit in a shared inbox and agents pick what they work on. In Dixa, every conversation is automatically routed to the best-available agent based on skills, language, and customer priority.</cite> This eliminates cherry-picking and typically improves first-response time.
- **Native telephony.** Zendesk Talk is a separate add-on. <cite index="2-22">Dixa offers browser-based cloud telephony with IVR built in the same visual flow builder, callback instead of hold, voicemail in the same queue, call recording, transcription and number transfer across 60+ countries.</cite>
- **Configuration simplification.** Teams with 50+ Zendesk triggers and years of accumulated configuration debt use Dixa's visual Flow builder to consolidate routing logic onto a single canvas per channel. This is often as much a motivation as any feature gap.
- **AI cost positioning.** Dixa markets lower per-resolution AI costs compared to Zendesk. Treat vendor cost comparisons as positioning until you price your exact seat mix, AI usage, and telephony footprint. ([dixa.com](https://www.dixa.com/call-center-software/?utm_source=openai))

The architectural differences that make this migration non-trivial: ticket lifecycle statuses (new/open/pending/solved/closed) vs. Dixa's simpler conversation state (open/pending/closed); Zendesk's 1,500+ marketplace apps vs. Dixa's smaller ecosystem; Zendesk Explore's reporting depth vs. Dixa's more opinionated analytics; and Zendesk's webhook-firing trigger model vs. Dixa's event-based webhook subscriptions (teams that built external integrations on Zendesk trigger webhooks must rebuild those integrations using Dixa's webhook event model or custom Flow actions).

## Zendesk to Dixa Object & Field Mapping

The core data model contracts during this migration. Zendesk has more object types, more configuration layers, and more customization surface area than Dixa. The challenge is deciding what to flatten and what to leave behind.

### Objects That Map Directly

- **Zendesk Tickets → Dixa Conversations.** Each ticket becomes one conversation. Zendesk's solved and closed statuses both map to Dixa's closed — the distinction is lost. Use Dixa's conversation import endpoint for historical loads because it accepts conversation-level `createdAt`, message arrays, and message-level timestamps. ([docs.dixa.io](https://docs.dixa.io/openapi/dixa-api/v1/conversations?utm_source=openai))
- **Zendesk Ticket Comments → Dixa Messages.** Public comments become customer-facing messages; internal/private comments become Dixa internal notes. Author attribution (agent vs. end-user), timestamp, and HTML body must be preserved per message. <cite index="55-6,55-7,55-8">Dixa's import endpoint allows importing a previously created conversation. For inbound messages the author is assumed to be the requester, unless the channel supports overriding. For outbound messages the author is specified using the agentId field.</cite>
- **Zendesk End Users → Dixa Contacts.** Straightforward for core fields (name, email, phone). Dixa supports bulk creation at `POST /v1/endusers/bulk` with name, email, phone, additional emails, additional phones, and `externalId`. Zendesk custom user fields map to Dixa custom attributes on contacts. ([docs.dixa.io](https://docs.dixa.io/openapi/dixa-api/v1/chatbots/postendusers?utm_source=openai))
- **Zendesk Organizations → Dixa Organizations.** Conceptually direct, but as of mid-2025, Dixa's public API documentation does not expose a bulk organization import endpoint. Verify current API support during planning. If the API surface proves limited, store a normalized organization key on the contact and surface richer account data via Dixa Custom Cards or an external CRM. Zendesk's shared-organization ticket visibility features may behave differently in Dixa.
- **Zendesk Agents → Dixa Agents.** <cite index="5-14">Dixa's user object includes fields for id, email, displayName, role (AGENT, TEAM_LEAD, ADMIN), active, teamIds, and queueIds.</cite> Zendesk's Light Agent and Contributor roles have no Dixa equivalent — those users need a new role assignment or removal.
- **Zendesk Groups → Dixa Teams.** Similar purpose, but Dixa teams operate within the Queue/Flow model rather than trigger-based assignment.
- **Zendesk Tags → Dixa Tags.** Both support free-form tags. Zendesk tags are lowercase with underscores; verify Dixa's character restrictions before passing tags through the API.
- **Zendesk Custom Ticket Fields → Dixa Custom Attributes (on conversations).** Type matching required: text→text, dropdown→dropdown (values must be pre-created in Dixa before import). In Dixa's public custom attribute docs, contact and conversation attributes are documented as `Select` or `Text`. Zendesk field types with no Dixa equivalent — regex, lookup relationship, numeric, date, multi-select, credit card — fall back to text or must be dropped. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408838961562-About-custom-fields-and-custom-field-types?utm_source=openai))
- **Zendesk Ticket Attachments → Dixa Conversation Attachments.** Uploaded via Dixa's API. Verify Dixa's attachment size limits and supported file types early — Dixa's import docs list `.jpg`, `.jpeg`, `.png`, `.pdf`, `.doc`, `.docx`, `.pptx`, and `.xlsx`, so unusual legacy file types deserve a preflight sample.

### Objects That Require Redesign

- **Zendesk Triggers + Automations → Dixa Flows.** A team with 30–50 Zendesk triggers typically ends up with 3–8 Dixa Flows. Flows cannot be created via API — they must be built manually in Dixa's visual editor.
- **Zendesk Views → No direct equivalent.** Replaced by Dixa's queue-based push model. Dixa has conversation search for ad hoc lookups, but agents work from queues, not filtered lists.
- **Zendesk Macros → Dixa Canned Responses.** Dixa canned responses handle text insertion only. Multi-action macros (field-setting, status changes, tag additions) must be decomposed into Flow logic or manual agent steps.
- **Zendesk SLA Policies → Dixa SLA rules (within Flows or queue config).** Not a 1:1 mapping. Historical SLA compliance data does not transfer.
- **Zendesk Trigger-based Webhooks → Dixa Webhooks / Flow Actions.** Zendesk triggers that fire HTTP targets or webhooks to external systems (CRMs, ERPs, notification services) must be rebuilt. Dixa supports webhook subscriptions for conversation events, but the event taxonomy differs. Map each outbound webhook in Zendesk to either a Dixa webhook subscription or a custom API integration called from a Flow action.

### Objects with No Dixa Destination

- **Custom Objects (Enterprise)** — flatten into custom attributes (lossy — loses relational cardinality), migrate to external CRM/ERP, or discard.
- **Multi-Brand configuration** — handle via separate Flows per brand, tagged conversations, or separate Dixa workspaces.
- **Satisfaction Reasons** — store as custom attributes if needed.
- **Suspended Tickets** — no Dixa equivalent. Decide during scoping.
- **Guide community forums, custom themes, content blocks** — no Dixa equivalent. Article content transfers; presentation features do not.
- **Answer Bot / AI Agent training data** — must be rebuilt in Dixa's Flow-based chatbot logic.
- **Dynamic Content placeholders** — Zendesk's locale-switching placeholders for multi-language macros and triggers have no Dixa equivalent. Multi-language canned responses must be created as separate items per language.
- **Side Conversations** — Zendesk-specific construct for child tickets and internal collaboration threads. No clean Dixa parity; side conversation content can be appended as internal notes on the parent conversation.
- **Ticket Follower/CC history** — verify Dixa's CC model during scoping; historical follower data may not transfer.

## Migration Approaches for Zendesk to Dixa

There is no native wizard to switch from Zendesk to Dixa. You have four viable paths. Choose based on volume, complexity, and engineering bandwidth.

### API-Based Migration (Recommended for History Preservation)

Extract via Zendesk's Incremental Export API (`GET /api/v2/incremental/tickets/cursor?start_time=`), then fetch comments per ticket (`GET /api/v2/tickets/{id}/comments`). Load into Dixa via `POST /v1/conversations/import`.

The endpoint accepts a `createdAt` field on both the conversation and individual messages, which means **original Zendesk timestamps can be preserved** — this is a significant advantage over many target platforms.

**Rate limit math:** <cite index="14-30,14-31">Zendesk Incremental Exports are limited to 10 requests per minute globally. If you're running multiple export jobs, they share this limit.</cite> Each request returns up to 1,000 tickets. Standard Zendesk Support API limits are plan-based: 400 requests per minute on Professional, 700 on Enterprise. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/introduction/rate-limits/?utm_source=openai))

On the Dixa side, <cite index="1-1,1-2">rate limits are imposed per token</cite> at **10 requests per second with a daily quota of 864,000 requests**. Dixa's load rate is the typical bottleneck. For a 200K-ticket migration with an average of 5 messages per ticket, plan for 3–10 days of load time if you're making separate API calls per conversation, message, note, and tag. At 10 requests per second, you get theoretical room for 200,000 conversation imports inside the daily quota — but the moment you stop bundling history into single import payloads and start creating conversations, messages, notes, and tags as separate calls, your request count multiplies 4–6x.

**Conversation import payload limits:** Test with your largest Zendesk tickets first. Tickets with 100+ comments should be imported in a test batch early to confirm Dixa's maximum payload size per import call. If a payload is rejected for size, split the conversation's messages across the initial import and subsequent `POST /v1/conversations/{id}/messages` calls.

**Observed throughput:** In practice, sustained import rates of 6–8 requests per second are more realistic than the 10 req/s ceiling due to payload serialization, network latency, and error-retry cycles. For a 200K-ticket migration, budget 4–7 days of continuous load time for conversations alone.

### Zendesk Full Export + API Load (Hybrid)

Use Zendesk's admin-panel full JSON export (Admin Center → Account → Data export) for one-time bulk extraction. Parse JSON locally, transform, then load via Dixa's API. Useful when you want a clean snapshot without writing incremental export code.

> [!WARNING]
> If you use Zendesk Full JSON export, test your largest tickets first. The export is NDJSON format and is recommended for accounts over 200,000 tickets. However, tickets over 1 MB can be exported without comments, and a single ticket can contain up to 5,000 comments. The export also omits records updated within six minutes of the export start. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408886165402-Exporting-ticket-user-or-organization-data-from-your-account?utm_source=openai))

### Clean-Break Migration

Export Zendesk data as an archive for compliance. Set up Dixa from scratch. Don't import historical tickets. Best when: historical data is low-value, the Zendesk configuration is so complex that starting clean is faster, or the team views the Dixa move as a reset. Keep Zendesk in read-only mode for reference during stabilization.

### Managed Migration Service

A provider handles extraction, mapping, transformation, loading, and advises on Flow design and integration gap analysis. Best for: >50K tickets, complex trigger stacks, Zendesk Talk number porting, tight timelines, or limited engineering bandwidth.

**Which approach fits your team:**

| Scenario | Recommended approach |
|---|---|
| Small team (<10 agents, <10K tickets), simple config | API-based DIY or clean break |
| Mid-size (10–50 agents, 10K–200K tickets) | API-based with contacts via bulk import, Flows built manually |
| Enterprise (100+ agents, 500K+ tickets, custom objects) | Managed service |
| Must preserve full history with timestamps | API-based migration |
| Limited engineering bandwidth | Managed service or clean break |
| GDPR / EU data residency requirements | Verify Dixa data residency before committing; consider managed service for compliance documentation |

## Step-by-Step Zendesk to Dixa Migration Process

The order of operations matters. Get it wrong and Dixa's API will reject records with missing references — conversations require a valid `requesterId` (Dixa contact), so contacts must exist first.

**Step 1: Audit Zendesk configuration.** Count triggers, automations, views, ticket forms, custom fields, custom objects, marketplace apps, and Guide articles. Catalog every Zendesk trigger that fires a webhook or HTTP target to an external system — these are active integrations that will break at cutover. This determines scope and timeline. Use [How to Export Tickets from Zendesk](https://clonepartner.com/blog/blog/how-to-export-tickets-from-zendesk/) as your extraction checklist.

**Step 2: Set up Dixa workspace.** Create teams, agent accounts, custom attributes (with all dropdown values enumerated), and conversation forms. **All custom attributes must exist in Dixa before importing any conversation data** — Dixa will reject records with attribute values that don't match predefined options. Dixa's Flow definitions and KB structure are set up in the UI, not via API, so plan for manual configuration. ([docs.dixa.io](https://docs.dixa.io/docs/tutorial-create-an-api-token?utm_source=openai))

**Step 3: Extract from Zendesk.** Use the Incremental Export API for tickets, per-ticket comment fetch for messages, and the Users/Organizations APIs for contacts. For one-time bulk pulls, the Full JSON export is practical; for cutover deltas, use Incremental Exports.

```python
# Zendesk: Incremental ticket export (cursor-based)
import requests

url = "https://{subdomain}.zendesk.com/api/v2/incremental/tickets/cursor"
params = {"start_time": 1609459200}  # Unix timestamp
headers = {"Authorization": "Bearer {token}"}

while True:
    resp = requests.get(url, params=params, headers=headers)
    data = resp.json()
    for ticket in data["tickets"]:
        process_ticket(ticket)
    if data["end_of_stream"]:
        break
    url = data["after_url"]
    params = {}
```

**Step 4: Load contacts and organizations first.** Push Zendesk End Users to Dixa Contacts using `POST /v1/endusers/bulk`. Map custom user fields to Dixa custom attributes. Do not start conversation imports until you have a stable source-to-target contact ID map. Persist every Zendesk user ID → Dixa contact UUID mapping in a local database or CSV — you will need it for conversation import, rollback, and post-migration validation.

**Step 5: Transform and load conversations.** Map Zendesk tickets to Dixa conversations using `POST /v1/conversations/import`. Set original `createdAt` timestamps, map public comments to inbound/outbound messages, and map internal notes.

```python
# Dixa: Import a historical conversation with messages
import requests

payload = {
    "genericChannelName": "ZendeskImport",
    "requesterId": "<dixa-contact-uuid>",
    "direction": "Inbound",
    "createdAt": "2024-03-15T10:30:00.000Z",
    "messages": [
        {
            "content": {"value": "Original customer message", "_type": "Text"},
            "attachments": [],
            "createdAt": "2024-03-15T10:30:00.000Z",
            "_type": "InboundImport"
        },
        {
            "content": {"value": "Agent reply", "_type": "Text"},
            "agentId": "<dixa-agent-uuid>",
            "attachments": [],
            "createdAt": "2024-03-15T11:00:00.000Z",
            "_type": "OutboundImport"
        }
    ]
}

resp = requests.post(
    "https://dev.dixa.io/v1/conversations/import",
    headers={"Authorization": "Bearer <token>", "Content-Type": "application/json"},
    json=payload
)
```

Dixa's public docs currently show import channels of `email` and `genericapimessaging` — test how old Zendesk phone and chat records will be represented before you promise native channel parity. ([docs.dixa.io](https://docs.dixa.io/openapi/dixa-api/v1/conversations?utm_source=openai))

**Step 6: Apply tags and custom attributes** via Dixa's Tags and Custom Attributes APIs. Dixa's bulk tag endpoint can create missing tags on the fly. Add private comments via `POST /v1/conversations/{conversationId}/notes` or the bulk notes endpoint.

**Step 7: Upload attachments.** Extract attachments from Zendesk URLs and push them to Dixa. Verify attachment size limits and supported file types before starting the bulk load. Download all Zendesk-hosted attachments during extraction — these URLs become inaccessible when the Zendesk account is deactivated.

**Step 8: Migrate knowledge base articles** using Zendesk's Help Center API (`GET /api/v2/help_center/articles`) for extraction. For multi-language articles, use `GET /api/v2/help_center/{locale}/articles` to retrieve each translation. Images referenced in Zendesk article bodies are hosted on Zendesk's CDN — these URLs will break when you close Zendesk. Download the images and re-host them. Zendesk dynamic content placeholders (`{{dc.placeholder_name}}`) used in articles and macros will not resolve in Dixa — replace them with static text or create per-language versions. Set up 301 redirects from old Guide URLs to new Dixa KB URLs.

**Step 9: Validate.** Record-count reconciliation, field-level spot checks, timestamp verification, and Flow testing. Verify that imported conversations show original Zendesk ticket dates. Run UAT with 2–3 agents before full go-live.

**Error handling:** Implement retry logic with exponential backoff for 429 responses on both sides. Common Dixa import errors include `400` for missing `requesterId` (contact doesn't exist), `400` for invalid custom attribute values (dropdown value not pre-created), and `413` or payload rejection for oversized conversation imports. Log every failed record with the full request payload and error response. Persist every source-to-target ID mapping. Log Dixa `partialErrors` as first-class validation failures, not harmless warnings.

**Rollback considerations:** Dixa does not expose a bulk conversation delete endpoint. If a migration batch loads corrupted data, you must either delete conversations individually via the API (impractical at scale) or coordinate with Dixa support for a workspace-level data reset. This means test migrations should use a separate Dixa workspace, and production loads should be validated in small batches (1,000–5,000 conversations) before running the full import.

```bash
# Key API endpoints at a glance
# Zendesk extraction
GET /api/v2/incremental/tickets/cursor?start_time=1719792000
GET /api/v2/tickets/{ticket_id}/comments
GET /api/v2/ticket_fields
GET /api/v2/help_center/articles
GET /api/v2/help_center/{locale}/articles  # multi-language

# Dixa loading
POST /v1/endusers/bulk
POST /v1/conversations/import
POST /v1/conversations/{conversationId}/notes/bulk
PATCH /v1/conversations/{conversationId}/custom-attributes
POST /v1/conversations/{conversationId}/tags/bulk
```

## Delta Migration and Cutover Strategy

The gap between your test migration and go-live cutover requires a delta strategy. Tickets created or updated after your initial extraction must be captured and loaded before switching channels.

**Delta process:**

1. Record the `end_time` value from your initial Incremental Export cursor
2. At cutover, run a new Incremental Export starting from that `end_time` to capture all tickets created or updated since the initial pull
3. For each delta ticket, check your source-to-target ID map: if the ticket was already imported, update the existing Dixa conversation (add new messages/notes via `POST /v1/conversations/{id}/messages`); if new, import as a new conversation
4. Deduplication key: use the Zendesk ticket ID stored as `externalId` or a custom attribute on the Dixa conversation to prevent double-imports

**Cutover sequence:**

1. Run delta export from Zendesk (typically covers 1–3 days of activity)
2. Load delta conversations into Dixa
3. Switch email forwarding rules to Dixa
4. Switch chat widget from Zendesk to Dixa
5. Port phone numbers (if not already completed)
6. Disable Zendesk triggers that send outbound communications to prevent duplicate responses
7. Set Zendesk to read-only (downgrade agents to end-user role or suspend accounts)

Plan the cutover for a low-traffic window. Email cutover is near-instant (DNS MX or forwarding change); chat widget swap takes a deploy cycle; phone porting is carrier-dependent (1–3 weeks, arranged in advance).

## How to Redesign Zendesk Triggers and Automations as Dixa Flows

This is the hardest and most time-consuming part of the migration. It cannot be automated — Flows must be built manually in Dixa's visual editor.

Zendesk uses a flat list of independent triggers (event-driven) and automations (time-driven) that execute in order and can interact in complex, sometimes conflicting ways. Dixa uses visual Flows — single-canvas routing programs per channel with branching, conditions, queue assignments, IVR menus, and escalation logic. Zendesk distributes business rules across many independent objects; Dixa consolidates them onto a single canvas.

**The consolidation process:**

1. Export all active Zendesk triggers and automations (use `GET /api/v2/triggers/active` and `GET /api/v2/automations/active`)
2. Group by purpose: routing, SLA enforcement, notification, escalation, tagging, auto-reply, webhook/integration firing
3. Map each group to a Dixa Flow. A Zendesk instance with 40 triggers and 10 automations typically produces 4–8 Dixa Flows
4. For each Zendesk view agents actively use, decide: does it become a Dixa queue (for active routing) or is it replaced by Dixa's conversation search (for ad hoc lookups)? Agents don't need 15 views — they need 3–5 well-configured queues
5. For each Zendesk trigger that fires a webhook to an external system, decide: rebuild as a Dixa webhook subscription, call the external API from a Flow action, or move the integration to a middleware layer (Zapier, Make, or custom service)

**The simplification opportunity:** Many Zendesk instances have accumulated trigger debt — triggers created years ago, triggers that conflict, triggers for edge cases that no longer exist. List all triggers, identify which are still active and necessary, and only rebuild the ones that matter. Rely on Dixa's native routing intelligence (skill-based routing, queue priority) instead of building manual assignment rules. This is a simplification exercise, not a 1:1 porting effort.

[For PMs] Budget 1–3 weeks for the trigger audit and Flow design phase. This is often the critical path — teams estimate days and spend weeks.

For a deeper framework on this step, see [Your Help Desk Data Migration's Secret Saboteur: Automations, Macros, and Workflows](https://clonepartner.com/blog/blog/how-to-migrate-automations-macros-workflows/).

## How to Migrate Zendesk Talk and Guide

### Zendesk Talk → Dixa Native Telephony

Dixa's native telephony is often a key reason teams migrate. <cite index="2-21,2-22">Voice is the genuine standout. It's browser-based cloud telephony with no hardware: IVR built in the same visual flow builder, callback instead of hold, voicemail in the same queue as everything else.</cite>

- **Number porting:** Phone numbers in Zendesk Talk must be ported to Dixa's telephony provider. Plan 1–3 weeks depending on carrier and country. Arrange temporary call forwarding from the old number to Dixa during the port to avoid missed calls. Dixa supports number transfer across 60+ countries, but verify your specific country's porting timeline with Dixa's telephony team during planning.
- **IVR rebuild:** Zendesk Talk IVR menus are rebuilt in Dixa's Flow builder. Map each Zendesk IVR branch to a Dixa phone Flow path. Document the exact IVR tree from Zendesk Talk before deactivation — Zendesk does not export IVR configuration via API.
- **Historical call recordings:** Export from Zendesk Talk via the Talk API (`GET /api/v2/channels/voice/calls/{call_id}/recording`) before migration. Recordings can be stored as file attachments on migrated conversations but will not appear in Dixa's native call recording interface. Do not assume historical Talk analytics become native Dixa voice history without explicit data warehousing. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408882914842-Can-I-download-call-recordings?utm_source=openai))
- **Call metrics:** Historical call data in Zendesk Explore does not transfer. Export and archive if needed for compliance or reporting continuity.

### Zendesk Guide → Dixa Knowledge Base

Use the Zendesk Help Center API (`GET /api/v2/help_center/articles`) to extract article titles, HTML bodies, labels, and publish statuses. Dixa supports internal and external knowledge, multi-language content, custom domains, and separate brand knowledge.

**Multi-language handling:** Zendesk Guide stores translations as separate locale-specific versions of each article. Extract all locales using `GET /api/v2/help_center/{locale}/articles`. Dixa's knowledge base supports multi-language content — create the equivalent language versions during import. Zendesk dynamic content placeholders (`{{dc.placeholder}}`) used for locale-switching in macros, triggers, and articles will not resolve in Dixa and must be replaced with static per-language content.

Images referenced in Zendesk article bodies are hosted on Zendesk's CDN — these URLs will break when you close Zendesk. Download the images and re-host them in Dixa. Set up 301 redirects from old Guide URLs. Zendesk Guide community forums, custom themes, and content blocks have no Dixa equivalent and will not transfer. ([developer.zendesk.com](https://developer.zendesk.com/api-reference/help_center/help-center-api/articles/?utm_source=openai))

## GDPR and Data Residency Considerations

If your team operates under GDPR or has data residency requirements, address these before migration:

- **Zendesk data centers:** Zendesk offers EU data hosting (Frankfurt) for eligible plans. If your Zendesk instance uses EU hosting, confirm that Dixa can match this. Dixa is headquartered in Copenhagen and processes data within the EU, but verify the specific data center location and any sub-processor arrangements with Dixa's security team during planning.
- **Data in transit during migration:** During the migration window, customer data is extracted from Zendesk, transformed on your infrastructure (or a migration provider's), and loaded into Dixa. Ensure the transformation step occurs within an appropriate jurisdiction and that data is encrypted in transit (TLS) and at rest.
- **Right to erasure:** If you maintain Zendesk in read-only mode post-migration, GDPR deletion requests must be executed in both systems until the Zendesk instance is fully decommissioned.
- **Data Processing Agreements:** Ensure DPAs are in place with Dixa before loading any personal data. If using a managed migration service, a DPA with the migration provider is also required.

## How Long Does a Zendesk to Dixa Migration Take?

<cite index="35-11">Most brands migrate from Zendesk to Dixa in 2–4 weeks.</cite> That timeline covers data migration and basic setup. For teams with complex Zendesk configurations — heavy trigger stacks, custom objects, Zendesk Talk, or large Guide knowledge bases — expect 4–8 weeks total. Discovery, Flow design, and UAT usually consume more calendar time than the raw data load.

[For PMs] **Sample timeline (40 agents, 200K tickets):**

- **Discovery & planning:** 1–2 weeks (audit Zendesk config, scope migration, run integration gap analysis, verify Dixa data residency)
- **Dixa workspace setup:** 1–2 weeks (teams, agents, custom attributes, conversation forms — parallel with Flow design)
- **Flow design & build:** 1–3 weeks (trigger audit, Flow creation, SLA config, queue setup, webhook integration rebuild — often the critical path)
- **Data migration:** 1–2 weeks (contacts first, then conversations, then KB articles; budget 4–7 days for conversation load at sustained 6–8 req/s)
- **Telephony migration:** 1–3 weeks (number porting, IVR rebuild — parallel track)
- **Validation & UAT:** 1 week
- **Delta migration & cutover:** 1–2 days
- **Go-live & monitoring:** 1–2 weeks (extra time for agent adjustment to push-based model)

**Key risks:**

- **Missing marketplace app in Dixa.** Dixa's integration ecosystem is significantly smaller than Zendesk's 1,500+ apps. Run a full app audit during planning — discovering a missing integration post-go-live causes rollback pressure. For each critical Zendesk app, determine: does Dixa have a native integration, can it be replicated via Dixa's API or Custom Cards, or does it require a middleware solution?
- **Flow design overrun.** Trigger debt in Zendesk makes this take longer than expected. Dedicate a person.
- **Agents resist push-based model.** Run training sessions before go-live. The shift from view-based work selection to queue-based routing is the main adoption risk, not the data mechanics.
- **Explore reports can't be replicated.** Dixa's analytics are simpler and more opinionated. Audit critical reports during planning; supplement with a BI tool (Looker, Metabase, or similar) connected to Dixa's data export if needed.
- **No bulk rollback.** Dixa lacks a bulk conversation delete endpoint. A corrupted import batch is difficult to reverse. Mitigate by running test migrations in a separate workspace and validating small production batches before full load.
- **Webhook integrations break at cutover.** Every Zendesk trigger that fires a webhook to an external system stops working when Zendesk is deactivated. Map and rebuild these integrations in Dixa before cutover, not after.

## What Can't Be Migrated from Zendesk to Dixa?

Be clear about what doesn't transfer:

- **Triggers and automations** → must be consolidated and rebuilt as Dixa Flows manually
- **Views** → no equivalent; replaced by Dixa's push-based queue model
- **Custom Objects (Enterprise)** → no Dixa equivalent; data must be flattened, migrated elsewhere, or discarded
- **Explore dashboards and custom reports** → must be rebuilt in Dixa analytics or supplemented with external BI
- **Answer Bot / AI Agent training data** → must be rebuilt in Dixa's chatbot logic (Mim)
- **Guide community forums, custom themes, content blocks** → no Dixa equivalent
- **Marketplace app configurations** → must be reconfigured with Dixa's native integrations or rebuilt via API
- **Zendesk Talk IVR configuration** → must be rebuilt in Dixa's Flow builder
- **Macro field-setting actions** → Dixa canned responses are text-only
- **Light Agent / Contributor roles** → no equivalent role in Dixa
- **Satisfaction reasons** → no Dixa equivalent
- **Historical call recordings in Talk's native interface** → exportable as attachments, but won't appear in Dixa's recording system
- **Suspended tickets** → no Dixa equivalent
- **Side conversations** → Zendesk-specific construct without clean Dixa parity; content can be preserved as internal notes
- **Ticket follower/CC history** → verify Dixa's CC model during scoping
- **Dynamic content placeholders** → must be replaced with static per-language text
- **Historical SLA compliance data** → does not transfer; SLA tracking restarts in Dixa
- **Trigger-based webhook configurations** → must be rebuilt using Dixa webhooks or Flow actions

## What Happens to Customers During Migration?

[For customer success] If channels are cut over at go-live (not mid-migration), customers typically see no downtime on email. Chat users will see a different widget (swap Zendesk for Dixa). Phone users may experience a brief gap during number porting — mitigate with temporary call forwarding.

Dixa's push-based model typically results in faster first-response times — conversations are offered to available agents immediately rather than sitting in views. Track first-response time before and after migration to quantify the improvement.

If customers bookmarked Zendesk Guide URLs, those will break. Set up 301 redirects to new Dixa KB URLs. Audit your top 50 Guide pages by traffic in Google Analytics and verify redirects for each.

The shift from views to queues is the biggest agent adjustment. Plan 1–2 weeks of extra support and feedback loops post-go-live. Keep Zendesk in read-only mode for 8–12 weeks as a fallback (remember to process GDPR requests in both systems during this period). The normal pattern is to keep Zendesk live during extraction and testing, run a final delta with Incremental Exports near cutover, switch channels, then keep Zendesk read-only during stabilization.

To understand the broader implications of keeping support running during this transition, review our guide on [Zero-Downtime Help Desk Data Migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/).

## Should You Migrate Zendesk to Dixa In-House or Use a Service?

**In-house works when:** small volume (<10K tickets), simple Zendesk configuration (few triggers, 1–2 ticket forms, minimal custom fields), no custom objects, no Zendesk Talk, available engineering time (estimate 80–120 engineering hours for a clean API-based migration at this scale), and the team is comfortable with a clean-break approach if history import proves complex.

**It doesn't work when:** large history, complex trigger stacks (20+ triggers), multiple ticket forms, custom objects, heavy Explore usage, many marketplace app dependencies, Zendesk Talk with number porting, tight timeline, GDPR compliance requirements you're unsure how to handle during transit, or the engineering team is needed elsewhere.

**The hidden costs of DIY:** The trigger-to-Flow redesign is the most common time overrun. The integration gap analysis is the second — discovering a missing integration post-go-live causes rollback pressure. Reporting gaps surface during the first reporting cycle and create stakeholder friction. The lack of bulk rollback in Dixa means a failed production import is expensive to clean up. If the data is straightforward but the operating model is tangled, treat it as an architecture project, not a ticket export. That is where a migration service earns its keep.

ClonePartner has completed 1,500+ data migrations across helpdesk, CRM, HRIS, and ATS platforms. For Zendesk-to-Dixa migrations, the service handles full ticket history migration (including comments, attachments, custom fields, and timestamp preservation), contact and organization mapping, tag normalization, knowledge base article migration, delta/cutover management, and advisory on trigger-to-Flow redesign and Zendesk Talk telephony transition. We manage the API rate limits, rollback planning, and data residency compliance so your engineering team doesn't have to.

> Planning a Zendesk to Dixa migration? ClonePartner handles the full data migration — tickets, contacts, attachments, timestamps, tags, and KB articles — so your team can focus on Flow design and agent training. Book a free 30-minute scoping call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### How long does a Zendesk to Dixa migration take?

Most teams complete the migration in 2–4 weeks. Complex instances with heavy trigger debt, custom objects, Zendesk Talk number porting, or large Guide knowledge bases should plan for 4–8 weeks including planning, Flow design, data migration, and validation.

### Can Zendesk ticket history be preserved in Dixa?

Yes. Dixa's conversation import API (POST /v1/conversations/import) accepts historical conversations with original createdAt timestamps and full message threading, preserving author attribution and chronological order.

### What data can't be migrated from Zendesk to Dixa?

Triggers, automations, views, custom objects, Explore dashboards, Guide community forums, macro field-setting actions, Light Agent roles, and suspended tickets do not transfer. They must be rebuilt, redesigned, or discarded.

### Can Zendesk triggers and automations be migrated to Dixa Flows?

Not directly. Zendesk triggers and automations must be consolidated into Dixa Flows manually using the visual Flow editor. A Zendesk instance with 40 triggers and 10 automations typically maps to 4–8 Dixa Flows.

### Does Dixa replace Zendesk Talk for phone support?

Yes. Dixa includes native built-in telephony with IVR, call routing, voicemail, callback, and call recording across 60+ countries. Phone numbers must be ported from Zendesk Talk's carrier, which takes 1–3 weeks.