Migrating From Freshdesk to Zendesk

When you migrate from Freshdesk to Zendesk the data move is the easy half. The hard half is the fortnight when both systems take mail and nobody is sure which is real.

Start free trial All guides

Migrate from Freshdesk to Zendesk: what maps cleanly

The two products are shaped similarly enough that most core objects have an obvious counterpart. A migration tool or a scripted move using both APIs will carry these across without much argument.

Object mapping

The clean part of the move. Field types still need checking one by one.

Freshdesk	Zendesk	Notes
Ticket	Ticket	Status values need translating, especially Closed versus Solved
Contact	End user	Matched on email, so duplicate contacts arrive as duplicate users
Company	Organization	Clean for B2B, close to meaningless for a consumer desk
Agent	Agent	Roles differ, so expect to reassign permissions manually
Group	Group	Straightforward. Routing rules behind them are not
Ticket fields	Ticket fields	One to one only where types line up. Dropdowns need care
Canned response	Macro	Text moves, placeholders don't. Every variable needs rewriting
Solution article	Guide article	Content moves, URLs change, so plan redirects

What doesn't map

This is the part that eats the schedule, and none of it is a surprise once you look.

Automation logic. Freshdesk dispatcher, supervisor and observer rules don't become Zendesk triggers and automations. The intent transfers, the configuration doesn't. Rebuild it, and take the chance to delete the rules nobody remembers writing.

Placeholders. Every variable in every template and canned response uses different syntax. This is mechanical and tedious and it's where the last-minute embarrassing emails come from.

Merge history. Freshdesk merges and Zendesk merges are recorded differently. Threads that were merged in Freshdesk may not arrive with that relationship intact.

Attachments at volume. They usually move, but attachment volume drives migration time more than ticket count does. Measure gigabytes, not tickets.

Portal customisation. Themes, custom CSS and any multi-product portal structure are a rebuild in Guide, not a copy.

None of this is a reason to avoid the move. It is a reason to scope it properly, because a team that budgets for a data copy and gets a configuration project loses trust in the whole thing by week three.

A sequence that works

1. Clean first, then move

Never migrate rubbish. Merge duplicate contacts, delete spam, decide how far back you actually need closed tickets. Most teams find two years is plenty and the rest can live in an export.

2. Build Zendesk properly, empty

Fields, forms, groups, triggers, SLAs, brands. Get it working with no data in it. This is the bulk of the real work and it's much easier without live tickets landing on top of you.

3. Trial import into a sandbox

Move a few thousand tickets and check them by hand. Statuses, timestamps, requester matching, attachments, custom field values. Fix mappings, then run it again.

4. Cut the mail over on a quiet day

Forwarding changes to Zendesk. Not on a Monday, and not on a launch week.

5. Import the delta and close Freshdesk to new mail

Pull across everything that arrived during the final window, and put Freshdesk into read-only as fast as you sensibly can.

Keep the old account alive for a few months after that, on the cheapest plan that still gives you access. It costs very little and it settles the arguments that start with "we definitely had a ticket about this".

The parallel period and the duplicates it creates

Almost everyone runs both for a while. It feels safe. It's also the single largest source of duplicate tickets you'll ever see, and it's worth planning for rather than reacting to.

Here's the mechanism. A customer replies to an old Freshdesk notification and it lands there, while their fresh email hits Zendesk. Your form points at the new address but Google has the old help centre indexed. An agent answers in one system, the customer chases in the other, and now two threads describe one problem with different answers in each.

Three things keep it under control. Make Freshdesk read-only for new tickets as early as you dare, rather than leaving it half open for comfort. Auto-reply on the old address with a pointer, not silence. And once you're on Zendesk, watch the first fortnight for tickets from the same requester with near-identical subjects, because they will be there.

For the wider decision about which of the two products you want, the Freshdesk versus Zendesk migration guide covers the move in both directions.

FAQ

Frequently asked questions

Is there a Freshdesk Zendesk import tool?

Third-party migration services do the Freshdesk Zendesk import for tickets, contacts and articles. None of them rebuild automations, so budget for that separately.

How long does it take to migrate from Freshdesk to Zendesk?

Configuration typically takes two to six weeks depending on how much automation you have. The data move itself is usually days, and attachment volume drives that more than ticket count.

Do ticket IDs carry over?

No. Zendesk assigns its own. If customers reference old IDs, store the Freshdesk ID in a custom field so search still finds them.

Can we move knowledge base articles?

Yes, content moves into Guide. URLs change, so set up redirects or accept the search ranking hit on your most visited articles.

Should we run both systems in parallel?

Briefly, and with the old one read-only for new tickets. A long parallel period is where duplicates multiply and where customers get two different answers.

What about merged tickets from Freshdesk?

Merge relationships are recorded differently in each product and may not survive the move. Check a sample of previously merged threads in your trial import.