The Complete Guide to Migrating from Kustomer to Zendesk

Moving your support operations from Kustomer to Zendesk means more than copying records — it means translating between two fundamentally different data models. Kustomer is built around a customer-centric timeline; Zendesk operates with a ticket-centric model. That structural mismatch is the root cause of most migration problems. This guide covers the full scope: what moves cleanly, what gets lost, what needs manual reconstruction, and what to do when things go wrong.

What data is lost or degraded in this migration

Before you plan anything, you need to know what cannot survive the move intact. Some Kustomer constructs have no direct Zendesk equivalent.

If any of these are business-critical, resolve the approach before migration begins — not after.

Define your migration scope

A successful migration is rarely a simple transfer. It involves a mix of automated processes, manual setup, and strategic archiving.

What should be migrated via the API

High volume data is best handled through bulk API operations to maintain integrity and save time. This includes your Core Resources such as Companies (Organizations), Customers (Users), and Conversations (Tickets).

Within these conversations, you will also want to move all Messages, Notes, and Attachments to preserve the full context of your support history.

Your Knowledge Base content, specifically Articles and Categories, should also be moved via API to keep your self-service portal intact.

Migration method selection by volume

The right migration approach depends on your data volume. Here is the decision logic:

• Under 10,000 tickets: Zendesk's native import tools (CSV import or basic API calls) are viable. Manageable by an internal engineer with API experience.
• 10,000 – 500,000 tickets: Use a batched API approach with rate limit management (see Insider Secrets below). Requires pagination handling and checkpoint logic to resume after failures.
• 500,000+ tickets: Plan a staged migration with a defined freeze window. Migrate historical data first, freeze new ticket creation or queue it externally, then migrate the delta before cutover.

What has to be configured manually

System settings and structural configurations often do not translate directly through an API and require a human touch.

You will need to manually recreate your Brands, as these define your public presence. Business Schedules, which dictate your support hours and SLA targets, must also be set up within the Zendesk interface.

Other visual elements like Knowledge Base Themes and Templates, as well as complex routing logic like Routes and Forms, are better configured manually to ensure they look and function correctly in the new environment.

What has to be archived

Not all data needs to live in your active help desk. Kustomer standard search is often limited to data from the past 2 years, and anything older is typically archived.

You might choose to archive very old Conversations or Audit Logs that are no longer relevant for daily operations but necessary for compliance.

Satisfaction (CSAT) responses older than a specific period can also be archived rather than imported, keeping your new Zendesk instance lean and fast.

Prepare Zendesk for data import

Before the first piece of data moves, your new environment must be ready to receive it.

• Rebuild Custom Fields: Recreate all Kustomer Custom Attributes as Ticket, User, or Organization fields in Zendesk to ensure data points have a place to land.
• Define Custom Objects: Use Zendesk Custom Objects to map over Kustomer Klasses, allowing you to store complex data that doesn't fit into standard fields.
• Establish User Identities: Prepare your user profiles to include multiple identifiers like email, phone numbers, and social handles.
• Configure Custom Ticket Statuses: Map Kustomer Snoozes and sub statuses to Zendesk Custom Ticket Statuses so your agents can maintain their existing workflows.
• Set up Brands and Schedules: Define your support brands and business hours so that incoming tickets are categorized correctly from day one.
• Enable Tagging: Ensure user and organization tagging is enabled in your Zendesk settings so that Kustomer Tags can be applied during import.

Map agent roles

Kustomer and Zendesk use different role structures. You need to map these explicitly before migrating users, or agents will land in Zendesk with incorrect permissions.

Zendesk's Light Agent tier is relevant if you have internal stakeholders who need read access without a full agent seat. Confirm your Zendesk plan covers the Light Agent seats you need before you start user import.

Migrate objects

The order in which you migrate objects is critical because of the relationships between them.

The logical sequence starts with Organizations (Companies). These are the top level containers. Once organizations are in place, you migrate Users (Customers) and link them to their respective organizations via Group Memberships or Organization Memberships.

Next, you move to the Tickets (Conversations). In Kustomer, a conversation is a container on a timeline, while in Zendesk, a ticket is the primary record. As you import tickets, you will also import Ticket Comments (Messages and Notes). It is important to distinguish between public messages and internal notes to maintain privacy.

Finally, you can migrate your Knowledge Base and CSAT data. Articles must be associated with their Categories and Sections, and any Attachments or Media must be linked to the correct article version.

Cutover, live data, and rollback

This section is commonly omitted from migration guides. Its absence in a real migration causes the most expensive failures.

