Kustomer to Zendesk Migration: What Migrates, What Breaks, and How to Plan It

When you migrate from Kustomer to Zendesk, your data can move but your configuration cannot. Customers, companies, conversations with their messages and notes, attachments, tags, custom attribute values, users, teams and knowledge base articles can all be transferred, usually through the Kustomer API or a migration service. Workflows, business rules, routing queues, KObject schemas, shortcut logic and reports have to be rebuilt in Zendesk by hand, and Kustomer offers no export for workflows at all.

This guide covers how the two data models differ, an object-by-object table of what migrates, the tools that do the move, a step plan with cutover, and a short section on going the other way, from Zendesk to Kustomer. For the general version of this process across any pair of helpdesks, see our helpdesk migration checklist. If Freshdesk is your source instead, see the Freshdesk to HubSpot migration guide.

Why is Kustomer to Zendesk harder than it looks?

Because the two products think about support differently.

Kustomer is customer-centric. Everything hangs off a customer record and its timeline. A customer has many conversations, each conversation has messages and notes, and custom data lives in custom attributes on standard objects or in KObjects, Kustomer’s custom objects (each defined by a “Klass”). Agents work from the timeline, seeing orders, past conversations and events in one scroll.

Zendesk is ticket-centric. The unit of work is the ticket. A ticket has a requester (an end user), belongs optionally to an organization, and contains public and private comments. Custom data lives in ticket, user and organization fields, plus Zendesk’s custom objects if you use them.

So the core question is not “how do we export” but “what becomes a ticket”. The common answer is one Kustomer conversation equals one Zendesk ticket. That is clean for email and chat, but it means the unified timeline view your agents are used to becomes a list of separate tickets on the requester’s profile. Decide early whether that matters to your team, and whether anything on the timeline that is not a conversation (KObject records such as orders or subscriptions) needs a home in Zendesk.

Our Kustomer vs Zendesk comparison covers the product differences in more depth if you are still deciding whether to move.

What migrates from Kustomer to Zendesk?

This table reflects what Kustomer’s own documentation says you can and cannot export, combined with what Zendesk’s import APIs accept. Confirm the details for your account with a sample run.

The hard “No” rows come straight from Kustomer: its data export documentation states that business rules, workflows, saved searches and custom Klasses cannot be exported, and that access ends on the subscription end date with no read-only period afterwards. That last point should drive your timeline.

What are the ways to get data out of Kustomer?

Kustomer offers four routes, each with limits worth knowing before you plan:

• Reporting export. CSV exports of conversations, customers, messages and notes, up to 25 attributes at a time, in 30-day windows. Fine for analytics, not for migration.
• Saved search export. Up to 50,000 rows per export, and data not updated in more than two years is excluded from search.
• Export Buddy app. Users, teams, snippets, shortcuts, conversation tags and knowledge base articles as CSV. Useful for configuration reference.
• API. The only route to full message bodies and complete history. Machine users are bound by Kustomer’s API rate limits, which vary by plan, with searches limited to 100 requests per minute unless your contract says otherwise.

In practice, every serious Kustomer to Zendesk ticket migration uses the API, either through your own scripts or through a migration service that has already built against it.

What tools can move the data?

On the Zendesk side, use the Ticket Import API rather than the standard ticket endpoint. It lets you set historical created_at, updated_at and solved_at values, does not run triggers on imported tickets that are not closed until they are next updated, and can send closed tickets straight to the archive with archive_immediately. Two cautions from Zendesk’s own docs: metrics and SLAs are not supported on imported tickets, and Zendesk recommends tagging imported tickets so you can exclude them from reports.

For a sense of service pricing, our migration checklist includes Help Desk Migration’s published per-record examples. Treat any published price as a floor and quote on your real volume.

A step-by-step Kustomer to Zendesk migration plan

