--- title: How a European Logistics Platform Moved a Decade of Support History from Zendesk to Freshdesk slug: logistics-platform-zendesk-to-freshdesk-case-study date: 2026-09-29 author: Abdul Aleem categories: [Case Studies] excerpt: "A European logistics technology company moved roughly 37,000 tickets and over 200,000 messages from Zendesk to Freshdesk with ClonePartner, verified inside Freshdesk rather than against our own records. Around a hundred tickets could not go, because Zendesk had permanently erased the people who raised them." tldr: "A European logistics platform moved a decade of Zendesk support history into a live Freshdesk, with every count verified by reading Freshdesk back." canonical: https://clonepartner.com/blog/logistics-platform-zendesk-to-freshdesk-case-study --- # How a European Logistics Platform Moved a Decade of Support History from Zendesk to Freshdesk ## 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 that could not be migrated:** 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](https://clonepartner.com/blog/blog/zendesk-to-freshdesk-migration-guide), 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 the migration had to be resumable, and had to survive being stopped and restarted without duplicating anything. - **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. That sample proved the thing most likely to be wrong: that original timestamps survived. A migrated ticket that reports today's date is not history, it is noise, and the customer confirmed the dates were right on their own records rather than taking our word for it. The sample also surfaced a question that was not a bug at all — the customer could not find their migrated resolved tickets in the Freshdesk filter panel. That was a Freshdesk interface behaviour rather than missing data, and it was explained rather than quietly fixed. **A guard against overwriting their own contacts.** Before the contacts push ran, a check was added so that a contact already present in Freshdesk kept its existing name and details. The migration filled gaps; it did not overwrite what the customer's team had built. **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 never required a code change and never required a re-run of anything already migrated. **Idempotent writes.** Every ticket and every note was pushed with a stable idempotency key derived from its source identity. A run that stopped at hour thirty and restarted picked up where it left off without creating a single duplicate. --- ## 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 had a requester who still exists in Zendesk but whose profile was created without an email address. This was not something that went wrong during the migration, and it was not something that could be worked around from our side. The identifying information no longer existed in the source to be migrated. If those deletions were made in response to data-erasure requests, then the tickets not carrying across is arguably the correct outcome. The decision that mattered was what *not* to do. The obvious fix 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 were put to the customer instead: migrate them against a placeholder, or add an email address in Zendesk and we re-run just those tickets. 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. By the time of the follow-up run, almost all of them had been deleted in Zendesk entirely — the information had been recorded in their internal systems and the tickets were no longer wanted. One remained, and 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: Verified in Freshdesk, Not in Our Own Records 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. That run also produced a disclosure rather than a result. Zendesk had continued receiving traffic past the agreed catch-up window, and roughly twenty-five tickets and ten replies created after it were deliberately not migrated, because the customer had scoped the run to end where it ended. Those were reported as existing rather than left to be discovered later. --- ## 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 — it is worth counting during discovery rather than finding at the end, alongside the other [ways a Zendesk to Freshdesk move loses data](https://clonepartner.com/blog/blog/zendesk-to-freshdesk-migration-2026-how-to-avoid-data-loss). - **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, and the two numbers disagree more often than anyone would like. Counting the destination is the only figure worth putting in front of a customer. ## Frequently asked questions ### Can tickets from a permanently deleted Zendesk user be migrated to Freshdesk? No. Freshdesk will not accept a ticket without a contactable requester, meaning at least an email address or a phone number. When Zendesk permanently deletes a user it erases the name and email address and leaves the tickets attached to an anonymous placeholder, so there is nothing left to attach the ticket to. On this migration around a hundred tickets were affected, and the identifying information no longer existed in the source to be migrated. ### Are original ticket timestamps preserved when migrating from Zendesk to Freshdesk? Yes. Original creation and update timestamps were carried across and proved on a sample of around a hundred tickets before any bulk work ran. A migrated ticket that reports today's date as its creation date is not history, so the sample was handed to the customer to check against their own records rather than taken on trust. ### Will migrating Zendesk contacts overwrite contacts that already exist in Freshdesk? It can, and on this project it would have. Freshdesk already held contacts created through the customer's own email channel, and migrating a Zendesk contact with a matching email address would have silently replaced a name their team had curated. A guard was added before the contacts push so an existing Freshdesk contact kept its name and details, and the migration filled gaps only. ### What happens to attachments larger than the Freshdesk size limit? Freshdesk rejects attachments above 20 MB. Rather than lose the whole message, the message text was migrated and the oversized file left behind, mostly screen recordings. The customer was given the list of which messages were affected rather than a count. ### How long does a Zendesk to Freshdesk migration of this size take? Roughly 37,000 tickets and over 200,000 messages was estimated at around 250,000 API calls across tickets, replies and contacts. At the increased Freshdesk rate allowance the customer arranged, that is more than fifty hours of continuous work, so the migration had to be resumable and survive being stopped and restarted without duplicating anything.