The Complete Guide to Migrating from Enchant to Kustomer

Kustomer organizes data into a continuous timeline, allowing your team to see every interaction in one place.

To make a migration from Enchant successful, you need a clear plan that respects the data models of both systems while ensuring no detail is left behind.

Define your migration scope

Defining the scope is the first step in ensuring your data remains clean and useful. You should categorize your information into three buckets to stay organized.

What to migrate via the API

The majority of your functional data should move through the API to preserve the relationships between records.

This includes your users, who will represent your support agents, and your customer profiles. You will also want to move the heart of your support history: tickets, which Kustomer calls conversations.

Within those conversations, every reply and internal note should be migrated to maintain a complete audit trail. Finally, the files and images attached to those communications are also eligible for API migration.

What to configure manually

Certain structural elements are better built from scratch in Kustomer to take advantage of its unique features.

Your team structures and role groups should be defined manually to ensure permissions are assigned correctly from day one.

Business schedules, which govern your support hours and SLA calculations, must also be set up within the Kustomer interface.

If you used specific labels to categorize tickets in Enchant, you should manually recreate these as tags within Kustomer settings to ensure they align with your new reporting needs.

What to archive

Migration is a perfect time to decide what data no longer serves your team. You might choose to archive tickets that are older than two years, as Kustomer search typically prioritizes more recent data.

High volumes of spam or messages from deleted accounts should also be archived or left behind to keep your new database efficient.

If you have custom contact data in Enchant that is no longer accurate, it is better to archive that information rather than cluttering your new customer profiles.

Prepare Kustomer for data import

Before you start pushing data into your new home, you need to lay the foundation. Complete these steps to ensure the import has a place to land:

• Create agent accounts: Set up your users in Kustomer so that when tickets are imported, they can be assigned to the correct people immediately.
• Define custom attributes: If your Enchant customers have unique fields like a membership ID, create these custom attributes in Kustomer first so the data has a destination.
• Set up your brands: If you manage multiple email signatures or help centers in Enchant, configure your brands in Kustomer to keep that data segmented.
• Establish business schedules: Configure your operating hours so that any imported conversation time data can eventually be measured against your actual availability.
• Replicate labels as tags: Create a list of your Enchant labels and add them to Kustomer as tags so you can filter conversations after the move.
• Generate API keys with proper scopes: Create a Kustomer API key with read/write permissions for customers, conversations, messages, and users. On the Enchant side, generate an API key with read access to tickets, customers, and attachments. Without the correct scopes, your migration script will fail silently or return permission errors.

Migrate objects

The migration should follow a strict logical order to ensure that every message is attached to the right conversation and every conversation is attached to the right person.

Kustomer uses a resource-oriented model where everything is an object. You must start with Users, as they are the owners of the support actions.

Next, move your Customers. In Enchant, customers are defined by their contacts, while in Kustomer, a customer is the anchor for an entire timeline of events. Once the customers exist, you can migrate Tickets, which transform into Kustomer Conversations.

After the conversation containers are ready, you can populate them with Replies (which Kustomer calls Messages) and Notes.

This fills the timeline with the actual words exchanged between your team and your customers. The final step is moving Attachments, which must be linked to the specific messages or notes they belonged to in the old system.

Data Mapping

Post Migration Configuration

Once the data is visible in the timelines, you need to turn the lights on by setting up the logic that makes Kustomer work:

• Rebuild Workflows: These are the automations that trigger based on events, such as a conversation being updated or a customer being created.
• Configure Queues and Routing: Set up your routing rules to ensure that new incoming conversations are sent to the right agents based on their skills or team.
• Create Shortcuts: Your canned responses from Enchant need to be recreated as shortcuts so agents can reply quickly.
• Set up SLAs: Define your service level agreements to track how quickly your team responds to customers now that the history is imported.

Post-Migration Validation

After the migration completes, you need to verify that the data landed correctly before pointing your team at Kustomer:

• Compare record counts: Check total counts for customers, conversations, messages, and attachments between Enchant and Kustomer. The numbers should match (minus any records you intentionally archived).
• Spot-check conversation threading: Open 10–20 conversations across different date ranges and verify that messages appear in the correct chronological order, assigned to the correct customer, with the correct agent attribution.
• Verify attachment accessibility: Confirm that attachments actually render and download — a successful attachment record in Kustomer doesn't guarantee the file upload to S3 completed.
• Check custom attribute mapping: Spot-check that custom fields (membership IDs, account numbers, etc.) populated correctly on customer profiles.
• Test timeline integrity: For a handful of customers with complex histories, verify that the full timeline — conversations, notes, and messages — is intact and readable.

