The Complete Guide to Migrating from Zendesk to Kustomer

Deciding to switch your support platform is a major milestone for any customer service team. Moving from Zendesk to Kustomer offers a chance to embrace a more customer-centric data model, but getting your data from one place to the other requires a clear roadmap.

This guide will walk you through the process of transitioning your history and configurations while ensuring nothing gets lost in the shuffle.

Define your migration scope

Before you start writing code or clicking buttons, you need to understand exactly what is moving and how it will get there. This ensures your team knows what to expect on day one in the new environment.

What to migrate via the API

The bulk of your historical data should be handled through the API to ensure accuracy and maintain relationships between records.

This includes your end users and staff accounts, along with their identities like email addresses and phone numbers. You will also want to move your interaction history, specifically tickets and their associated public and private comments.

Your Knowledge Base content, including categories, articles, and article translations, is also a prime candidate for API migration. Finally, historical CSAT responses and business schedules can be imported directly to maintain your reporting continuity.

What to configure manually

Some elements of your platform are built differently and require a human touch to function correctly in the new system. Kustomer uses a unique logic engine, so your Zendesk Triggers and Automations must be manually rebuilt as Workflows.

Similarly, the visual layout of your tickets, known as Ticket Forms, will need to be recreated using KViews (Klass Views) to ensure your agents see the right information at the right time.

Redirect rules for your help center should also be set up manually to ensure your SEO remains intact during the transition.

What to archive

Migration is a perfect time to clean house. You might choose to archive very old suspended tickets or article labels that no longer serve a purpose in your current support strategy.

If you have historical audit logs or ticket events that are not necessary for daily operations, you can keep them in a separate data warehouse or export them to a static file rather than importing them into your active Kustomer instance.

Pre-migration checklist

Before the first API call, confirm all of the following are true:

• You hold a Kustomer API key with org.admin role (required to create users, conversations, and custom attributes)
• Your Zendesk API token has read access to tickets, users, organizations, and help center content
• All custom attributes (metadata fields) are created on the Customer and Conversation objects in Kustomer
• Kustomer Teams are created and match your Zendesk Group names
• Business schedules are configured in Kustomer before tickets land (SLA timers start on import)
• Klasses (custom objects) are defined if you have structured data beyond standard ticket fields
• You have a staging or sandbox Kustomer instance to validate the first batch before full run
• externalId strategy is agreed upon — typically the source Zendesk ticket or user ID
• Attachment storage limits and quotas have been checked on the destination account
• A rollback plan is documented: which records to delete, how to identify them, and who is responsible

Prepare Kustomer for data import

To make the import successful, the "destination" must be ready to receive the data. You should handle these configurations before the first piece of data moves.

• Define Custom Attributes: You must create Custom Attributes (Metadata) on your Customer and Conversation objects to house data from your Zendesk User and Ticket fields.
• Establish Teams: Recreate your Zendesk Groups as Teams in Kustomer so that conversation ownership is preserved during the import.
• Configure Business Schedules: Set up your operational hours to ensure your service level agreements (SLAs) calculate correctly as soon as tickets land.
• Define Klasses: If you have complex data structures, create the necessary Klasses (Custom Objects) to act as containers for that information.
• Map Organizations: Prepare your Company records if you plan to link groups of customers to specific business entities.

Migrate objects

The migration follows a specific logical sequence to satisfy data dependencies. For example, you cannot assign a ticket to an agent who does not exist yet.

Mapping Table

Step 1: The Foundation

Start by migrating your Users (Agents and Admins) and Teams. This allows the system to correctly attribute ownership for everything that follows.

Next, import your Organizations as Companies so that customer profiles can be linked to them immediately upon creation.

Step 2: Customer Profiles and Structure

Import your End Users along with their User Identities, such as secondary emails and phone numbers. Simultaneously, you should build your Knowledge Base structure.

