The Complete Guide to Migrating from Zendesk to Enchant

Making the switch from Zendesk to Enchant is a significant move toward a more streamlined team experience.

Enchant provides a fully hosted omnichannel shared inbox solution that simplifies how you interact with your customers.

The underlying concepts — support tickets, customer profiles, conversation history — are similar across both platforms. The data models are not. This guide covers the full migration sequence, the field-level mappings, the failure modes, and the edge cases that trip up most self-managed migrations.

Define Your Migration Scope

Before you begin moving data, decide what goes through the automated pipeline and what requires a human touch. Your primary migration scope for the API includes users, customer profiles, ticket histories, and attachments. These are high-volume objects that benefit from a programmatic transfer.

Some elements must be configured manually. Your Help Center content — categories, sections, and articles — belongs in this category. There is no bulk import API for Enchant knowledge base content. Export your Zendesk articles via the Zendesk Help Center API, then reformat and recreate them in Enchant by hand or via a scripted paste workflow. Review formatting carefully: Zendesk renders HTML, Enchant expects plain text or Markdown depending on the field.

Consider what data should be archived rather than migrated. Non-essential system events — audit logs, notification receipts, agent name-change history — are better kept in a Zendesk CSV export for compliance than imported into your new active workspace.

Data Model Comparison

Before writing a single API call, map the objects. The table below shows the Zendesk object, its Enchant equivalent, the migration method, and known gaps.

Prepare Enchant for Data Import

Setting up your new environment is the first physical step. Rebuild configurations in Enchant before migration starts so that incoming records have a destination.

Create your inboxes. Every ticket in Enchant must belong to an inbox. Create one inbox in Enchant for every Zendesk group you are migrating.

Define your labels. Zendesk tags are free-text strings. Enchant uses structured label IDs. Pre-create every label you plan to use before import — you will reference label IDs (not names) in your API payloads.

Install the API app. In your Enchant help desk settings, install the API app to generate access tokens. These tokens are unrestricted — store them in a secrets manager, not in plaintext config files.

Disable all notification rules. Before importing any historical data, disable automated notification triggers in Enchant. If you do not, Enchant will fire new-ticket and new-message notifications to your customers for every historical record you import. The setting is in Settings → Notifications. Disable all outbound email notifications and re-enable them only after import is complete and validated.

Migrate Objects

The migration must follow this sequence. Each step depends on IDs created in the previous step.

Step 1 — Staff and Destinations

Create Enchant user accounts for every Zendesk agent and admin via POST /users. Store the mapping of Zendesk agent ID → Enchant user ID. Every message you import later must reference an Enchant author ID — without this map, you cannot attribute replies and notes to the correct agent.

Step 2 — Customer Database

Create Enchant customer records for every Zendesk end user via POST /customers. For each customer, migrate their identities (email addresses, phone numbers) as contacts via POST /customers/{id}/contacts. Designate exactly one contact as primary — Enchant uses the primary contact for outbound replies. Store the Zendesk user ID → Enchant customer ID mapping.

Edge case — duplicate customers: If a customer exists in Zendesk under multiple email addresses that were never merged, you will create duplicate customer records in Enchant. Deduplicate before import using the email address as the key. Query GET /customers?email={address} to check for existing records before creating new ones.

Step 3 — Files and Attachments

Attachments in Enchant follow a two-step flow:

1. Upload the file to get an attachment ID (POST /attachments).
2. Include the attachment ID in the message payload when creating the message.

Critical: Enchant automatically deletes any file that is not associated with a message shortly after upload. Do not batch-upload all attachments in advance. Upload each file and create its associated message in the same script step.

Pseudocode for the attachment flow:

for each message in ticket:
    attachment_ids = []
    for each file in message.attachments:
        response = POST /attachments with file binary
        attachment_ids.append(response.attachment_id)
    POST /tickets/{ticket_id}/messages with {
        body: message.body,
        attachments: attachment_ids,
        created_at: message.original_timestamp
    }

Step 4 — Ticket Shells and Messages

Create the ticket record first, then populate it with messages in chronological order.

• Create ticket: POST /tickets with type: email, customer ID, inbox ID, and original created_at timestamp.
• Create messages: POST /tickets/{id}/messages for each comment.
  • Zendesk comment.public = true → Enchant message type: reply
  • Zendesk comment.public = false → Enchant message type: note
• Set created_at on each message to preserve the original Zendesk timestamp.

After all messages are created, update the ticket state to match the original Zendesk status (see state mapping below).

Zendesk status → Enchant state mapping:

Step 5 — Handling Specialized Data

CSAT responses: No native import field. Append the CSAT score and verbatim comment as a private note on the ticket, formatted consistently (e.g., [CSAT] Score: 5 | Comment: "Great support").

Merged tickets: Enchant has no merge relationship concept. Migrate the source and target tickets independently as closed tickets. If preserving the merge relationship matters, append a note to each ticket referencing the other's migrated ID.

Ticket followers and CCs: Enchant has no equivalent. If this data must be preserved, append a note listing the follower emails before closing the ticket.

Zendesk API Rate Limits and Pagination

If you are migrating more than a few thousand tickets, rate limits will be your primary operational constraint.

• Zendesk export: Use the Incremental Ticket Export API rather than the standard search endpoint. It is purpose-built for bulk export and handles pagination more reliably at scale. The endpoint returns up to 1,000 records per page.
• Rate limits (Zendesk): Enterprise plans allow up to 700 requests per minute. Standard plans are lower. Build in a rate-limit handler that reads the Retry-After header and backs off accordingly.
• Rate limits (Enchant): Enchant API v1 enforces rate limits. Check the response headers on each request and implement exponential backoff on 429 responses.
• Volume guidance: For migrations under 50K tickets, a sequential single-threaded script is manageable. Above 50K, parallel workers per inbox or per date range will reduce total runtime significantly — but test parallelism carefully against Enchant's rate limit ceiling before running at full scale.

Failure Mode Reference

These are the most common ways a Zendesk → Enchant migration breaks:

Validation and Rollback

Before switching DNS and email routing to Enchant, validate the migration:

1. Row count check: Compare total ticket count in Zendesk (via GET /tickets/count) against total in Enchant (via GET /tickets with pagination). Counts should match.
2. Spot-check conversations: Randomly sample 20–30 tickets across different inboxes and date ranges. Verify message count, order, attachment presence, and agent attribution.
3. Attachment audit: For a random sample of tickets with attachments, confirm each attachment loads correctly in Enchant. A broken attachment URL in Zendesk will produce an orphaned upload attempt in Enchant — these should be logged and reviewed.
4. Customer record check: Verify that high-volume customers (your top 50 by ticket count) have correct contact records and a designated primary email.

Rollback: Zendesk data is not deleted during migration — you are writing to Enchant, not moving from Zendesk. If the migration fails validation, your Zendesk instance remains intact and operational. Keep Zendesk live and receiving tickets until the Enchant validation passes. Cutover is a DNS and email forwarding change, not a data operation.

Post Migration Configuration

After the bulk of your data is in Enchant, rebuild the active logic of your help desk:

• Automations and business rules: Recreate triggers and routing rules using Enchant's native tools. There is no import path — these must be rebuilt manually.
• Macros: Rewrite or reformat Zendesk macros to fit Enchant's response format.
• Email forwarding: Confirm that your support email addresses are forwarding to Enchant and that brand settings are correct before cutover.
• Re-enable notifications: After validation is complete, re-enable the notification rules you disabled in the preparation step.

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:

• Enchant API v1
• Zendesk Ticketing API