Handling Failures and Resuming

Migrations fail mid-stream. Network timeouts, rate limit hits, and malformed records will interrupt the process. Plan for this upfront:

• Use externalId for idempotency: Because every object stores its original Enchant ID in the externalId field, you can look up whether a record already exists in Kustomer before creating it. This prevents duplicates when you restart a failed migration run.
• Log every API response: Store the Kustomer ID returned for each created object alongside the original Enchant ID. This gives you a lookup table for resuming from the exact point of failure.
• Build your script to be resumable: Your migration script should accept a "start from" parameter — for example, skip the first N customers that were already migrated. If you stored externalId on every object, you can query Kustomer to determine which records already exist and skip them.
• Handle partial conversation failures: If a conversation was created but its messages failed to import, you don't need to delete and recreate the conversation. Just re-run the message import step for that specific conversation using the Kustomer conversation ID from your log.

Insider Secrets

1. Use the importedAt attribute: When you are migrating history, always include the importedAt field in your data body. This tells Kustomer the data is from the past and prevents it from triggering live workflows or being subject to the standard API rate limits. The payload looks like this:

{
  "name": "Jane Doe",
  "email": "jane@example.com",
  "importedAt": "2024-01-15T10:30:00.000Z"
}

2. Concatenate names during the move: Enchant keeps first and last names in separate fields, but Kustomer uses a single name field for the customer profile. Join these two strings before sending:

kustomer_name = f"{enchant_customer['first_name']} {enchant_customer['last_name']}".strip()

3. The attachment two-step: You cannot simply send a file to Kustomer. You must first create the attachment document to receive a temporary S3 pre-signed URL and then send a separate multi-part request to that specific URL to actually save the file:

# Step 1: Create the attachment record in Kustomer
response = requests.post(
    "https://api.kustomerapp.com/v1/messages/{messageId}/attachments",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"name": "screenshot.png", "contentType": "image/png"}
)
presigned_url = response.json()["data"]["attributes"]["url"]
 
# Step 2: Upload the actual file to the pre-signed S3 URL
with open("screenshot.png", "rb") as f:
    requests.put(presigned_url, data=f, headers={"Content-Type": "image/png"})

4. Leverage External IDs for lookups and crash recovery: Use the unique ID from Enchant and store it in the externalId field in Kustomer for every object. This serves two purposes: it makes it easy to perform lookups if you need to update records later, and it gives you an idempotency key if the migration crashes and you need to resume without creating duplicates.
5. Throttle your own requests: While the importedAt flag helps with some limits, the API still has account-wide rate limits based on your pricing plan (the exact thresholds vary by tier and are not publicly documented in detail — contact Kustomer support for your specific limits). Build a small delay into your migration script to stay within your allowed request rate.

Common Failure Modes

• Messages appear out of chronological order: This happens when the importedAt timestamp on messages doesn't match the original send time from Enchant. Make sure you're mapping Enchant's message timestamp to importedAt, not using the current time.
• Customer timeline is empty after import: The customer record was created, but conversations weren't linked to it. Verify that each conversation's customer field references the correct Kustomer customer ID (not the Enchant customer ID).
• Attachments show as broken links: The attachment record was created (step 1 of the two-step), but the file upload to the pre-signed URL failed or timed out. Re-run the upload step using the same pre-signed URL if it hasn't expired, or create a new attachment record.
• Duplicate customers after a restart: The migration script crashed and was restarted without checking for existing records. Use the externalId lookup to check whether each customer already exists before creating a new one.
• Conversations assigned to the wrong agent: Agent user IDs from Enchant don't map to Kustomer user IDs. Build a lookup table of Enchant user ID → Kustomer user ID during the Users migration step, and reference it when importing conversations.

Summary

Migrating from Enchant to Kustomer requires reorganizing your customer data into a timeline-based structure.

By following the logical order of Users, then Customers, and finally Conversations, you ensure that your data integrity remains intact.

Take the time to prepare your custom attributes and teams beforehand, validate your data after the migration, and rebuild your workflows once the migration is complete.

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
• Enchant