1. Inventory before you touch data. List every workflow, business rule, queue, shortcut, snippet, SLA, saved search and integration. Since none of the logic exports, screenshots and written descriptions are your only record. Mark each item keep, rebuild or drop.
2. Decide the mapping. Conversation to ticket, customer to user, company to organization, custom attributes to fields, and what to do with each KObject Klass. Write it in a spreadsheet the whole team signs off.
3. Build Zendesk first. Create ticket, user and organization fields, groups, brands, and Help Center categories and sections. Fields must exist before values can land in them.
4. Run a sample migration. 20 to 100 real conversations, including long threads, ones with attachments, and ones with custom attribute values. Check threading order, authorship, notes versus public replies, and inline images.
5. Rebuild the logic. Recreate triggers, automations, macros, SLA policies and views in Zendesk. Test with live sample tickets. This is usually the longest phase.
6. Reconnect integrations. Commerce, CRM, billing, Slack and anything your timeline apps pulled in.
7. Run the full migration. Newest first is a sensible default, so agents have recent context quickly. Tag everything imported.
8. Cut over and run a delta. Switch channels, then migrate anything created or updated in Kustomer during the move.
9. Verify and archive. Compare customer, conversation and article counts with the source. Keep a full export somewhere you control before the Kustomer contract ends.

What is the cutover plan?

Four weeks before: finish the inventory, complete the sample migration, and confirm your Kustomer contract end date. Because access stops on that date, plan the full export with margin.

Two weeks before: freeze configuration changes in Kustomer. Finish building and testing Zendesk triggers and macros. Train agents on Zendesk with sample tickets.

Cutover day:

• Point support email forwarding to Zendesk.
• Swap the chat widget and any web forms.
• Reconnect messaging channels such as WhatsApp, Facebook and Instagram to Zendesk, which may require re-verifying business accounts.
• Run the delta migration.
• Leave Kustomer readable for agents who need to look something up, for as long as your contract allows.

First two weeks after: watch first response time and backlog daily. Expect a dip in agent speed. Check that imported tickets are excluded from SLA reports.

The Zendesk side of this is covered in more depth in our guide to moving onto or off Zendesk.

What about Zendesk to Kustomer migration?

Going the other direction is simpler, because Kustomer ships its own importer. According to Kustomer’s documentation, the Zendesk importer:

• Lives under Settings, Administration, Data Import, and needs a Zendesk admin account with an API token plus the Kustomer Admin role.
• Imports Zendesk tickets, tags, users and groups, converting tickets into Kustomer conversations and groups into teams.
• Lets you filter by date range, exclude specific email addresses, and filter by tags.
• Runs a test import first (it stops after 100 tickets or five minutes), then a full import of up to 500,000 tickets, newest first. A full import can take up to two weeks.
• Creates imported users and teams as deactivated, and routes conversations to the default queue initially.

Kustomer’s docs do not say the importer moves macros, triggers or Help Center articles, so plan to rebuild those, and use a migration service if you need Guide content or more than 500,000 tickets. Before importing, create custom attributes on the Customer and Conversation objects, and disable or add conditions to any workflows that should not fire on imported data. Kustomer suggests excluding conversations with an importedAt value.

For the reverse path in full, see what moving off Kustomer involves.

How do you keep customers answered during the cutover?

The riskiest weeks of any helpdesk migration are the ones where agents are learning a new tool, the backlog is growing, and the knowledge base is half moved. Customers do not pause while you migrate.

One way to cover that gap is an AI resolution layer that runs alongside whichever helpdesk is live, rather than inside it. Fidiora works this way: it answers repetitive questions from your help content with cited sources, and creates a ticket in your helpdesk only when a person is needed, with the full conversation attached. Because it is not tied to the helpdesk’s data model, you can connect it before cutover to take pressure off the Kustomer queue, then point its handoffs at Zendesk on the day you switch. See how AI handoffs to your team work.

It also changes the size of the migration problem. Fewer conversations reaching agents means fewer Zendesk seats to buy. Fidiora charges $0.69 per genuine resolution, dropping to $0.45 above 1,000 a month, with no seat fees, free handoffs and a monthly spend cap, and setup typically takes under an hour. The getting started guide shows the steps. If your reason for leaving Kustomer was cost or AI resolution rather than a missing feature, read AI layer vs replatforming before you commit to the move.