Migrating Freshdesk to Dixa requires transforming tickets into conversations, managing two different API rate-limit models, and rebuilding automations manually. Most mid-market migrations complete in 1–3 weeks.
There is no native migration path from Freshdesk to Dixa, and no third-party tool has a verified, production-tested Dixa destination connector as of June 2025. The fundamental challenge is a structural data model mismatch: Freshdesk is ticket-centric (numbered tickets containing child conversations), while Dixa is conversation-centric (UUID-identified threads containing messages and internal notes). Automations, macros, SLA policies, canned responses, and company objects have no direct equivalents in Dixa and must be rebuilt or restructured manually. Custom ETL pipelines or managed migration services are required for any migration involving more than a trivial number of records, with particular attention to attachment re-hosting, status value normalization, and Dixa's limited historical import channel support (email and genericapimessaging only).
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
TL;DR — Freshdesk to Dixa Migration
Migrating from Freshdesk to Dixa is a high-complexity project because the two platforms use fundamentally different data models: Freshdesk is ticket-centric, Dixa is conversation-centric. A typical migration for 50,000–200,000 tickets takes 1–3 weeks including mapping, testing, and cutover. The biggest risks are losing threaded message history due to the structural mismatch, and the fact that Dixa's historical import endpoint only supports email and genericapimessaging channel types — phone and social history require normalization or sandbox testing. Freshdesk automations, macros, SLA policies, and canned responses cannot be migrated and must be rebuilt manually. The Dixa API requires the Ultimate or Prime plan; the Growth plan does not include API access. Teams with fewer than 10,000 tickets and no custom fields can attempt a scripted DIY migration (80–120 engineer-hours). For anything larger or with complex relationships, a managed service ($5,000–$15,000 for 50K–200K tickets) or custom ETL pipeline is the safer path. Written June 2025. Targets Freshdesk API v2 and Dixa API v1.
Critical Freshdesk extraction gotcha
GET /api/v2/tickets/{id}?include=conversations returns only up to 10 conversations per ticket. For full threads, always use the dedicated endpoint: GET /api/v2/tickets/{id}/conversations. Avoid deep pagination past page 500. Invalid requests still count toward the account-wide rate limit — honor Retry-After headers on 429 responses. (developers.freshdesk.com)
Dixa API access requires the Ultimate or Prime plan
The Growth plan ($89/agent/month) does not include API access. The Ultimate plan starts at $139/agent/month (annual billing) and the Prime plan at $179/agent/month. All Dixa plans require a 7-seat minimum ($973/month minimum on Ultimate). If your Dixa instance is on the Growth plan, you cannot use the API for migration — you will need to upgrade before beginning any API-based work. (dixa.com/pricing)
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 Freshdesk
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 Dixa can hold your support model
Walk your current workflow through Dixa: 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 Freshdesk → Dixa 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.
Freshdesk → Dixa specifics
- Omnichannel routing architecture
- Dixa routes phone, email, chat, and social conversations through a single intelligent routing engine rather than treating each channel as a separate queue. For mid-market support teams handling 8,000+ conversations per month, this eliminates channel silos.
- Agent experience
- Dixa's single-screen workspace surfaces customer context, order data (via Shopify/Magento integrations), and conversation history without tab-switching.
- Built-in telephony
- Freshdesk requires Freshcaller as a separate add-on. Dixa includes browser-based VoIP as a first-class channel on all plans.
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 Freshdesk 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 Freshdesk 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 Freshdesk 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
Freshdesk → Dixa specifics
- Freshdesk Companies
- You lose the hierarchical contact-to-company relationship.
- Multi-product support
- Freshdesk supports multiple products with separate email inboxes. Dixa handles this through separate Queues and contact endpoints, which requires restructuring. Map Freshdesk product_id to the correct Dixa Queue.
- Parent-child ticket relationships
- Freshdesk's associated_tickets_list has no direct equivalent. Dixa supports linking conversations via PUT /v1/conversations/{id}/link, but the relationship semantics differ.
- Sandbox instances share the same API rate limits
- as production — plan your test migration load accordingly.
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 Freshdesk → Dixa 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 Freshdesk → Dixa 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 Dixa 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.
Freshdesk → Dixa specifics
- Status mapping
- Freshdesk ticket status is numeric (2=Open, 3=Pending, 4=Resolved, 5=Closed) and often customized with additional values beyond 5. Dixa conversations use state values like Open, Pending, AwaitingPending, and Closed. Build an explicit lookup table that includes any custom status values your Freshdesk instance has added. (developers.freshdesk.com)
- Custom fields
- Freshdesk custom_fields can include nested/dependent dropdown fields and date inputs using YYYY-MM-DD. Dixa custom attributes support Text and Select types. Flatten nested dropdowns into separate attributes or concatenate values before loading. Standardize all date fields to ISO 8601. (developers.freshdesk.com)
- Company relationships
- Freshdesk contacts can belong to a primary company and additional companies. Dixa has no built-in company object, so these relationships must be stored as custom attributes on End Users. If company relationships matter for routing or reporting, validate the destination model in a sandbox before committing to a build.
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 Dixa sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Dixa 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 Dixa'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.
-
Contact your Dixa account manager
and request a sandbox organization. This is typically provisioned as a separate Dixa organization with the same plan features as your production instance.
Freshdesk → Dixa specifics
- Data in sandbox is fully isolated
- from production. After testing, you can request sandbox data deletion before running the production migration.
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 Dixa, 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 Freshdesk 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 Dixa'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 Freshdesk 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 Freshdesk read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
-
Delete imported Dixa conversations
via DELETE /v1/conversations/{id} if you need a clean slate before re-running. For bulk deletion, script against your migration log (which should contain all created conversation UUIDs).
Freshdesk → Dixa specifics
- Freshdesk data is never modified
- by the extraction process — your source system remains intact.
- Revert DNS and email routing
- from Dixa contact endpoints back to Freshdesk inboxes. This can be done in minutes if you pre-document the original DNS records.
- Re-run the migration
- after fixing transformation bugs. Using externalId on every imported record makes re-runs idempotent — you can skip already-imported records.
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 Freshdesk and Dixa 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 Dixa, 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 Freshdesk 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.
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.
Freshdesk Dixa Object Mapping
| Freshdesk field | Dixa field | Notes |
|---|---|---|
| Ticket | Conversation | One-to-one, but Dixa conversations have no numeric ticket ID. Status values differ (Freshdesk uses integers 2–5; Dixa uses open/closed/followup). Store legacy ticket ID in externalId or a custom attribute. |
| Conversation (reply/note) | Message / Internal Note | Public replies → Dixa Messages. Private notes → Dixa Internal Notes via separate POST /v1/conversations/{id}/notes call. Preserve chronological order. |
| Contact | End User | Freshdesk contacts have company_id; Dixa End Users have no native company field — use custom attributes. |
| Company | (No direct equivalent) | Must be stored as a custom attribute on End Users or handled via an external CRM integration. |
| Agent | Agent | Map by email, not numeric ID. Dixa has 3 built-in roles (Administrator, Agent, Team Lead/Supervisor) — no custom roles. Must be provisioned before importing conversations. |
| Group | Queue + Team | Requires splitting: create a Queue for routing and a Team for organizational grouping. |
| Tag | Tag | Create via POST /v1/tags before importing conversations. Apply to conversations via POST /v1/conversations/{id}/tags/{tagId}. |
| Custom Field | Custom Attribute | Freshdesk supports dropdown, checkbox, date, number, text, and nested fields. Dixa custom attributes are simpler — verify type compatibility before migration. |
| Attachment | Attachment (URL-based) | Dixa's import endpoint accepts attachments as {"url": "...", "prettyName": "..."}. Source URLs must be accessible at import time. If Freshdesk URLs require auth or expire, re-host to S3/GCS first. |
| Satisfaction Rating | Conversation Rating | Freshdesk uses satisfied/unsatisfied. Dixa supports CSAT (1–5), NPS, and ThumbsUpOrDown. Requires normalization. |
| Knowledge Base Article | Knowledge Article | Dixa has a Knowledge API on the Prime plan. Content must be re-imported or recreated. |
| Automation / Trigger | (Cannot be migrated) | Must be rebuilt in Dixa's flow builder. |
| Canned Response | (Cannot be migrated) | Must be recreated as Dixa Templates. |
| SLA Policy | (Cannot be migrated) | Dixa SLAs are configured per-queue. Rebuild from scratch. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets / Conversations | high | The structural mismatch between Freshdesk's ticket-centric model and Dixa's conversation-centric model requires full thread reconstruction, with risk of losing threaded message history and chronological ordering. |
| Contacts / End Users | medium | Contacts map to End Users by email, but Freshdesk company associations must be stored as custom attributes since Dixa has no native company field. |
| Companies | high | Dixa has no direct company object, so hierarchical contact-to-company relationships are lost and must be flattened into custom attributes or managed via external CRM integration. |
| Agents | low | Agents can be mapped by email address, though Dixa only supports three built-in roles (Administrator, Agent, Team Lead/Supervisor) with no custom roles, and agents must be provisioned before importing conversations. |
| Tags | low | Tags can be created and applied via the Dixa API with straightforward one-to-one mapping, requiring only that they are created before conversation import. |
| Custom Fields / Attributes | high | Freshdesk supports dropdown, checkbox, date, number, text, and nested dependent fields, but Dixa custom attributes only support Text and Select types, requiring flattening of nested dropdowns and type normalization. |
| Attachments | medium | Dixa requires publicly accessible URLs at import time, so any Freshdesk attachment URLs that are authenticated or time-expiring must be re-hosted to persistent cloud storage before migration. |
| Satisfaction Ratings | medium | Freshdesk uses a binary satisfied/unsatisfied scale while Dixa supports CSAT (1-5), NPS, and ThumbsUpOrDown, requiring normalization logic to map between the different rating systems. |
| Knowledge Base Articles | medium | Dixa's Knowledge API is only available on the Prime plan, and content must be re-imported or recreated rather than directly migrated. |
| Automations / SLA Policies / Canned Responses | high | These objects have no migration path whatsoever and must be manually rebuilt from scratch in Dixa's flow builder, per-queue SLA settings, and Templates system. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Ticket-to-Conversation Model Mismatch
Freshdesk's atomic unit is a numbered ticket with child conversations, while Dixa uses UUID-identified conversations containing messages directly, requiring full thread reconstruction during migration.
Limited Import Channel Support
Dixa's historical import endpoint only supports email and genericapimessaging channel types, meaning phone call and social media interaction history must be normalized or tested in a sandbox before import.
Company Object Has No Equivalent
Freshdesk's hierarchical contact-to-company relationships have no native representation in Dixa and must be flattened into custom attributes on End Users, losing relational semantics.
Groups to Queues Plus Teams
Each Freshdesk Group must be split into both a Dixa Queue (for routing with SLA and offering algorithms) and a Dixa Team (for organizational grouping), requiring careful dual-mapping.
Non-Migratable Automation and SLA Config
Freshdesk automations, triggers, canned responses, and SLA policies cannot be exported or migrated and must be manually rebuilt in Dixa's flow builder and per-queue SLA settings.
Attachment Re-hosting Requirement
Dixa accepts attachments as publicly accessible URLs at import time, so Freshdesk attachment URLs that require authentication or have expiration policies must be re-hosted to S3 or GCS before migration.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate Freshdesk to Dixa without losing data?
Yes — ticket content, replies, notes, contacts, tags, and attachments can all be migrated to Dixa with full fidelity using the API. The data you will lose is operational configuration: automations, SLA policies, canned responses, and time tracking entries. These must be rebuilt manually in Dixa. The common data-loss pattern is relying on Freshdesk CSV export alone, because it omits full conversation threads and archived tickets.
What data cannot be migrated from Freshdesk to Dixa?
Automations, dispatch rules, canned responses, SLA policies, time tracking entries, forum content, agent shift schedules, and ticket views cannot be migrated. These must be rebuilt manually in Dixa's flow builder, templates, queue settings, and analytics.
What Dixa plan do I need for API-based migration?
You need the Ultimate plan ($139/agent/month annual) or Prime plan ($179/agent/month annual). The Growth plan does not include API access. All Dixa plans require a 7-seat minimum.
How long does a Freshdesk to Dixa migration take?
A small team with fewer than 10,000 email-only tickets can complete the migration in 3–5 days. Mid-market migrations (10K–100K tickets) typically take 1–2 weeks. Enterprise migrations with 100K+ tickets, multi-brand setups, and attachments take 2–4 weeks. These timelines include mapping, test loads, validation, and cutover.
Can I keep Freshdesk ticket IDs in Dixa?
Not as native Dixa conversation IDs — Dixa uses UUIDs. The standard approach is to store the old Freshdesk ticket ID in Dixa's externalId field or a custom attribute so agents can search legacy references after cutover.