The Complete Guide to Migrating from Enchant to Intercom

This guide covers the technical process of migrating support data from Enchant to Intercom — including object sequencing, field mapping, API constraints, and the failure modes that catch teams off guard.

Enchant is a streamlined shared inbox. Intercom is a comprehensive customer platform. They model data differently, and the migration requires understanding those differences at the field level before writing a single line of code.

Define Your Migration Scope

Before you begin the technical heavy lifting, you need to decide what goes where. Most of your historical data, including your tickets, the messages within them, your customer records, and your organizational tags, will be moved via the Intercom API.

This ensures that the depth of your support history remains intact and searchable.

However, not everything can be handled by a script. Your structural elements, such as your internal team members (Admins) and your departmental groupings (Inboxes), need to be configured manually within the Intercom interface.

There is no direct programmatic way to recreate these administrative settings.

Finally, consider what needs to be archived. If you have thousands of contacts who have not interacted with you in years, Intercom provides a dedicated archive feature to keep your workspace clean while retaining their data for future reference.

What Does Not Survive the Migration

Not everything in Enchant has a direct equivalent in Intercom. Before you start, review this list of data that is lost or degraded during migration:

• Conversation ratings / CSAT scores — Enchant's satisfaction data has no direct import path into Intercom's CSAT model. You can store historical scores as conversation note metadata, but they will not populate Intercom's native reporting.
• SLA policy configurations — These must be rebuilt manually in Intercom. Historical SLA breach/meet data from Enchant does not transfer.
• Webhook subscriptions and event history — Enchant webhook configurations are platform-specific and cannot be ported. Event logs are not part of the migration payload.
• Custom workflow rules — Enchant routing rules do not map to Intercom workflows. These must be recreated from scratch in Intercom's workflow builder.
• Closed vs. open ticket handling — Intercom treats closed conversations differently from open ones during import. Closed tickets imported via API will not trigger automations or appear in active queues, which is usually the desired behavior, but you should verify that your reporting captures them correctly.

Knowing what you will lose upfront is more valuable than discovering it after cutover.

Enchant → Intercom Field Mapping

The table below maps Enchant objects and fields to their Intercom equivalents. Review this before building any migration scripts — it defines what transforms cleanly, what requires transformation, and where data loss occurs.

Prepare Intercom for Data Import

Preparation defines whether the migration succeeds or fails silently. You must rebuild your help desk framework before importing any records.

Start by adding your team members. In Enchant, these are your users; in Intercom, they are Admins. You will need to invite them manually so they have active accounts to which tickets can be assigned.

Once your people are in, set up your Teams. Enchant uses Inboxes to separate different communication streams, such as sales or support. You should create corresponding Teams in Intercom to mirror this structure.

This step is vital because when you eventually import your tickets, you will want to tell Intercom which team owns which ticket.

Recreate your labeling system by setting up Tags. This allows your imported data to be categorized exactly as it was in your previous system.

Finally, pre-create any custom data attributes in Intercom that you need to receive data from Enchant's custom fields. This step is easy to skip and impossible to fix retroactively without re-running the migration.

Migrate Objects

The order in which you move your data is the most critical part of the process. If you move tickets before customers, those tickets will have no owners. Follow this logical sequence to keep your data integrity high.

1. Customers and Contacts:

In Enchant, a customer is a high-level entity that contains specific contact information, such as email addresses or phone numbers. Intercom uses a unified Contact model.

When you migrate these, you are creating the foundation for everything else. You will move the names and contact details first so that every ticket migrated later has a person to attach to.

2. Tickets:

With your customers and teams ready, you can move the tickets. Enchant tickets are containers for conversations.

In Intercom, the Ticket object serves a similar purpose. During this phase, you will recreate the ticket shells, ensuring they are linked to the correct customer and assigned to the right team or admin.

3. Messages, Notes, and Replies:

This is where the actual conversation lives. Enchant separates internal communication (notes) from customer-facing communication (replies).

Intercom treats these as conversation parts. You will migrate these one by one into the newly created tickets.

It is important to maintain the original timestamps so the conversation flow makes sense to anyone reading it later.

4. Attachments:

Attachments require a specific workaround. In Enchant, files are uploaded separately to generate a unique identifier before being added to a message.

Since Intercom handles attachments differently in its ticket creation, the most reliable method is to include the direct URL of the Enchant attachment within the body of the message or the ticket description.

This ensures your team can still access vital files without needing to rebuild a complex file hosting logic. The trade-off: native attachment metadata (file size, upload date, thumbnail previews) is lost. The file itself remains accessible via the URL as long as Enchant hosting persists.

Rate Limits and Retry Logic

Enchant limits API requests to one hundred per minute. Intercom's API enforces its own rate limits that vary by endpoint and plan tier. Both APIs return HTTP 429 Too Many Requests when you exceed the limit.

Your migration script must handle this. At minimum:

• Check for 429 responses on every API call.
• Read the Retry-After header (if present) to determine how long to wait before retrying.
• Implement exponential backoff as a fallback if no Retry-After header is returned.
• Log every throttled request so you can identify bottlenecks and estimate total migration time.

For context: at 100 requests/minute on the Enchant side, exporting 10,000 tickets with an average of 5 messages each requires roughly 850 minutes (~14 hours) of API time for export alone, assuming no retries. Plan accordingly.

Search Indexing Delay

Intercom has a delay between when a contact is created via API and when that contact becomes searchable. If your script creates a contact and immediately queries for it to link a ticket, the lookup may fail.

The fix: after creating a contact, store the returned id in your local mapping rather than searching for the contact by email. If you must search, add a wait of several seconds before the lookup. This single issue is the most common cause of ticket-contact mismatches in Intercom migrations.

Common Failure Modes

Migrations fail in predictable ways. Here are the ones that apply to Enchant → Intercom specifically:

Post Migration Configuration

After the data is successfully in Intercom, you must rebuild the automation that makes your support efficient. Workflows are the primary example.

Any rules you had in Enchant for routing tickets based on keywords or customer types will need to be recreated using Intercom's workflow builder.

This is also the time to configure your AI settings. If you use Intercom's Fin AI agent, you should begin importing your external help pages as content sources so the agent can learn how to answer your customers based on your existing documentation.

Summary

Migrating from Enchant to Intercom requires manual setup of admins and teams first, followed by automated migration of contacts, tickets, messages, and attachments in that order. The process is sequential and order-dependent — skip a step and downstream records will be orphaned or mislinked.

The primary technical risks are rate limiting on both APIs, search indexing delays causing ticket-contact mismatches, silent dropping of unmapped custom attributes, and attachment URL rot after Enchant account decommission.

Take it one object at a time, respect the rate limits, validate with spot checks after each phase, and document every transformation decision.

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 Documentation
• Intercom API Reference