Zendesk to Freshdesk Migration 2026: How to Avoid Data Loss

Every Zendesk to Freshdesk migration carries a data-loss risk that most teams discover too late — after the cutover, when an agent opens a ticket and finds the inline screenshot missing, the side conversation gone, or an entire attachment thread silently dropped. This is not a theoretical risk. It comes from hard platform constraints: Zendesk's strict export rate limits, Freshdesk's attachment ceilings, and the structural mismatch between objects that exist in one system but not the other.

This guide breaks down the exact technical reasons data gets lost during a Zendesk to Freshdesk migration, the API limits you will hit on both sides, a complete data-mapping table, and a direct comparison of migration methods — so you can pick the approach that matches your risk tolerance.

For a step-by-step walkthrough of setting up your Freshdesk environment before import, see The Complete Guide to Migrating From Zendesk to Freshdesk.

Zendesk to Freshdesk Migration: Why Data Loss Happens

Data loss during a Zendesk to Freshdesk migration rarely looks like a total failure. It looks like a successful import where 10% of the historical context is quietly missing.

The root cause is structural divergence. Zendesk and Freshdesk organize support data differently. Zendesk exposes side conversations, ticket audits, metric events, and satisfaction reasons as first-class API objects. Freshdesk does not have native equivalents for any of them. When a migration tool encounters an object that has no 1:1 target, it either drops the data or trims it to fit — usually without warning.

Ticket-count parity is not a useful success metric. A migration can recreate the right number of tickets and still lose internal context, inline screenshots, third-party collaboration threads, and attachment references that agents depend on when they reopen an old case. (developer.zendesk.com)

On top of structural divergence, both platforms enforce API rate limits that throttle how fast data can be extracted and imported. A migration script that does not respect these limits will get 429 Too Many Requests errors — and if it does not retry correctly, records are skipped without warning.

The most common data-loss scenarios we see:

• Inline images stripped from ticket comments (broken <img> tags pointing at expired Zendesk CDN URLs)
• Attachments over 15–20 MB silently dropped by Freshdesk or the migration tool
• Side conversations discarded entirely because no target object exists
• Tags longer than 32 characters rejected by Freshdesk
• Ticket audits and metric events abandoned because they have no Freshdesk equivalent
• Unassigned tickets failing to import because Freshdesk's API requires an agent assignment

Zendesk Export API Limits: The 10 Requests/Minute Bottleneck

The biggest constraint on the export side is Zendesk's Incremental Export API, which is the only practical way to extract large ticket datasets.

Zendesk enforces a strict rate limit of exactly 10 requests per minute on its incremental export endpoints. This limit applies regardless of your enterprise plan tier. With the High Volume API add-on (available on Suite Growth and above, minimum 10 seats), the limit increases to 30 requests per minute — still far below the account-wide limits most teams expect.

This is a separate rate limit from the standard account-wide API limit (which ranges from ~200 to 700+ requests/minute depending on plan). The incremental export endpoints have their own allocation, tracked via the Zendesk-RateLimit-incremental-exports-cursor response header. Zendesk's docs also note that the start_time parameter must be at least one minute in the past, so the newest minute of data is never available during extraction. (developer.zendesk.com)

Why this matters for migrations:

• Each incremental export request returns up to 1,000 tickets.
• At 10 requests/minute, you can extract roughly 10,000 tickets per minute — but each ticket still needs separate API calls for comments, attachments, side conversations, and satisfaction ratings.
• For a 500,000-ticket account, just the ticket extraction phase (not including comments or attachments) can take hours.
• A DIY script that does not parse the Retry-After header and implement exponential backoff will hit 429 errors and silently skip pages.

A well-architected extractor treats these as separate rate-limit budgets:

• Tickets: the incremental ticket export endpoint (developer.zendesk.com)
• Comments: the Ticket Comments API, including inline-image-aware handling (developer.zendesk.com)
• Side conversations: the Side Conversations API, with their own IDs, participants, state, and events (developer.zendesk.com)

