A European logistics technology company

TL;DR

Customer: A European logistics technology company. Its platform sits between online retailers and carriers, handling carrier selection, labels, tracking and delivery communication.

The Move: Zendesk to Freshdesk. Tickets, replies, contacts, tags, groups and custom fields, with original timestamps preserved. Zendesk stayed read-only throughout.

The Scope: Roughly 37,000 tickets carrying over 200,000 messages, and more than 5,000 contacts. A decade of support history.

The Roadblock: Freshdesk will not accept a ticket without a contactable requester — it needs at least an email address or phone number. Zendesk, when a user is permanently deleted, erases their name and email and leaves their tickets attached to an anonymous placeholder. Those tickets have nothing left to attach to.

The Outcome: Effectively the entire history in Freshdesk, verified by reading Freshdesk back; a per-ticket map from old Zendesk number to new Freshdesk number; and an itemised list, with reasons, of everything that did not go.

By the Numbers

• Estimated API calls for the full run: around 250,000
• Messages migrated: over 200,000
• Tickets migrated: roughly 37,000
• Contacts migrated: more than 5,000
• Sample migrated for review first: around 100 tickets, close to 900 comments, over 130 contacts
• Tickets with no requester left in the source: around 100
• Catch-up tickets and replies after the main run: around 20 tickets, over 100 replies
• Data span: a decade of support history

The Challenge: A Live Helpdesk and a Requester Rule

The customer runs a shipping and delivery platform used by online retailers, integrating with hundreds of carriers. Their support desk carried a decade of conversations with merchants about shipments, labels, service points and delivery exceptions — the sort of history where a ticket from three years ago is still the fastest way to understand a recurring integration problem.

They were moving to Freshdesk, and the Freshdesk account was already live. The migration was not filling an empty system; it was adding a decade of history underneath a desk people were working in that day. Most of the groundwork is the same as any Zendesk to Freshdesk migration, but three constraints shaped this one:

• Freshdesk requires a contactable requester. Every ticket must belong to someone with at least an email address or a phone number. Zendesk has no such rule, and more importantly, Zendesk destroys that information when a user is permanently deleted — which is exactly what happens when a data-erasure request is honoured. The tickets survive; the person does not.
• Rate limits made this a multi-day run, not an overnight one. The full migration was estimated at around 250,000 API calls across tickets, replies and contacts. At the increased Freshdesk allowance the customer arranged, that is more than fifty hours of continuous work — so resumability is a design requirement: the run survives being stopped and restarted, and every write carries a stable idempotency key.
• Existing contacts could not be overwritten. Freshdesk already held a set of contacts created through the customer's own email channel. Migrating a Zendesk contact with the same email address would have silently replaced a name the customer's team had already curated.

The ClonePartner Solution: Sample, Verify, Then Commit

A hundred-ticket sample first. Before any bulk work, a sample of around a hundred tickets with their comments and contacts was pushed to Freshdesk and handed to the customer to review. It proved the property everything else rests on: that original timestamps survived. A migrated ticket carrying today's date is an archive, not a history, and the customer confirmed the dates against their own records.

The sample also settled where migrated resolved tickets show up in Freshdesk's filter panel, which is an interface behaviour worth knowing before go-live. It was explained in full, with the filter that brings them up.

A guard in front of the contacts push. A contact already present in Freshdesk keeps its existing name and details, whatever the source record says. The migration fills gaps only, so the authored records in a live desk outrank the ones arriving behind them.

Tag and field mapping from configuration, not code. Zendesk tags that exceeded Freshdesk's length limit were shortened using a map the customer supplied. Statuses, groups, brands and custom fields were all resolved from the migration job's configuration, so a mapping change is a configuration change, applied to what comes next without touching what has already landed.

Idempotent writes. Every ticket and every note was pushed with a stable idempotency key derived from its source identity. A run can be stopped at hour thirty and resumed, and the keys are what make the resumed run additive.

The Tickets That Could Not Move

Almost all of them belonged to requesters that had been permanently deleted in Zendesk. When Zendesk permanently deletes a user, the name and email address are erased and the tickets are left attached to an anonymous "permanently deleted user". Freshdesk will not accept a ticket without a contactable requester, so there was nothing to attach them to. One is attached to a requester profile that carries no email address at all.

The identifying information no longer existed in the source to be migrated, so no mapping could recover it. Where those erasures answered data-protection requests, the tickets not carrying across is arguably the correct outcome.

The decision that mattered was what not to do. The quick route is to attach the orphaned tickets to a generic placeholder contact, and it would have taken minutes. It was deliberately not done, because it would have put invented contact details into a brand-new helpdesk — and a fabricated requester is indistinguishable from a real one six months later. Both options went to the customer instead: migrate them against a placeholder, or add an email address in Zendesk and have those tickets migrated on their own. Every one was listed with subject, date and status so the choice could be made on the actual records.

The customer's own answer closed it: the content of those tickets already lived in their internal systems, so almost none of them were wanted in the new helpdesk. One remains available to migrate on its own if they ever want it.

A second, smaller gap was handled the same way. A few messages carried attachments above Freshdesk's 20 MB limit, mostly screen recordings. Rather than lose those messages entirely, the message text was migrated and the oversized file left behind. The text is there; the large attachment is not, and the customer was told which.

The Results: Every Count Read Back From Freshdesk

The main migration completed two weeks before cutover. The figures handed over were counted inside Freshdesk rather than taken from the migration's own database — filter on the migration tag and the ticket count matches exactly.

Two artefacts went with it. A per-ticket export mapping every migrated ticket from its original Zendesk number to its new Freshdesk number, with a direct link, the original creation date and the number of messages transferred — so anyone holding an old Zendesk reference can find where it landed. And a second file listing the tickets that did not migrate, with the reason for each.

A catch-up run at cutover covered the three days of activity between the data snapshot and the cutover: around twenty new tickets and over a hundred replies added to existing tickets, all confirmed directly in Freshdesk.

The catch-up window has a boundary, and the boundary was documented. Zendesk kept receiving traffic past it, and roughly twenty-five tickets and ten replies created after the cut-off sit outside the migrated range by design. Each one was counted and handed over, so the edge of the migration is a known quantity.

What Made This Migration Different

For teams planning a Zendesk to Freshdesk move, three details from this project are worth noting:

• Permanently deleted users are a migration problem, not a data-protection footnote. Erasure in Zendesk leaves the ticket and destroys the person, and a destination that requires a contactable requester cannot accept the result. Anyone who has honoured erasure requests over the years will hit this, and the number is knowable before the migration starts — count it during discovery, alongside the other ways a Zendesk to Freshdesk move loses data.

• Do not invent data to make a number look better. Attaching the orphaned tickets to a placeholder contact would have produced a cleaner completion figure and a worse helpdesk. Invented contact details are indistinguishable from real ones once they are in the system, and the person who finds them later has no way to know. Report the gap, give the customer the options, and let them decide.

• Verify by reading the destination back. Every count handed to this customer was taken from Freshdesk itself, not from the migration's own records. A push that reports success is only reporting that it sent something. A destination count is the only figure the customer can reproduce for themselves, which is what makes it the one worth putting in front of them.