The Complete Guide to Migrating from Kustomer to Enchant

Making the move from Kustomer to Enchant is a significant step toward streamlining your support operations.

While both platforms are built to help you serve your users, they organize information in slightly different ways.

This guide will walk you through the specifics of moving your data effectively.

Define your migration scope

Determining which pieces of data move through the digital pipes and which require a human hand is the first step in your journey. We have categorized your Kustomer data into three distinct buckets to ensure nothing is lost.

Migrated via the API

The majority of your functional data will be moved through automated scripts using the programmatic interfaces provided by both systems.

This includes your core support team, your entire customer database, and the history of their interactions.

Standard objects like conversations, customer messages, internal notes, and file attachments are all capable of being transferred directly into Enchant.

Even your organizational data, such as tags and custom attributes, can be mapped into labels or summary fields.

Configured manually

Some elements in Kustomer are built on complex logic that does not translate directly into another system's database structure.

Your automated workflows, which handle conditional branching to assign users or add tags, must be rebuilt within Enchant's settings.

Similarly, the visual presentation of your knowledge base, including themes and custom forms, will need to be recreated to match the look and feel of your brand.

Business schedules and routing rules also fall into this category, as they dictate how your team currently manages availability.

Archived data

It is often wise to leave behind high volumes of data that are no longer useful for day to day operations.

Tracking events and audit logs from Kustomer are typically used for historical reporting and are not moved into the live Enchant inbox.

Additionally, any standard objects that have not been updated in over two years might be treated as archive material. You can export this legacy data into flat files for your records while keeping your new Enchant environment clean and fast.

Prepare Enchant for data import

Before you begin pushing data, you need to ensure the destination is ready to receive it. Building the framework first prevents errors during the import process.

• Invite your team: You must create all your users in Enchant so that tickets and notes can be attributed to the right people.
• Establish inboxes: Define your communication channels, such as email or chat, so the incoming tickets have a place to land.
• Pre-define labels: Create labels in Enchant that correspond to your Kustomer tags to maintain your organizational system.
• Set up custom fields: Ensure any custom metadata fields are active in Enchant so they can accept data from Kustomer's custom attributes.

Authentication: Both APIs require token-based authentication. Kustomer uses API keys passed as Bearer tokens in the Authorization header. Enchant uses HTTP Basic Auth with your API key as the username and an empty password. Confirm you have active credentials for both before writing any migration script.

Staging first: Run your migration against a test Enchant account before touching production. Enchant does not offer a formal sandbox, but you can create a separate account for this purpose. Validate object counts, attachment rendering, and label assignment before cutting over.

Migrate objects

Moving your data requires following a specific order to maintain the relationships between different objects. In the support world, a message cannot exist without a ticket, and a ticket cannot exist without a customer.

The primary data models in Kustomer, like Customers and Conversations, map well to Enchant's Customers and Tickets.

However, Kustomer treats Companies as a separate object, whereas Enchant stores this information within the Customer Summary.

KObjects are Kustomer's custom data objects — structured records attached to a customer or conversation that store domain-specific information such as order history, subscription details, or product data. Enchant has no equivalent native object type. The best workaround is to serialize the KObject's key fields and migrate them as Internal Notes at the top of a ticket or as summary metadata on the customer profile.

Open vs. closed status: Kustomer conversations carry statuses such as open, snoozed, and done. Map open and snoozed conversations to open tickets in Enchant, and done conversations to closed tickets. There is no direct snoozed equivalent in Enchant; treat those as open and note the snooze context in an internal note if it is operationally relevant.

Timestamps: Kustomer stores createdAt and updatedAt timestamps on all objects. Enchant's API accepts a created_at parameter on ticket and message creation, so original timestamps can be preserved. Verify this behavior against the Enchant API documentation for the specific endpoint you are using, as not all object types expose this parameter.

Data Mapping

The Logical Migration Sequence

1. Users: Create these first to provide the unique identifiers needed for ticket assignments.
2. Customers: Import your contact list next so that all interactions have a valid owner.
3. Attachments: Upload files to Enchant's servers to generate the necessary IDs before they are linked to messages.
4. Tickets (Conversations): Generate the ticket shells once the customers are already in the system.
5. Messages and Notes: Fill the tickets with their respective replies and internal discussions.
6. Labels (Tags): Apply your labels to the tickets to categorize them according to your established workflow.

Post Migration Configuration

Once the data is in Enchant, you need to set up your operational logic. These steps ensure your team can start working immediately.

• Recreate Workflows: Build your automation rules from scratch to handle ticket routing and automated replies.
• Set up SLAs: Configure your service level agreements to track response times and maintain high quality support.
• Import Knowledge Base Articles: Copy over your help content and organize it into categories.
• Configure Satisfaction Surveys: Set up your customer feedback loops to continue measuring team performance.
• Activate Snippets: Move your canned responses into Enchant's system so agents have their saved replies ready.

Insider Secrets

1. Respect the Rate Limits: Enchant uses a credit based system that allows 100 credits per minute. If you try to move too much data too fast, you will receive a busy signal, so be sure to build pauses into your migration script. At a sustained rate of 6 requests per second (the burst ceiling), migrating 100,000 tickets with their messages could take multiple hours depending on message volume per ticket — plan accordingly and run migrations during off-peak hours.
2. The Attachment Two Step: You cannot simply send a file with a message in Enchant. You must post the file data as a Base64 encoded string first, wait for the system to give you a file ID, and then attach that ID to your message.
3. Summary Fields are Powerhouses: Since Enchant does not have a separate Company object, use the summary field to store critical business details about your customers. This keeps the info visible to agents without needing extra API calls.
4. HTML and Text Clarity: When moving message bodies, check if the content is HTML or plain text. Enchant needs you to explicitly flag the message as htmlized to render correctly, otherwise, your beautifully formatted replies will look like a wall of code.
5. Burst Limits and Stability: While the minute limit is 100, there is a secondary burst limit of 6 requests per second. For a stable migration, it is often better to aim for a consistent, slower speed than to try and maximize every second.
6. External IDs are Your Best Friends: When creating objects in Enchant, always store the original Kustomer ID in a custom field or summary. This is your primary deduplication key — if a migration run fails midway, you can query Enchant for records that already carry a given Kustomer ID before attempting to recreate them, which prevents duplicate records on retry.

Failure handling and recovery

Migration runs fail. The question is whether your script handles failure gracefully or leaves you with a partially migrated dataset that is difficult to reason about.

Idempotency via External IDs: The External ID pattern described above is your core recovery mechanism. Before creating any object in Enchant, query for an existing record with the matching Kustomer ID stored in a custom field. If it exists, skip creation and log the match. If it does not, create it. This makes every migration run safe to re-execute.

Partial failure checkpointing: Log the Kustomer ID of every successfully migrated object to a local file or database table as you go. If the run fails at record 40,000 of 100,000, you can resume from record 40,001 rather than starting over. Without this, a failure deep into a large migration is expensive to recover from.

Attachment failures: Attachment uploads are the most common failure point due to file size, encoding errors, or transient network issues. Handle attachment failures separately from message failures — a message with a missing attachment is recoverable; a missing message is not. Log failed attachment uploads with the source URL or file reference so they can be retried independently.

Rate limit errors: Enchant returns an HTTP 429 when the credit limit is exceeded. Your script should catch 429 responses, wait for the retry period to elapse (typically 60 seconds), and then retry the request rather than failing the run.

Further Reading

• Kustomer API Documentation
• Enchant API Documentation

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.