The script is rarely slow because your language runtime is slow. It is slow because the API topology is wider than teams expect. For a deeper source-side export breakdown, see 3 Advanced Ways to Export Tickets from Zendesk.

Freshdesk Import API Limits and Trial Account Traps

On the import side, Freshdesk enforces per-minute API rate limits that vary by plan. These limits are account-wide — shared across every app, integration, and script hitting the same Freshdesk instance simultaneously. (support.freshdesk.com)

Freshdesk also applies per-endpoint sub-limits that are lower than the account-wide ceiling and easy to miss. The endpoint caps break down as: Ticket Create = 80 / 160 / 280, Ticket Update = 80 / 160 / 280, and Tickets List = 20 / 100 / 200 per minute across Growth / Pro / Enterprise. A job that creates contacts quickly can still stall when it hits the lower ticket-create cap. (support.freshdesk.com)

Key constraints to plan for:

• The limit is account-wide, not per-API-key. If Freshdesk marketplace apps or other integrations are running, they consume from the same pool.
• Even failed requests count toward the limit. A malformed payload still burns a request.
• Pagination is capped at 100 records per page. Importing 50,000 contacts requires at least 500 sequential API calls just to verify existing records before creating new ones.
• Every API response includes X-RateLimit-Total, X-RateLimit-Remaining, and X-RateLimit-Used-CurrentRequest headers — parse them proactively instead of waiting for 429 responses.
• If your Freshdesk account was created before December 2025, your limit behavior may differ while Freshdesk completes its rollout from per-hour to per-minute rate limiting. Confirm with Freshdesk support before sizing your import workers. (support.freshdesk.com)

Zendesk to Freshdesk Data Mapping: The Complete Object Map

The mapping between Zendesk and Freshdesk is where migrations succeed or fail. Some objects translate directly. Others require transformation. A few have no equivalent at all.

This is a recommended migration mapping, not a vendor-defined one-click crosswalk. Freshdesk's ticketing model natively supports replies and public/private notes, and its documented third-party collaboration flow feeds forwarded replies back as private notes. That is why side conversations land as private notes — it is the closest structural equivalent. (developers.freshdesk.com)

Zendesk public_comment    -> Freshdesk public_note (or reply)
Zendesk internal_comment  -> Freshdesk private_note
Zendesk side_conversation -> Freshdesk private_note

For a deeper look at mapping methodologies, see Your Ultimate Guide to Data Mapping for a Flawless Helpdesk Migration.

Mapping the Unmappable: Side Conversations, Audits, and Tags

Side Conversations → Private Notes

Zendesk Side Conversations are threaded, multi-participant discussions attached to a ticket — they can be email-based, Slack-based, or even child tickets. Freshdesk has no equivalent object. (developer.zendesk.com)

The correct migration strategy is to extract each side conversation and its events via the Zendesk Side Conversations API (/api/v2/tickets/{id}/side_conversations), then import each message as a private note on the corresponding Freshdesk ticket. Preserve the original subject, participants, timestamps, and channel type in the note body so agents retain full context.

This approach means you lose the threaded structure, but you preserve the content. The alternative — skipping side conversations entirely — means losing potentially critical internal context that agents relied on to resolve issues.

Ticket Audits and Metric Events → Archived Data

Zendesk ticket audits record every change to a ticket: field updates, reassignments, status changes, SLA breaches. Freshdesk does not have an equivalent audit log that can be populated via API.

The pragmatic approach: export audits and metric events as JSON files, store them in a searchable archive (S3, SharePoint, or a simple database), and link to the archive from a custom field or private note on the Freshdesk ticket. The data is not lost — it is just not inside Freshdesk.

Tags Over 32 Characters

Freshdesk enforces a strict 32-character limit on tags. If your Zendesk account uses long, descriptive tags (e.g., enterprise_customer_high_priority_escalation) or auto-generated identifiers that exceed 32 characters, Freshdesk will reject them during import. Options:

• Truncate to 32 characters (risks collision if multiple tags share a prefix)
• Remap using a lookup table that maps long tags to shorter equivalents
• Hash-and-alias: create a short hash and maintain a reference mapping