Handling live data during cutover

Tickets created in Kustomer during the migration window will not automatically appear in Zendesk. You have three options:

1. Hard freeze: Stop new ticket creation in Kustomer for the duration of the final migration run. Only viable for very low-volume teams or planned maintenance windows.
2. Delta migration: Run the bulk migration, then re-query Kustomer for any tickets updated or created after your initial export timestamp, and migrate only those records as a final pass.
3. Parallel operation: Keep Kustomer active for incoming tickets and redirect to Zendesk only after the migration is validated. Requires agents to work in both systems briefly.

Pausing webhooks and live integrations

Before cutover, identify every active webhook and integration connected to Kustomer (CRM syncs, Slack notifications, escalation tools, analytics pipelines). These must be paused before migration and re-pointed to Zendesk endpoints afterward. Failing to do this will cause duplicate events, missed notifications, or data written to the wrong system during the transition window.

Rollback plan

If the migration produces corrupted records, duplicate users, or broken ticket chains, you need a defined rollback path before you go live — not while you are debugging at 2am.

• Keep Kustomer active and do not decommission it until the Zendesk data has been fully validated.
• Do not redirect agent traffic to Zendesk until you have completed a post-migration QA pass (see validation checklist below).
• Maintain a migration log of every API call batch so you know exactly which records were written and can target deletions if you need to clean Zendesk and re-run.
• If the migration is partial — for example, tickets migrated but not users — do not attempt to patch it in production. Restore from your pre-migration Kustomer export and re-run from the beginning.

Post-migration validation checklist

Before redirecting agents to Zendesk:

• Spot-check 50+ tickets across date ranges, channels, and statuses
• Verify internal notes did not become public comments
• Confirm organization memberships are correctly assigned
• Check that custom field values match source records
• Validate CSAT scores transferred (accept that free-text fields may be absent)
• Confirm agent roles match the role mapping table above
• Test all triggers and automations with real ticket scenarios
• Re-enable webhooks and verify downstream systems are receiving events from Zendesk

Post migration configuration

Once the data is in, you need to turn the lights on by setting up the automation and tools your agents use every day.

• Workflows: Rebuild your Kustomer Workflows as Zendesk Triggers and Automations to handle ticket routing, assignment, and status changes.
• Shortcuts: Recreate your Kustomer Shortcuts as Zendesk Macros so agents can quickly respond with canned text.
• Snippets: Convert Kustomer Snippets into Zendesk Dynamic Content to support multi-language responses and standardized text.
• Search Filters: Rebuild your Saved Searches and Search Folders as Zendesk Views to help agents organize their daily tasks.
• Notification Settings: Manually configure notification logs and individual user notification preferences to ensure the right people are alerted at the right time.
• Chat and Channel Setting: Finalize your Chat Settings and any Email or Web Hooks required to keep your various communication channels connected.

Insider secrets

1. Setting historic timestamps requires specific roles. To set attributes like createdAt or createdBy during a migration, you must have the org.admin role in Kustomer or equivalent administrative permissions in Zendesk, otherwise the system will automatically set the timestamp to the moment of import.
2. Avoid rate limit traps with importedAt. When migrating messages, including an importedAt property in your payload can often bypass certain object rate limits, which usually restrict a single user to 120 creations per minute.
3. Identity matching is automatic but picky. When you create a profile in Zendesk, the API automatically tries to match standard identifiers like email or phone number to existing users. If it doesn't find a match, it creates a new anonymous user, which can lead to duplicates if your data isn't clean.
4. Knowledge Base media must be handled first. Zendesk recommends creating your Guide media objects before creating article attachments. You then use the media ID to link the attachment to the article, ensuring images appear correctly in your translated content.
5. Organization field keys are permanent. When recreating custom fields, remember that while you can change the title, you cannot change the "key" after creation. Make sure your naming convention is solid before you start the import.

Summary

Migrating from Kustomer to Zendesk is a structural shift, not just a data transfer. The customer-centric timeline model does not have a direct equivalent in Zendesk, and several Kustomer constructs — KObject relationships, sub-statuses, CSAT free-text fields, AI summaries — will need explicit decisions made about how to handle them before you start.

The practical sequence: audit what will be lost, set up your Zendesk data model, map your agent roles, run the migration in dependency order (Organizations → Users → Tickets → Knowledge Base), handle the live data window deliberately, and validate before you redirect agent traffic.

Do not decommission Kustomer until the Zendesk data has been independently verified.

Further Reading:

• Kustomer API Reference
• Zendesk API Reference