Skip to main content

Tejas Mondeeri

·5 min read

The Complete Guide to Migrating from Help Scout to Enchant

Migrating from Help Scout to Enchant? Learn the exact API sequence to map customers, move ticket history, and handle attachments while preserving data context

ClonePartner Help Scout to Enchant migration

Making the switch to a new help desk is a significant step toward improving your team's productivity and customer experience.

Moving from Help Scout to Enchant offers a fresh start with a powerful toolset, but getting your data from one to the other requires a clear plan.

This guide will walk you through the process of moving your records effectively while ensuring nothing important is left behind.

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.

However, not every object has a direct path through the API based on the available documentation. Items like Saved Replies and your Knowledge Base, which includes Docs collections, categories, and articles, should be migrated manually.

These are often better to rebuild in the new environment to take advantage of Enchant's specific formatting. For older data that you no longer need for daily operations, you might 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.

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: Start by listing your Help Scout users and ensuring 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.

  2. Customers: Next, 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 IDs required to open a ticket.

  3. Tags and Labels: Map your Help Scout tags to Enchant labels. This allows you to categorize your historical data as it flows into the new system.

  4. Attachments: This is where the process requires a specific workaround. In Enchant, attachments must be uploaded as standalone resources first. You must take the file data from Help Scout, upload it to Enchant to receive a new attachment ID, and then store that ID to be used in the next step.

  5. Tickets (Conversations): Now you can create the shell of the conversation. In Enchant, a ticket contains the high-level data like the subject, the associated customer, and the inbox it lives in.

  6. Messages (Threads): Finally, you move the individual replies and notes into those tickets. Enchant distinguishes between "reply" and "note" types, and this is where you will attach the IDs for any files you uploaded in the previous step.

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.

Insider Secrets

A successful migration often comes down to understanding the technical nuances of both platforms.

One major detail is that Help Scout and Enchant both use rate limiting to protect their systems. Enchant allows 100 credits per minute, and if you hit that limit, you must wait for the reset header's duration before sending more data.

When moving attachments, remember that Enchant expects file data to be Base64 encoded. If you try to send raw binary data, the creation will fail.

Another helpful tip involves Correlation IDs; if you encounter errors while pulling data from Help Scout, keep a log of the Correlation-Id header provided in their response.

This makes it much easier for their support team to help you if something goes wrong during the export. Lastly, always use the ISO8601 format for timestamps to ensure your conversation history displays in the correct chronological order.

Summary

Transitioning from Help Scout to Enchant is a structured process that rewards careful preparation.

By identifying which objects move via API and which require a manual touch, you can ensure a seamless experience for your support team.

Focus on the logical order of operations, starting with users and ending with messages, and you will find that your historical data remains a valuable asset in its new home.

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: