---
title: "Dixa to Freshdesk Migration: The Complete Technical Guide"
slug: dixa-to-freshdesk-migration-the-complete-technical-guide
date: 2026-07-01
author: Roopi
categories: [Migration Guide, Freshdesk, Dixa]
excerpt: "Complete guide to migrating from Dixa to Freshdesk — object mapping, API constraints, automation redesign, telephony transition, and hard limits."
tldr: "Dixa-to-Freshdesk migration requires API-based data transfer in 31-day batches, manual Flow decomposition into three automation engines, and a separate telephony product decision. Plan 4–8 weeks."
canonical: https://clonepartner.com/blog/dixa-to-freshdesk-migration-the-complete-technical-guide/
---

# Dixa to Freshdesk Migration: The Complete Technical Guide


# Dixa to Freshdesk Migration: The Complete Technical Guide

> [!NOTE]
> **TL;DR:** A Dixa-to-Freshdesk migration is moderate complexity for the data layer but high complexity for the workflow and telephony layers. Conversation history, contacts, companies, tags, and custom fields can be migrated via the Freshdesk API. The hard parts are the routing redesign (Dixa's real-time Flow-and-Queue model must be decomposed into Freshdesk's three separate automation engines), the telephony gap (Dixa's native phone system must be replaced by Freshdesk Contact Center — a separate product with separate pricing), and the chat split (Dixa's built-in chat may require Freshchat, another separate product). Dixa's Exports API forces 31-day extraction windows with low request rates. Freshdesk API rate limits gate load speed. Realistic timeline for a typical team (40 agents, 200K conversations): 4–8 weeks including planning, automation design, data migration, and validation.

## Why teams migrate from Dixa to Freshdesk

A **Dixa-to-Freshdesk migration** moves support from a conversation-centric, real-time omnichannel platform to a ticket-centric helpdesk within the Freshworks product ecosystem. Teams switch for practical reasons: consolidating on the Freshworks suite (Freshsales CRM, Freshservice ITSM, Freshchat under one vendor), accessing Freshdesk's marketplace of 1,000+ apps, gaining granular automation control, or leveraging mature ticketing features like parent-child tickets and shared ownership on Pro+ plans.

Three architectural differences make this migration non-trivial:

- **Routing paradigm shift.** Dixa pushes conversations to agents in real-time via Flows and Queues — the agent accepts or declines. Freshdesk agents work from filtered ticket views, with tickets assigned via Dispatch'r rules, Omniroute (Enterprise only), or manual assignment. The real-time push model does not survive the transition.
- **Telephony is a separate product.** Dixa has native built-in telephony. Freshdesk does not — it requires Freshdesk Contact Center (Freshcaller), a separate Freshworks product with its own per-agent and per-minute pricing. ([dixa.com](https://www.dixa.com/omnichannel-customer-service))
- **Single Flow builder vs. three automation engines.** Dixa has one visual Flow builder for all routing logic. Freshdesk splits automation across Dispatch'r (on-create), Supervisor (time-based, runs hourly), and Observer (on-update events). A single Dixa Flow branch may require rules across all three engines.

The trade-off is clear: Freshdesk's modular ecosystem offers more granular control and broader integrations, but you lose the simplicity of Dixa's unified operating model.

## Consolidated Dixa → Freshdesk feature comparison

Before diving into the detailed mapping, this single reference table summarizes every major feature, its Freshdesk equivalent, the minimum plan required, and the gap or workaround:

| Dixa Feature | Freshdesk Equivalent | Plan Required | Gap / Workaround |
|---|---|---|---|
| Conversations | Tickets | All plans | 1:1 mapping; multi-channel source reduced to single `source` field |
| Messages (replies, notes) | Ticket Conversations (Replies, Private Notes) | All plans | Internal notes live in `conversation_wrapup_notes`, not message export |
| Contacts | Contacts | All plans | Unique by email; duplicate returns HTTP 409 |
| Companies | Companies | All plans | Auto-association by email domain available |
| Agents | Agents | All plans | Roles: Account Admin, Admin, Supervisor, Agent |
| Teams | Groups | All plans | Direct mapping |
| Queues (real-time routing) | Groups + Views + Dispatch'r + Omniroute | Enterprise (Omniroute) | No real-time queue equivalent; redesign required |
| Flow Builder (single canvas) | Dispatch'r + Supervisor + Observer | All plans (basic); Enterprise (Omniroute) | Manual decomposition across three engines |
| Tags | Tags | All plans | Case-insensitive, spaces allowed |
| Custom Attributes (conversations) | Custom Ticket Fields | All plans (basic); Pro+ (dependent dropdowns) | Type matching + pre-creation of dropdown values required |
| Custom Attributes (contacts) | Custom Contact Fields | All plans | Same type-matching requirements |
| Conversation Forms | Ticket Forms | Pro+ (multiple forms; up to 50 per account) | Recreate with field visibility rules |
| Knowledge Base | Solutions (Category → Folder → Article) | All plans (basic); Pro+ (multilingual) | Re-host images; update internal links |
| Native Telephony | Freshdesk Contact Center (Freshcaller) | Separate product/pricing | New implementation; IVR rebuild; number porting 1–3 weeks |
| In-Flow Chatbot | Freddy AI / Freshchat Bots | Freshchat (separate product) | Rebuild required; no programmatic migration |
| Native Chat Widget | Freshdesk Messaging or Freshchat | Freshdesk (basic); Freshchat (full-featured) | See Freshchat vs. Freshdesk Messaging analysis below |
| Offer-Based Assignment | Omniroute auto-assignment | Enterprise only | Agents shift to view-based work on lower plans |
| Agent Skills / Proficiency | Omniroute skill-based routing | Enterprise only | No equivalent below Enterprise |
| Real-Time Queue Metrics / Wallboard | No direct equivalent | — | Use Freshdesk Analytics or third-party dashboards |
| Callback Request Objects | No direct equivalent | — | Requires Freshcaller or third-party implementation |
| CSAT Scores | Custom ticket field values | All plans | Historical scores won't appear in native satisfaction dashboards |
| Canned Responses | Canned Responses | All plans | Verify placeholder syntax: `{{ticket.requester_name}}`, `{{ticket.id}}` |
| Analytics Dashboards | Freshdesk Analytics (rebuild required) | Pro+ (custom dashboards) | Dixa-specific metrics (offer acceptance rate, queue wait time) have no equivalent |
| Webhooks | Freshdesk Webhooks | All plans | Must be reconfigured; different event schema (see webhook section below) |
| API Integrations | Freshdesk API + Marketplace Apps | All plans | Reconfigure each integration against Freshdesk API endpoints |

## Dixa to Freshdesk object and field mapping (detailed)

Every Dixa object maps to a Freshdesk equivalent, but the mapping is not always 1:1. Getting this right determines whether agents retain historical context after cutover.

- **Dixa Conversations → Freshdesk Tickets.** Each conversation becomes one ticket. Map Dixa's open/closed states to Freshdesk's lifecycle statuses (Open = 2, Pending = 3, Resolved = 4, Closed = 5). Dixa's priority levels map to Freshdesk's numeric values (1 = Low, 2 = Medium, 3 = High, 4 = Urgent). Multi-channel Dixa conversations spanning chat and email get a single `source` field in Freshdesk — set it based on the originating channel.
- **Dixa Messages → Freshdesk Ticket Conversations.** Customer replies and agent messages map to Freshdesk public Replies. Internal notes map to Private Notes. Author attribution and timestamps must be set explicitly per message. Important: Dixa's bulk message export does not include internal notes — those are found under `conversation_wrapup_notes` in the conversations endpoint. ([docs.dixa.io](https://docs.dixa.io/docs/exports-api-guide))
- **Dixa Contacts → Freshdesk Contacts.** Freshdesk contacts are unique by email address and also support `unique_external_id`, which enables idempotent reloads if you store Dixa source IDs. Dixa's contact model is simpler — map base fields (name, email) and push the rest to custom contact fields. ([developers.freshdesk.com](https://developers.freshdesk.com/api/))
- **Dixa Companies → Freshdesk Companies.** Freshdesk can auto-associate contacts to companies by email domain, simplifying this mapping.
- **Dixa Agents → Freshdesk Agents.** Profiles must be recreated. Freshdesk roles are Account Admin, Admin, Supervisor, and Agent. Dixa's agent skill model maps to Freshdesk's Omniroute (Enterprise plan only).
- **Dixa Teams → Freshdesk Groups.** Direct mapping for routing and assignment.
- **Dixa Queues → No direct equivalent.** Dixa's real-time routing containers do not exist in Freshdesk. Redesign them as Freshdesk Groups + Ticket Views + Dispatch'r rules + Omniroute. Dixa's queue API exposes `offerTimeout`, `offerAlgorithm`, and preferred-agent settings that reflect a real-time offer model with no Freshdesk parallel. ([docs.dixa.io](https://docs.dixa.io/openapi/dixa-api/v1/queues))
- **Dixa Tags → Freshdesk Tags.** Both support tags. Freshdesk tags are case-insensitive and allow spaces.
- **Dixa Custom Attributes (conversations) → Freshdesk Custom Ticket Fields.** Type matching required: text → single-line text, dropdown → dropdown (with pre-created options). Freshdesk supports dependent dropdowns (Pro+), URL fields, and section headers. All dropdown values and dependency trees must be pre-created before import — the API rejects payloads with unrecognized values.
- **Dixa Custom Attributes (contacts) → Freshdesk Custom Contact Fields.** Same type-matching requirements apply.
- **Dixa Conversation Forms → Freshdesk Ticket Forms.** Freshdesk supports multiple ticket forms from Pro onward, with up to 50 forms per account. Recreate each Dixa form as a Freshdesk form with field visibility rules. ([support.freshdesk.com](https://support.freshdesk.com/support/solutions/articles/50000010095))
- **Dixa Knowledge Base → Freshdesk Solutions.** Three-level hierarchy: Category → Folder → Article. Supports rich text, embedded images, SEO metadata, and multilingual content (Pro+).
- **Dixa Call Recordings → Freshdesk ticket attachments** (audio files) or linked URLs in private notes. Historical recordings cannot be imported into Freshcaller's native storage.
- **Dixa CSAT Scores → Freshdesk custom ticket field values.** Historical scores will not appear in Freshdesk's native satisfaction reporting dashboards.
- **Dixa Canned Responses → Freshdesk Canned Responses.** Verify placeholder syntax compatibility — Freshdesk uses `{{ticket.requester_name}}`, `{{ticket.id}}`.

## Migration approaches for Dixa to Freshdesk

Five viable methods, each fitting different constraints:

**a) CSV Export + Freshdesk CSV Import** — Complexity: Low. Export from Dixa's admin panel and use Freshdesk's CSV import (Admin → Support Operations → Import). Works for contacts and companies. Ticket CSV import supports basic fields but does **not** import threaded reply/note history — only the initial description. Use as a supplementary method alongside API-based ticket migration.

**b) API-Based Migration (Dixa API → Freshdesk API)** — Complexity: Medium-High. The primary method for full-history migration. Dixa's Exports API streams conversations and messages for a given time frame, capped at 31 days per request. Freshdesk's v2 REST API supports ticket creation, replies, notes, contacts, and companies. Use this when you need to preserve conversation threads, timestamps, and attachments.

**c) Hybrid: Contacts via CSV + Conversations via API + KB via Solutions API** — Complexity: Medium. The pragmatic middle ground for most mid-size migrations. Import contacts and companies via CSV (fast, handles dedup by email), migrate conversation history via API, and transfer articles via the Solutions API.

**d) Custom ETL Pipeline** — Complexity: High. Build extract-transform-load scripts in Python or Node.js using both APIs. Best when you need full control over transformation logic or are combining migration with other Freshworks product onboarding (e.g., Freshsales CRM).

**e) Managed Migration Service** — Complexity: Low (for you). A provider handles extraction, mapping, transformation, and loading. Best when you have >50K conversations, complex Dixa Flows, heavy phone channel usage, or limited engineering bandwidth.

**Quick decision guide:** Small team (<10 agents, <10K conversations) → CSV + API hybrid. Must preserve full history → API-based. Heavy telephony or complex Flows → managed service. Clean break acceptable → CSV only. Enterprise (100+ agents, 500K+ conversations) → managed service.

## Migration architecture: Dixa → Transform → Freshdesk

### Dixa extraction

Dixa's Exports API uses time-bound queries — not offset/limit pagination — and no single query can span more than 31 days. Batch extraction into monthly windows: `created_after=2024-01-01&created_before=2024-01-31`, then the next month, and so on. Dixa enforces low export request rates: 10 requests per minute for conversations and 3 for messages. ([docs.dixa.io](https://docs.dixa.io/docs/exports-api-guide))

The export messages endpoint does not contain internal notes; those live in the `conversation_wrapup_notes` field of the conversations endpoint. You must also extract attachments and phone metadata (duration, recording URL, IVR path) separately — Dixa's files API supports bulk retrieval of call recordings. ([docs.dixa.io](https://docs.dixa.io/docs/files-api-guide))

**Sample Dixa Exports API conversation payload (anonymized):**

```json
{
  "id": "conv_abc123",
  "channel": "email",
  "state": "closed",
  "priority": "high",
  "created_at": "2024-03-15T09:22:11Z",
  "updated_at": "2024-03-16T14:05:33Z",
  "requester": {
    "id": "contact_xyz789",
    "email": "customer@example.com",
    "name": "Jane Doe"
  },
  "assignee": {
    "id": "agent_def456",
    "email": "agent@company.com",
    "name": "John Smith"
  },
  "queue_id": "queue_ghi012",
  "tags": ["billing", "refund"],
  "custom_attributes": {
    "order_number": "ORD-98765",
    "product_line": "Enterprise"
  },
  "conversation_wrapup_notes": "Customer requested refund for duplicate charge. Approved per policy.",
  "csat_score": 4,
  "direction": "inbound",
  "subject": "Duplicate billing charge on invoice #4521"
}
```

**Sample Dixa Exports API message payload (anonymized):**

```json
{
  "id": "msg_001",
  "conversation_id": "conv_abc123",
  "author_type": "customer",
  "author_id": "contact_xyz789",
  "body": "Hi, I was charged twice for my subscription this month...",
  "created_at": "2024-03-15T09:22:11Z",
  "channel": "email",
  "attachments": [
    {
      "id": "att_001",
      "filename": "invoice_screenshot.png",
      "url": "https://files.dixa.io/att_001/invoice_screenshot.png",
      "size_bytes": 245760
    }
  ]
}
```

Note: Internal notes are absent from the messages export. Retrieve them from the `conversation_wrapup_notes` field in the conversation payload above.

### Transformation layer

Five decisions to make early:

- **Status mapping:** Dixa's conversation states (open/pending/closed) → Freshdesk ticket statuses. Freshdesk distinguishes Resolved (4, customer can reopen) from Closed (5, terminal). Decide which to use for Dixa's closed conversations — typically Resolved for recently closed (within 30 days), Closed for historical.
- **Custom field coercion:** Coerce Dixa text attributes into Freshdesk dropdowns by matching exact string values. All dropdown values and dependency trees must be pre-created in Freshdesk before import.
- **Multi-channel source:** Dixa conversations can span multiple channels. Freshdesk has a single `source` field per ticket (1 = Email, 2 = Portal, 3 = Phone, 7 = Chat, 9 = Feedback Widget, 10 = Outbound Email). Set it based on the originating channel.
- **Phone metadata:** Store call duration, recording URL, queue wait time, and IVR path in custom ticket fields. Decide where oversized recordings will live — Freshdesk's API enforces a 20MB per-attachment limit. ([developers.freshdesk.com](https://developers.freshdesk.com/api/#create_ticket))
- **Webhook reconfiguration:** Inventory all Dixa webhooks feeding downstream systems (analytics, CRM sync, Slack notifications). Map each to Freshdesk's webhook event model, which fires on ticket creation, update, note addition, and other events. Freshdesk webhooks use a different payload schema — downstream consumers will need to be updated.

### Freshdesk load and throughput math