Build the tag-mapping table before migration and validate it against your automation rules, views, and reporting — any tag referenced in a Freshdesk automation that does not match exactly will silently fail.

Unassigned Tickets

Zendesk allows tickets to sit entirely unassigned. Freshdesk requires tickets to be assigned to an agent upon creation via the API. Create a "Migration Agent" in Freshdesk to receive all unassigned Zendesk tickets, then bulk-reassign or unassign post-migration. Without this, the API will reject the creation payload.

The 15 MB Attachment Limit and Inline Image Failures

Attachment handling is the single largest source of silent data loss in Zendesk to Freshdesk migrations.

The Size Limit

There is an important distinction between the platform limit and the tool limit. Freshdesk enforces a 20 MB attachment limit per conversation on paid plans (Growth and above), and a 15 MB limit on trial and free-tier accounts. But most migration tools are stricter than the platform itself. (developers.freshdesk.com)

Standard automated migration tools explicitly state they will fail to transfer any attachment larger than 15 MB per note or reply. Freshdesk's own native Zendesk migration app has the same constraint: if any attachment per note/reply exceeds 15 MB, all attachments on that note are skipped — not just the oversized one.

Inline Image Breakage

Inline images in Zendesk ticket comments are stored as references to Zendesk's CDN. When you export the HTML body of a comment, those <img src="https://your-subdomain.zendesk.com/attachments/..." /> URLs come along. After migration, those URLs either expire or require Zendesk authentication to access.

Freshdesk's native migration tool does not migrate inline images at all. Automated tools typically convert them to attachments — meaning they are no longer rendered inline in the conversation thread, breaking visual context for agents reviewing ticket history.

Zendesk's comments endpoint exposes an inline boolean on attachments that marks images intended to live inside the comment body. If your exporter only downloads standard attachments and ignores this flag, pasted screenshots turn into broken references. (developer.zendesk.com)

The correct fix requires a dedicated pipeline:

1. Parse the HTML body of each Zendesk comment to identify inline image URLs.
2. Download the images using authenticated Zendesk API calls.
3. Upload the images to Freshdesk as attachments via the API.
4. Rewrite the <img> src tags in the comment body to reference the new Freshdesk-hosted URLs.

This is tedious to script and impossible with most off-the-shelf tools. It is one of the primary reasons teams opt for a custom or managed migration.

Comparing Migration Methods: Native, SaaS Tools, and Custom Engineering

Freshdesk's Native Migration App

Freshdesk provides a free marketplace app for Zendesk imports. It handles contacts, companies, agents, tickets, and knowledge base articles. Hard limitations: inline images are not imported, attachments over 15 MB cause the entire note's attachments to be skipped, tags over 32 characters are rejected, only the primary language is imported for multilingual help centers, and subject lines over 256 characters are truncated.

For small accounts (under 10,000 tickets, no side conversations, few large attachments), this may be sufficient. For anything more complex, it is not.

Help Desk Migration (Relokia)

Help Desk Migration is the most widely used automated SaaS tool for helpdesk migrations. It handles the core data well and supports side conversations as private notes. But it still enforces a 15 MB-per-note attachment limit, trims tags over 32 characters, and converts inline images to attachments rather than preserving them inline.

Its own FAQ is explicit about what sits outside the automated path: macros, triggers, email notifications, canned responses, integration configurations, and reporting metrics are not imported. Replies created while the migration is in progress are not captured automatically during that run. (help-desk-migration.com)

For a detailed feature and pricing comparison, see ClonePartner vs Help Desk Migration: 2026 Price & Feature Comparison.

DIY API Scripts

Building your own migration gives you complete control — but you inherit complete responsibility. You will need to engineer around Zendesk's 10 req/min incremental export limit, Freshdesk's 200–700 req/min import limit (plus the lower per-endpoint caps), handle pagination across potentially millions of records, manage attachment download/re-upload pipelines, and build retry logic for every API call.