Zendesk Categories map directly to Kustomer Categories. However, Zendesk Sections do not have a 1:1 equivalent object, so the workaround is to map them as nested Categories within the Kustomer hierarchy.

Step 3: Content and Interactions

Now you can bring over your Articles, Article Translations, and Article Attachments. Once the people and the knowledge are in place, migrate your Tickets as Conversations.

Following the ticket headers, import the interaction history where Public Comments become Messages and Private Comments become Notes.

Finally, link your CSAT responses to the relevant conversations to finish the data move.

Feature parity gaps

Not every Zendesk feature has a direct Kustomer equivalent. The following gaps are the ones most likely to affect your migration planning.

Post Migration Configuration

Once your data is successfully moved, you need to turn on the lights and make the system operational.

• Rebuild Workflows: Use the manual mapping of your Zendesk triggers to build out branching logic in Kustomer Workflows.
• Design Klass Views: Create the UI screens (KViews) that agents will use to view and edit ticket information.
• Import Shortcuts: Finalize your Macros as Shortcuts, ensuring any dynamic text or placeholders function correctly in the new environment.
• Validate Satisfaction Surveys: Confirm that your Satisfaction survey triggers are ready to send for new conversations.
• Activate Routing: Assign your Queues and Routing rules to ensure incoming messages land with the right teams.

Failure recovery

Partial migration failures are the most common operational risk, and the most underplanned for.

How to identify failed records: If you are using externalId (strongly recommended), a failed record will simply not exist in Kustomer with that external ID. After each batch, run a lookup against your source IDs to find gaps. Any source ID without a matching Kustomer object failed silently.

How to re-run safely: Because externalId is unique-enforced in Kustomer, re-submitting a record that already exists will return a conflict error rather than create a duplicate. This means your import script is safe to re-run after fixing the failed subset — iterate over only the missing IDs rather than the full dataset.

What causes mid-run failures: The most common causes are missing referenced objects (e.g., a conversation referencing a team that wasn't created yet), malformed custom attribute values (type mismatches against the schema you defined), and attachment upload policy expiry (the temporary upload URL has a short TTL — generate it immediately before use, not in batch ahead of time).

Audit after completion: Before cutover, run a record count comparison between source and destination for each object type. A 1–2% gap in conversations is common when source data contains corrupted or duplicate records; a gap larger than that warrants investigation before go-live.

Insider Secrets

1. Use the ImportedAt flag: When importing Conversations or Messages via the API, include the importedAt attribute in your request body; this bypasses standard rate limits and prevents your import from being throttled.
2. External IDs are your best friend: Always map the original Zendesk Ticket ID or User ID to an externalId field in Kustomer; this allows you to perform easy lookups and prevents duplicate records if you need to run the import script multiple times.
3. Attachments require two steps: You cannot simply send a URL; you must first create an attachment object to get a temporary upload policy, then upload the file to that specific URL before it can be linked to a message. The upload policy URL has a short TTL — generate it immediately before uploading, not in a pre-batched step.
4. Nesting logic for Sections: Since Zendesk has a Category/Section/Article hierarchy and Kustomer is Category/Category/Article, remember that Kustomer allows infinite nesting; you can preserve your exact Guide structure by simply creating sub-categories.
5. Author linking is manual: When migrating articles or comments, the API will default the author to the owner of the API token unless you explicitly provide the user ID of the original author.

Summary

Transitioning from Zendesk to Kustomer is a strategic move toward a more integrated view of your customers.

By following a logical migration order, prioritizing your foundational data like Users and Teams, and carefully rebuilding your automation logic, you can ensure a seamless experience for your agents.

While the technical move involves many moving parts, the result is a powerful, highly customized support environment built to grow with your business.

If you'd rather focus on your revenue instead of wrestling with mapping sheets and pagination loops, ClonePartner can handle the full migration for you. Every project gets a dedicated engineer who understands the nuances of both APIs and ensures zero downtime.

Further Reading:

• Kustomer
• Zendesk