The Complete Guide to Migrating from Help Scout to Enchant

Moving from Help Scout to Enchant requires a clear plan. This guide covers the API migration sequence, field mapping, rate limits, failure handling, and what cannot be migrated.

Defining Your Migration Scope

Before you start writing scripts or clicking buttons, you need to decide exactly what is coming with you. Some data is best handled through automated tools, while other elements require a more hands-on approach.

Most of your core data, including staff users, customer profiles, tags, and the actual history of conversations and messages, can be migrated via the API. This ensures that your historical context remains intact without manual data entry.

What Cannot Be Migrated via API

Not every object has a direct API path. The following require manual reconstruction:

For older data you no longer need for daily operations, you may choose to archive it within Help Scout rather than moving it at all.

Preparing Enchant for Data Import

You cannot simply dump data into a new system; you must first build the containers that will hold it.

The most critical step is manually creating your Inboxes within Enchant (mapping). Because a ticket must always belong to an inbox, you need those inbox IDs generated in Enchant before you can route any migrated conversations.

Additionally, you should take this time to define your Labels, which serve as the Enchant equivalent of Help Scout Tags.

While you can create these via API, setting them up beforehand allows you to map your categorization logic cleanly.

Ensure your staff users are also invited to the platform so that their email addresses are recognized when you start assigning ticket ownership later.

Field Mapping: Help Scout → Enchant

The table below maps the primary Help Scout objects and fields to their Enchant equivalents. Fields marked No equivalent are dropped silently unless you create a custom field or store the data in a note.

Migrate Objects

The order in which you move your data is vital because many objects depend on others to exist. Follow this sequence to maintain a clean data model:

1. Users

List your Help Scout users and ensure they exist in Enchant. Each user in Enchant has a unique ID that you will need to associate with every ticket and message they have ever touched.

Endpoint: GET /v1/users (Enchant) to retrieve existing user IDs. Match against Help Scout user emails.

2. Customers

Migrate your customer database. Enchant identifies customers through their contact information, such as email addresses or phone numbers. By creating these profiles first, you generate the necessary customer_id values required to open a ticket.

Endpoint: POST /v1/customers — required fields include email.

3. Tags and Labels

Map your Help Scout tags to Enchant labels. Create any labels that do not already exist, and record the resulting label_id values for use when creating tickets.

Endpoint: POST /v1/labels — required field: name.

4. Attachments

In Enchant, attachments must be uploaded as standalone resources before they can be referenced in a message. Take the file data from Help Scout, Base64-encode it, upload it to Enchant to receive a new attachment_id, and store that ID for the next step.

Endpoint: POST /v1/attachments — required fields: filename, content_type, data (Base64-encoded).

5. Tickets (Conversations)

Create the shell of the conversation. A ticket in Enchant contains the high-level data: subject, associated customer, and the inbox it lives in.

Endpoint: POST /v1/tickets — required fields: inbox_id, customer_id, subject.

Store the returned ticket_id — you will need it to attach messages in the next step.

6. Messages (Threads)

Move the individual replies and notes into those tickets. Enchant distinguishes between reply and note message types. Reference the attachment_id values captured in step 4.

Endpoint: POST /v1/tickets/{ticket_id}/messages — required fields: type (reply or note), body. Include attachment_ids array if applicable.

API Constraints, Rate Limits, and Edge Cases

Enchant Rate Limits

Enchant allows 100 credits per minute. Each API call costs one credit. If you hit the limit, the response will include a Retry-After header indicating how long to wait before sending more requests. Build a back-off loop into your migration script that reads this header rather than using a fixed sleep interval.

Help Scout API Behavior

Help Scout's REST API paginates responses. The default page size is 50 items; set page [size] to 100 (the maximum) to reduce round-trips. Requests return a page object with totalPages — iterate through all pages before assuming you have a complete export.

Help Scout also enforces its own rate limits. Requests that exceed the threshold return HTTP 429 with a X-RateLimit-Retry-After header. Log and handle these the same way as Enchant's limit.

Timestamps

Always use ISO8601 format (e.g., 2024-03-15T10:30:00Z) for all timestamp fields. Sending epoch integers or non-standard date strings will cause field rejection or incorrect chronological ordering in Enchant's UI.

Idempotency and Restart Safety

If a migration run is interrupted mid-batch, re-running it without safeguards will create duplicate records. Before each insert, query Enchant to check whether the record already exists (match on customer_id + subject + created_at for tickets, or email for customers). Alternatively, maintain a local mapping table that records help_scout_id → enchant_id for every successfully migrated object. On restart, skip any ID already present in the mapping table.

Failure and Recovery

Post-Migration Configuration

Once the data is in, your work moves back into the Enchant settings. Automated workflows and routing rules do not migrate via API and must be rebuilt manually.

You will need to look at your Help Scout Workflows and replicate that logic using Enchant's automation tools to ensure that new incoming mail is handled correctly.

This is also the time to set up your Saved Replies. Since these were not part of the API migration, your team will need to copy their most-used templates into the Enchant interface to maintain their response speed.

What Cannot Be Migrated

The following data has no API migration path and will not transfer automatically:

• Saved Replies — must be manually recreated in Enchant
• Knowledge Base content — Docs collections, categories, and articles must be rebuilt
• Automated Workflows and routing rules — logic must be re-entered in Enchant's UI
• Conversation closedAt timestamps — no direct Enchant field; preserve in a message note if the audit trail matters
• Help Scout custom field values — only transferable if matching custom fields are pre-created in Enchant
• Archived conversations — you may choose to leave these in Help Scout rather than migrate them

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
• Help Scout