The cost teams consistently underestimate: ongoing maintenance. The Zendesk and Freshdesk APIs both evolve. Rate limits change. Edge cases — deleted users referenced in tickets, suspended tickets, archived data — surface mid-migration and require custom handling.

Engineer-Led Migration

This is the right option when historical ticket context matters to operations, compliance, or account management. You still get custom code and precise mapping, but you do not have to assign your own engineering team to babysit the job through cutover.

How ClonePartner Handles Zero Data Loss Migrations

We have completed hundreds of helpdesk migrations — including Zendesk to Freshdesk moves ranging from 5,000 to 2,000,000+ tickets. Our approach is built around the specific constraints outlined in this article.

Rate-limit-aware extraction. Our pipelines natively handle Zendesk's 10 req/min incremental export limit with cursor-based pagination, automatic retry on 429 responses, and parallel extraction of comments, attachments, and side conversations within the allowed budget. No silent failures.

Full object mapping with transformation. Side conversations are extracted with their complete event history and imported as structured private notes in Freshdesk — with original participants, timestamps, and channel type preserved in the note body. Tags are pre-processed against a remapping table. Unassigned tickets are routed to a configurable default agent. Legacy Zendesk IDs are stored in custom fields so agents and auditors can trace records back to the source.

Custom attachment pipeline. Attachments that exceed Freshdesk's native limits are handled through a custom extraction and upload process. Inline images are downloaded from Zendesk's CDN, re-uploaded to Freshdesk, and the HTML in each comment body is rewritten to reference the new URLs — preserving visual context for agents.

Delta migration for zero downtime. After the initial bulk migration, we run a delta sync that captures every ticket created or updated in Zendesk during the migration window. Your support team keeps working in Zendesk until the moment of cutover, and nothing is missed. For more on this approach, see Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move.

The expensive failure is not the rerun. It is the day an agent opens a six-year-old VIP ticket and the internal decision trail is gone. After enough migrations, you stop optimizing for whether the job finished and start optimizing for whether an experienced agent would trust the ticket history.

What to Do Before You Start

Regardless of which method you choose, these steps reduce data-loss risk:

1. Audit your Zendesk data. Count tickets, attachments, side conversations, and tags. Identify any tags over 32 characters and attachments over 15 MB. This determines which migration method is viable.

2. Provision a paid Freshdesk account. Never test a migration on a trial account (50 req/min). Use at minimum a Growth plan (200 req/min).

3. Pre-build the Freshdesk environment. Create all agents, groups, custom fields, ticket forms, and statuses before importing a single record. If the target structure does not exist, imports fail or land in the wrong place.

4. Build a data-mapping spreadsheet. Map every Zendesk object to its Freshdesk equivalent. Flag objects with no equivalent (audits, metric events) and decide how to archive them.

5. Disable Freshdesk automations during import. Freshdesk automations fire on ticket creation. If they are active during migration, you will trigger thousands of unwanted emails, SLA timers, and auto-assignments.

6. Run a test migration on a representative sample. Pick 100–500 tickets that include edge cases: large attachments, side conversations, long tags, inline images, multilingual KB articles. Validate every one manually.

7. Request temporary API limit increases. Contact both Zendesk and Freshdesk support before migration to request temporary rate-limit increases. Zendesk can sometimes increase the incremental export limit; Freshdesk can raise the per-minute ceiling.

Picking the Right Migration Path

The right approach depends on your dataset complexity, not just volume:

• Under 10K tickets, no side conversations, no large attachments: Freshdesk's native app or Help Desk Migration will likely work. Validate with a test run.
• 10K–100K tickets, some side conversations, mixed attachment sizes: Help Desk Migration with its premium tier, or a custom engineering engagement. Budget for manual QA on edge cases.
• 100K+ tickets, heavy side conversations, large attachments, inline images, compliance requirements: Custom migration with an experienced partner. The API constraints alone make this a multi-week engineering project if done in-house.

If you are in the third category — or if your team cannot afford to discover data loss after cutover — that is exactly the problem we built ClonePartner to solve.