Freshdesk API rate limits dictate migration speed. Per the official developer documentation, current per-minute limits are: **Growth 100 req/min** (Ticket Create 50/min), **Pro 400 req/min** (Ticket Create 160/min), **Enterprise 700 req/min** (Ticket Create 280/min). These limits are applied account-wide regardless of the number of agents or API keys. ([support.freshdesk.com](https://support.freshdesk.com/support/solutions/articles/225439))

Each Dixa conversation requires approximately 1 ticket create + N reply/note creates (one per message) + attachment uploads. A conversation with 10 messages needs ~11 API calls. At Pro's 400 req/min, realistic throughput is ~35 fully-enriched tickets per minute. For a 200K-conversation migration: roughly 95 hours of continuous load time, or 5–6 days running 16 hours/day. Enterprise (700 req/min) cuts this nearly in half (~55 hours). Plan your [help desk data migration playbook](https://clonepartner.com/blog/blog/help-desk-data-migration-playbook/) timeline accordingly.

> [!WARNING]
> **Timestamp preservation is not straightforward.** Freshdesk's Create Ticket API lists `created_at` and `updated_at` as response attributes, but community reports and official forums indicate these fields have historically returned validation errors when passed as request parameters on some plans. Test timestamp override in a Freshdesk sandbox before committing to this approach. If per-ticket timestamp override is not available, the fallback is to include the original Dixa timestamp in the ticket subject or a custom field. Per-message timestamp override for replies and notes is even less documented — test this separately.

### Setting up a Freshdesk sandbox for testing

The guide repeatedly calls for sandbox testing. Here's how to access one:

- **Enterprise plan:** Freshdesk Enterprise includes a built-in sandbox environment (Admin → Account → Sandbox). This creates an isolated copy of your production instance where you can test imports, automations, and field configurations without risk. Changes can be promoted to production selectively.
- **Pro plan and below:** No native sandbox. Workarounds: (1) Create a free trial Freshdesk account as a test instance — this gives you 21 days with full feature access. (2) Request a temporary sandbox from Freshdesk sales during migration planning. (3) Use a low-tier paid instance as a dedicated test account.

Always run a subset migration (100–500 tickets) in the sandbox before committing to the full load. Validate: timestamp behavior, custom field acceptance, automation triggers, and attachment upload limits.

## Step-by-step Dixa to Freshdesk migration process

The order of operations matters. Getting it wrong causes cascading failures — orphaned tickets, missing custom fields, and validation errors. Run a test migration with a subset of data before the full load. The best sequence is: test migration → UAT with a small agent group → corrections → full migration → delta sync → cutover.

1. **Create custom fields, ticket forms, and groups in Freshdesk.** All dropdown values must be pre-created with exact options enumerated. Freshdesk rejects API calls referencing values that don't exist. Create agent accounts, connect email channels, and configure ticket forms.

2. **Migrate contacts and companies.** Contacts must exist before tickets because ticket creation requires a valid requester identified by email. If the contact doesn't exist, Freshdesk auto-creates a minimal record — bypassing your custom field population. Use `POST /api/v2/contacts` with email, name, and `custom_fields`. Freshdesk contacts are unique by email; creating a duplicate returns HTTP 409. For companies, use `POST /api/v2/companies`.

3. **Extract conversations from Dixa in 31-day batches.** Use the Exports API to stream conversations and messages. Deduplicate contacts by email address to match Freshdesk's unique constraint. Pull internal notes from the conversation payload, not the message export.

4. **Load tickets and threads.** Call `POST /api/v2/tickets` with `subject`, `description` (HTML), `email`, `status`, `priority`, `group_id`, `responder_id`, `tags`, `custom_fields`, and (if supported on your plan) `created_at` and `updated_at`. Then add replies via `POST /api/v2/tickets/{id}/reply` and private notes via `POST /api/v2/tickets/{id}/notes`. When setting routing-related fields, assign `group_id` first and `responder_id` second — the agent must belong to the assigned group.

5. **Upload attachments.** Send as multipart form data during ticket or reply/note creation. Freshdesk enforces a 20MB per-attachment limit via API. ([developers.freshdesk.com](https://developers.freshdesk.com/api/#create_ticket))

6. **Migrate knowledge base articles.** Use the Freshdesk Solutions API: `POST /api/v2/solutions/categories`, then folders, then articles with title, HTML body, status, and SEO metadata. Download and re-host embedded images — Dixa-hosted URLs will break after you close your account. Update internal links between articles.

7. **Reconfigure webhooks and integrations.** For every Dixa webhook feeding a downstream system, create the equivalent Freshdesk webhook or marketplace app integration. Freshdesk webhook events include `new_ticket`, `updated_ticket`, `new_note`, and others. The payload schema differs from Dixa — update all downstream consumers to parse Freshdesk's JSON structure.

8. **Validate.** Run record-count reconciliation comparing Dixa exports to Freshdesk creations. Verify field-level data integrity with spot checks. Check timestamp integrity on imported tickets. For phone tickets, confirm call duration and recording URLs populated the correct custom fields. Test automations independently: create test tickets matching the conditions of every Dispatch'r, Supervisor, and Observer rule to verify actions fire correctly. Keep the Dixa account active in read-only mode for 8–12 weeks post-migration as a fallback archive.

**Error handling:** Implement retry logic for 429 responses — Freshdesk returns a `Retry-After` header. Log failed records with the full error response body, which includes error code and field-level descriptions.

**Dixa extraction example (Python):**

```python
# Example: Extracting conversations from Dixa Exports API
import requests
import time

DIXA_API_TOKEN = "YOUR_DIXA_API_TOKEN"
BASE_URL = "https://exports.dixa.io/v1/conversation_export"

def extract_conversations(start_date, end_date):
    """Extract conversations in 31-day windows."""
    headers = {"Authorization": f"Bearer {DIXA_API_TOKEN}"}
    params = {
        "created_after": start_date,  # e.g., "2024-01-01T00:00:00Z"
        "created_before": end_date,   # e.g., "2024-01-31T23:59:59Z"
    }
    conversations = []
    response = requests.get(BASE_URL, headers=headers, params=params)
    if response.status_code == 200:
        conversations = response.json().get("data", [])
    elif response.status_code == 429:
        retry_after = int(response.headers.get("Retry-After", 60))
        time.sleep(retry_after)
        return extract_conversations(start_date, end_date)
    return conversations

# Respect rate limit: 10 requests/min for conversations
# Iterate in 31-day windows across your full date range
```

**Freshdesk load example (Python):**

```python
# Example: Creating a ticket with Freshdesk API
import requests
import time

url = "https://yourdomain.freshdesk.com/api/v2/tickets"
headers = {"Content-Type": "application/json"}
auth = ("YOUR_API_KEY", "X")

payload = {
    "subject": "Dixa conversation #12345",
    "description": "<div>Original conversation content...</div>",
    "email": "customer@example.com",
    "status": 5,  # Closed
    "priority": 2,  # Medium
    "tags": ["migrated-from-dixa"],
    "custom_fields": {
        "cf_dixa_conversation_id": "12345",
        "cf_original_channel": "email",
        "cf_original_created_at": "2024-03-15T09:22:11Z",
        "cf_csat_score": "4"
    }
}

response = requests.post(url, json=payload, auth=auth, headers=headers)
if response.status_code == 429:
    retry_after = int(response.headers.get("Retry-After", 60))
    time.sleep(retry_after)
elif response.status_code == 201:
    ticket_id = response.json()["id"]
    # Now add replies and notes for this ticket
    note_url = f"https://yourdomain.freshdesk.com/api/v2/tickets/{ticket_id}/notes"
    note_payload = {
        "body": "<div>Agent wrapup note: Customer requested refund...</div>",
        "private": True
    }
    requests.post(note_url, json=note_payload, auth=auth, headers=headers)
```

## How to redesign Dixa Flows as Freshdesk automations

This is the most complex and time-consuming part of the migration. Dixa Flows cannot be migrated programmatically — they must be manually decomposed and rebuilt.

Dixa has one visual Flow builder with branching, conditions, and channel-specific logic on a single canvas. Freshdesk splits automation across three separate engines:

- **Dispatch'r** fires once on ticket creation. Use for initial routing, classification, and assignment — the equivalent of Dixa Flow logic that runs when a conversation first arrives. Conditions include requester, subject, source, priority, custom fields, and business hours.
- **Supervisor** runs every hour on tickets matching conditions. It only evaluates tickets updated in the last 30 days. Use for escalation rules, SLA-based follow-ups, and stale ticket reminders. ([support.freshdesk.com](https://support.freshdesk.com/support/solutions/articles/37615))
- **Observer** fires on ticket update events (status change, reply added, reassignment). Use for notifications, re-routing, and post-update actions.

**The decomposition process:** Take each Dixa Flow and classify every decision branch as creation-time logic (→ Dispatch'r), time-based logic (→ Supervisor), or event-based logic (→ Observer). A complex Dixa Flow with 10 branches may become 5–10 Freshdesk automation rules spread across all three engines.

**Example:** A Dixa Flow that says "if conversation is email AND priority is high AND not responded in 1 hour, escalate to senior team" spans all three engines. Dispatch'r sets the initial priority and group assignment on creation. Supervisor monitors the elapsed time hourly and fires the escalation when the 1-hour threshold is passed (note: because Supervisor runs hourly, the effective escalation window is 1–2 hours, not exactly 1 hour). Observer handles the reassignment notification when the escalation fires.

**Freddy AI as a chatbot replacement:** Dixa's in-Flow chatbot paths have no direct migration equivalent. Freshdesk offers Freddy AI for auto-triage (suggesting fields, priority) and Freddy Self-service for article suggestions. For full conversational bot flows, Freshchat's bot builder is the closest replacement — it supports decision trees, API actions, and handoff to live agents. Evaluate whether your Dixa chatbot flows can be replicated in Freddy or if a Freshchat bot build is required. This is a separate implementation workstream.

The migration is an opportunity to prune automation debt. Dixa's Flow Builder makes it easy to accumulate old branches over time. Only rebuild rules that are actively used. Consider moving agent-triggered actions into Freshdesk Scenario Automations (agent macros) instead of overengineering Observer rules.

**Timeline estimate:** 1–3 weeks for a team with 5–15 active Flows. This is often the critical path.

## How to handle Dixa's telephony in the Freshdesk migration

Dixa has built-in telephony; Freshdesk does not. This is a product decision, not a configuration task. The team must choose a telephony provider:

- **Freshdesk Contact Center (Freshcaller):** The native Freshworks telephony product. Integrates tightly with Freshdesk tickets. Includes IVR, call routing, call recording, voicemail, and callback queues. Separate pricing: per-agent per-month (Growth: $18/agent/mo, Pro: $47/agent/mo, Enterprise: $83/agent/mo as of 2024) plus per-minute calling rates that vary by country. ([freshworks.com](https://www.freshworks.com/freshcaller-cloud-pbx/pricing/))
- **Third-party telephony** (Aircall, Talkdesk, RingCentral, CloudTalk): Integrates via marketplace apps or API. May be preferred if the team already has an existing telephony vendor or needs features Freshcaller doesn't cover (e.g., advanced workforce management, multi-region PSTN coverage).

**Migrating phone conversation data:** Historical Dixa phone conversations migrate as standard Freshdesk tickets — not as Freshcaller call records. Call metadata (duration, recording URL, queue wait time, IVR path) goes into custom ticket fields. Attach call recordings as audio files, or link to them in private notes if they exceed the 20MB attachment size limit. Dixa's files API supports bulk retrieval of recordings. ([docs.dixa.io](https://docs.dixa.io/docs/files-api-guide))

**Number porting** takes 1–3 weeks depending on carrier and country. Plan a temporary forwarding arrangement during the port window. Dixa's in-Flow IVR menus must be rebuilt in Freshcaller's IVR configuration — treat this as a new implementation workstream, not an import.

## How to replace Dixa's chat: Freshdesk Messaging vs. Freshchat

Dixa includes native chat as part of its unified platform. Moving to Freshdesk forces a decision between two options:

**Freshdesk Messaging (included with Freshdesk):**
- Basic chat widget embeddable on your website
- Conversations create Freshdesk tickets
- Limited bot capabilities (canned response suggestions)
- No proactive messaging, no campaigns, no advanced bot flows
- Suitable for teams that use chat for simple inbound queries

**Freshchat (separate Freshworks product):**
- Full-featured messaging platform with web, mobile, and in-app channels
- Advanced bot builder with decision trees, API actions, and NLP
- Proactive messaging and campaign capabilities
- Integrates with Freshdesk for ticket creation but runs as a separate product
- Separate per-agent pricing (Free tier available; Growth: $23/agent/mo, Pro: $59/agent/mo, Enterprise: $95/agent/mo as of 2024)
- Suitable for teams that rely heavily on chat for real-time support, sales, or onboarding

**Decision framework:** If Dixa chat accounts for >20% of your conversation volume or you rely on chatbot automation, Freshchat is likely required. If chat is a secondary channel with low volume, Freshdesk Messaging may suffice. Evaluate during discovery — this decision affects both budget and implementation timeline.

## How to migrate Dixa's knowledge base to Freshdesk Solutions

Freshdesk Solutions organizes content in a strict Category → Folder → Article hierarchy. Map your Dixa KB structure to fit this model before migrating content.

For small knowledge bases (under ~50 articles), manual recreation is sometimes faster than scripting. Above that threshold, use the Freshdesk Solutions API (`POST /api/v2/solutions/categories`, then folders, then `POST /api/v2/solutions/folders/{id}/articles`) to automate the transfer.

Embedded images in Dixa articles point to Dixa-hosted URLs, which will break when you close your account. Download all images, host them on a CDN or re-upload to Freshdesk, and update the `src` attributes in the article HTML body before import. Update internal links between articles to reflect the new Freshdesk URL structure.

If customers have bookmarked Dixa KB article URLs, set up 301 redirects from old URLs to the corresponding Freshdesk Solutions article URLs.

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

A typical migration for 40 agents and 200K conversations takes 4–8 weeks. Here is a realistic phase breakdown:

- **Discovery & planning (1–2 weeks):** Audit Dixa data, inventory Flows, assess telephony dependency, define custom field mapping, confirm target Freshdesk plan features and rate limits. Inventory webhooks and downstream integrations.
- **Freshdesk instance setup (1–2 weeks, parallel):** Create custom fields, ticket forms, groups, agent accounts, connect email channels. Provision sandbox (Enterprise) or test instance.
- **Flow decomposition & automation build (1–3 weeks):** Audit Dixa Flows, create Dispatch'r/Supervisor/Observer rules and SLA policies. Often the critical path.
- **Contact/company migration (1–3 days).**
- **Conversation history migration (3–10 days):** Dependent on volume and Freshdesk plan rate limits. Enterprise (700 req/min) completes nearly twice as fast as Pro (400 req/min).
- **Knowledge base migration (3–7 days).**
- **Webhook and integration reconfiguration (2–5 days).**
- **Telephony setup (1–3 weeks, parallel):** Freshcaller or third-party, IVR rebuild, number porting.
- **Agent training (1–2 weeks, parallel):** See agent change management section below.
- **Validation & UAT (1 week).**
- **Go-live & monitoring (1 week).**

**Risk register:**

| Risk | Likelihood | Mitigation |
|---|---|---|
| Flow decomposition takes longer than estimated | High | Start Flow audit in week 1; accept that not every branch needs replication |
| Freshdesk plan doesn't include required features | Medium | Map features to plan tiers during planning; upgrade before migration begins |
| Dixa API rate limits throttle extraction | Medium | Request temporary increase from Dixa support; run extraction off-peak |
| Reply/note timestamp preservation not supported | Medium | Test in sandbox first; fall back to formatted conversation log in description |
| GDPR/data residency conflict | Medium | Verify data processing regions for both platforms; obtain DPA from Freshworks |
| Partial migration failure requiring rollback | Low–Medium | Define rollback procedure (see section below); keep Dixa active |
| Downstream integrations break post-cutover | Medium | Inventory all webhooks/API consumers during discovery; test in staging |

## Rollback plan: what to do if the migration fails

No migration guide is complete without a rollback procedure. Define these before starting:

**Before cutover:**
- Keep Dixa active in full operational mode (not read-only) until go-live confirmation
- Tag all migrated records in Freshdesk with `migrated-from-dixa` for easy identification
- Document the exact Freshdesk API calls needed to bulk-delete imported records if required

**If a blocking issue is discovered mid-migration:**
1. **Stop the load process.** Log the last successfully migrated record.
2. **Assess scope.** Is the issue data-level (field mapping error), automation-level (rules misconfigured), or platform-level (missing feature)?
3. **Data-level fix:** Correct the transformation logic, delete affected records via `DELETE /api/v2/tickets/{id}` (rate-limited; batch carefully), and re-import the corrected subset.
4. **Automation-level fix:** Disable the misconfigured rules, correct them, and re-test. This doesn't require data rollback.
5. **Platform-level blocker:** If Freshdesk fundamentally cannot support a critical workflow, pause migration, revert to Dixa operations, and re-evaluate scope.

**Post-cutover rollback (nuclear option):**
- Freshdesk does not have a "purge all imported data" function. Bulk deletion requires iterating through tickets via the API, subject to rate limits.
- For 200K tickets: bulk deletion at Pro (400 req/min) takes ~8 hours of continuous API calls.
- This is why the sandbox test migration with a representative subset (500–1,000 tickets) is non-negotiable — it catches blocking issues before you create 200K records you might need to delete.

## GDPR and data residency considerations

Migrating customer PII between platforms triggers data protection obligations, especially for EU-based teams:

- **Data processing agreements (DPA):** Ensure a signed DPA is in place with Freshworks before any customer data is transferred. Freshworks provides a standard DPA covering GDPR compliance.
- **Data residency:** Dixa processes data in the EU (AWS eu-west-1, Ireland). Freshdesk offers data center locations in the US, EU (Germany), India, and Australia. Confirm your Freshdesk instance is provisioned in the correct region before migration. Moving data from an EU Dixa instance to a US Freshdesk instance may violate GDPR transfer requirements unless Standard Contractual Clauses (SCCs) or equivalent mechanisms are in place.
- **Right to erasure:** Any deletion requests received during the migration window must be honored in both systems. Maintain a log of deletion requests and process them in both Dixa and Freshdesk.
- **Data minimization:** Migrate only the data you need. If historical conversations older than your retention policy are not required, exclude them from extraction.
- **Transfer mechanism:** During migration, data transits through your transformation layer. Ensure this intermediate system (your ETL server) also meets security and data handling requirements — encrypt data at rest and in transit, avoid persisting PII longer than necessary.

## Agent change management: the push-to-pull transition

The shift from Dixa's offer-based routing to Freshdesk's ticket views is the single biggest operational adjustment for agents. Underestimating this causes response time spikes and agent frustration. Plan for it explicitly:

**Week 1–2 before go-live: Preparation**
- Record a 15-minute walkthrough video showing the Freshdesk agent interface: ticket views, filters, reply/note workflow, canned responses, and Scenario Automations.
- Create a quick-reference card mapping Dixa actions to Freshdesk equivalents (e.g., "Accept conversation" → "Assign to self from view," "Transfer conversation" → "Change group/agent," "Wrap up" → "Resolve ticket").
- Set up each agent's default Freshdesk views to match their former Dixa queue assignments.

**Week 1 post-go-live: Guided transition**
- Run 15-minute daily standups focused on Freshdesk workflow questions.
- Assign 1–2 power users as floor support to help agents in real time.
- Monitor first-response time and resolution time daily — expect a 20–40% spike in the first week as agents build muscle memory.

**Week 2 post-go-live: Stabilization**
- Review automation effectiveness: are Dispatch'r rules routing correctly? Are tickets piling up in views without assignment?
- If on Enterprise with Omniroute: tune round-robin and load-based assignment settings based on observed patterns.
- Reduce standups to every other day.

**Week 3+: Optimization**
- Collect agent feedback on workflow pain points.
- Refine Scenario Automations (macros) based on common agent actions.
- First-response times should be approaching pre-migration baselines by week 3.

## What happens to customers during migration?

Email customers typically see no change beyond possibly a new reply-to address. Chat customers will see a different widget (Dixa widget removed, Freshdesk or Freshchat widget added). Phone customers may experience a brief gap during number porting.

The routing model change has the biggest operational impact. In Dixa, conversations were offered to available agents immediately. In Freshdesk, tickets sit in views or are assigned via Dispatch'r/Omniroute. **First-response times often spike during the first two weeks** as agents adapt from real-time push to ticket views and group-based assignment. Configure Omniroute (if on Enterprise) or strict Dispatch'r assignment rules to minimize response lag.

**Email threading caveat:** Freshdesk threads email replies using `Message-ID` and `In-Reply-To` headers. Imported historical tickets preserve content but not the original live mail-thread identity. Customers replying to very old Dixa emails may create a new Freshdesk ticket instead of reopening the imported thread. Test this behavior before go-live. ([support.freshdesk.com](https://support.freshdesk.com/support/solutions/articles/50000011687))

To maintain data continuity during the transition, [zero-downtime help desk data migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/) strategies use delta syncs — ensuring tickets created in Dixa during the migration window are pushed to Freshdesk before final cutover.

## Edge cases and known challenges

- **Per-message timestamp preservation:** The Ticket Create API may support `created_at`, but timestamp override for individual replies via the `/reply` endpoint is inconsistently documented across API versions. Test in the Freshdesk sandbox. If unsupported, historical replies display the migration date, distorting thread chronology.
- **Duplicate contacts:** Dixa permits contacts with identical emails; Freshdesk rejects them (HTTP 409). Define a merge strategy — typically retain the most recently updated record — before bulk importing.
- **Dependent dropdowns:** Freshdesk Pro+ supports cascading dropdowns. The entire dependency tree must be defined and created in the Freshdesk UI before the API will accept payloads referencing those fields.
- **Attachment size limits:** Freshdesk's API enforces 20MB per attachment. ([developers.freshdesk.com](https://developers.freshdesk.com/api/#create_ticket)) Oversized call recordings and heavily threaded tickets with many files need special handling — consider linking to external storage (S3, GCS) in private notes.
- **Freshdesk plan feature gaps:** Omniroute (skill-based routing), custom ticket forms, sandbox environments, and higher API rate limits are tier-dependent. Map required features to plan tiers during discovery to avoid surprises mid-migration. Pro ($49/agent/mo) is the minimum for most migrations (custom forms, parent-child tickets, CSAT customization, multilingual KB). Enterprise ($79/agent/mo) adds Omniroute, sandbox, and 700 req/min. Prices as of 2024; verify current pricing.
- **Freshchat dependency:** If your team relies on Dixa's built-in chat, decide during planning whether Freshdesk's native messaging or a full Freshchat rollout (a separate Freshworks product) is the right replacement. See the Freshchat vs. Freshdesk Messaging analysis above.
- **Webhook migration:** Dixa webhooks feeding downstream systems (analytics platforms, CRM sync, Slack notifications, custom dashboards) will stop working at cutover. Inventory all webhooks during discovery and rebuild them as Freshdesk webhooks or automation-triggered API calls.

## What can't be migrated from Dixa to Freshdesk?

Be explicit about the hard limits:

- **Flows** → Must be manually decomposed and rebuilt across Dispatch'r, Supervisor, and Observer. No programmatic migration path.
- **IVR trees** → Must be rebuilt in Freshcaller or a third-party telephony platform.
- **In-Flow chatbot paths** → Must be rebuilt using Freddy AI, Freshchat bots, or a third-party bot platform.
- **Queue configuration** → Freshdesk has no real-time queues. Redesign as Groups + Views + Dispatch'r + Omniroute.
- **Offer-based assignment** → No Freshdesk equivalent. Agents adapt to view-based work or Omniroute auto-assignment.
- **Real-time queue metrics/wallboard** → No direct equivalent in Freshdesk. Consider third-party dashboards or Freshdesk Analytics custom reports.
- **Agent skills and proficiency levels** → Must be recreated in Omniroute (Enterprise only).
- **Analytics dashboards** → Must be rebuilt. Dixa metrics like offer acceptance rate and queue wait time have no Freshdesk equivalent.
- **Native telephony infrastructure** → Replaced by Freshcaller or a third-party product.
- **Native callback handling** → No direct equivalent; requires Freshcaller or third-party implementation.
- **CSAT response data** → Historical ratings can be stored in custom fields but won't appear in native satisfaction reports.
- **Webhook configurations** → Must be rebuilt using Freshdesk's webhook system with a different event and payload schema.
- **Integration configurations** → Must be reconfigured via Freshdesk Marketplace apps or custom API integrations.

## Should you migrate Dixa to Freshdesk in-house or use a service?

**In-house works when:** small volume (<10K conversations), simple routing (1–3 Flows, no IVR), minimal phone usage, small knowledge base, and available engineering time (estimate 80–160 engineer-hours for a full API migration).

**It becomes a risk when:** large history (>50K conversations), complex multi-Flow routing with IVR, heavy phone channel usage, large KB (>100 articles), tight timeline (<4 weeks), or the engineering team is needed elsewhere.

The data migration itself — extracting records from Dixa and loading them into Freshdesk — is manageable for a competent engineer. The risk compounds in three areas:

1. **Flow decomposition across three engines** is the most common time overrun. Teams assume routing logic transfers 1:1 and discover that a single Flow branch spans Dispatch'r + Supervisor + Observer.
2. **Telephony product evaluation** (Freshcaller vs. third-party) is a product decision, not a configuration task. It requires its own evaluation cycle.
3. **API rate limits and retry logic** across both Dixa extraction (31-day windows, 10 req/min) and Freshdesk loading (plan-gated limits) require production-grade error handling that quick scripts rarely include.

The useful question is not "can someone export data?" It is "can someone preserve history, create the destination schema, rebuild the routing model, handle GDPR compliance, reconfigure integrations, retrain agents, and cut over without interrupting support?"

## Frequently asked questions

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

A typical migration for a 40-agent team with 200K conversations takes 4–8 weeks including discovery, automation redesign, data migration, telephony setup, and validation. The conversation data load alone runs 3–10 days depending on volume and Freshdesk plan rate limits. Flow decomposition is often the critical path at 1–3 weeks.

### Can I preserve full Dixa conversation history in Freshdesk?

Yes. Full conversation threads — replies, private notes, and attachments — can be migrated via the Freshdesk API. Each Dixa conversation becomes one Freshdesk ticket with threaded conversations. Ticket-level timestamp preservation via created_at requires testing in a Freshdesk sandbox, as behavior varies by plan. Per-message timestamp override is less documented.

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

Dixa Flows, IVR trees, chatbot logic, queue configurations, offer-based assignment, real-time queue metrics, and native telephony infrastructure cannot be migrated programmatically. They must be manually rebuilt in Freshdesk's three automation engines and Freshcaller.

### Does Freshdesk replace Dixa's built-in phone system?

No. Freshdesk does not include telephony. You need Freshdesk Contact Center (Freshcaller) — a separate Freshworks product with per-agent and per-minute pricing — or a third-party provider like Aircall or Talkdesk.

### Can Dixa Flows be migrated to Freshdesk automations automatically?

No. Each Dixa Flow must be manually decomposed into Freshdesk's three automation engines: Dispatch'r (on-create rules), Supervisor (hourly time-based rules), and Observer (on-update event rules). A single complex Flow may require 5–10 separate Freshdesk rules across all three engines.