The Complete Guide to Migrating from Freshdesk to Enchant

This guide covers the practical steps for migrating your data from Freshdesk to Enchant, including object mapping, dependency order, attachment handling, and the API constraints you'll hit along the way.

By understanding the underlying data models of both platforms, you can ensure a smooth transition for your support team.

Define your migration scope

Before writing a single line of code, you must determine what data needs to move and how. Most of your high-volume data will be migrated via the API.

This includes the core pillars of your helpdesk: Inboxes (Groups), Users (Agents), Customers (Contacts), and the full history of Tickets and Messages (Replies and Notes).

There are certain configurations that you should handle manually. Canned Responses and SLA Policies fall into this category because they often benefit from a "fresh start" to ensure they align with Enchant's specific feature set.

Freshdesk automatically archives closed tickets that have been inactive for 120 days to maintain performance. You should decide if these archived records are necessary for your current operations or if they should remain in Freshdesk for long-term reference.

Note that Freshdesk custom fields, satisfaction ratings, and multi-product structures do not have direct equivalents in Enchant. Plan for how you'll handle these before starting — whether that means flattening custom field data into Enchant's available fields, exporting it separately for reference, or accepting the data loss.

Also be aware that any webhooks, marketplace apps, or third-party integrations connected to Freshdesk will not carry over. Inventory these before migrating so you can reconnect or replace them on the Enchant side.

Prepare Enchant for data import

In Enchant, every ticket must belong to an inbox, so you need to create these first to provide a destination for your data. You should also pre-configure your team by setting up your Users.

This ensures that when tickets are imported, they can be assigned to the correct person immediately.

You should also pre-create your Labels. Freshdesk uses Tags as simple strings, but Enchant identifies Labels by unique IDs.

By setting these up in the Enchant settings first, you can capture the IDs needed to tag tickets correctly during the migration process.

Field mapping reference

Before you start writing migration code, map every field you care about. The table below covers the core objects:

Status mapping

Freshdesk uses numeric status codes. Enchant uses text-based states. Map them explicitly:

Edge case: Freshdesk allows custom statuses beyond these defaults. Audit your instance for any custom status values and decide on an Enchant mapping before you begin.

Migrate objects

The order in which you move your objects is critical for maintaining the relationships between records. Follow this logical sequence to prevent orphan data.

1. Inboxes and Users:

Start by mapping your Freshdesk Groups to Enchant Inboxes and your Freshdesk Agents to Enchant Users. This builds the framework of your new helpdesk.

2. Customers and Contacts:

The data model for people is slightly different between the two platforms. Freshdesk uses a single "Contact" object. Enchant, however, separates the identity of the person (the Customer) from their specific identifiers like email or phone (the Contacts).

During migration, you must create the Customer record first and then associate their individual Contact identifiers with that Customer ID.

In pseudocode, the flow looks like this:

# Create the Customer, then attach Contact identifiers
customer = enchant_api.create_customer(name=freshdesk_contact["name"])
 
for email in freshdesk_contact["emails"]:
    enchant_api.create_contact(
        customer_id=customer["id"],
        type="email",
        value=email
    )

3. Tickets and Tags:

Once the customers exist, you can migrate the ticket shells. You will need to map Freshdesk's numeric status values into Enchant's text-based states using the status mapping table above.

During this step, you will also apply your pre-created Labels to match the original Freshdesk Tags.

4. Messages and Attachments:

With the ticket shells in place, you can pull the full history of Conversations. Both public replies and private notes are imported as Messages in Enchant.

Attachments require special handling: you must download the file from Freshdesk, convert it to Base64 data, and upload it to Enchant to generate an attachment ID before linking it to the specific message.

The attachment flow in pseudocode:

# Download from Freshdesk, encode, upload to Enchant, then link
file_bytes = freshdesk_api.download_attachment(attachment_id)
base64_data = base64.b64encode(file_bytes).decode("utf-8")
 
enchant_attachment = enchant_api.upload_attachment(
    filename=original_filename,
    content_type=mime_type,
    data=base64_data
)
 
# Link immediately — unlinked attachments are eventually deleted
enchant_api.create_message(
    ticket_id=ticket_id,
    body=message_body,
    attachments=[enchant_attachment["id"]]
)

5. Companies:

Since Enchant does not have a native Company object like Freshdesk, you should use a workaround. Storing the Freshdesk Company name in the Enchant Customer "summary" field is an effective way to preserve this organizational context for your agents.

Validation and rollback

After migration completes, verify the results before going live:

• Record counts: Compare total Customers, Tickets, and Messages between Freshdesk and Enchant. They should match exactly (minus any records you intentionally excluded).
• Spot checks: Open a sample of tickets across different statuses and verify that messages, attachments, labels, and assignments came through correctly.
• Attachment integrity: Confirm that a sample of attachments are downloadable and not corrupted.

If you discover data issues mid-migration — say the script fails at step 4 after tickets are created but before messages are attached — you have two options: fix and resume from the failure point (if your script tracks progress), or delete the partially imported data in Enchant and restart. Enchant's API supports deletion, so a clean restart is feasible if needed.

Running Freshdesk and Enchant in parallel for a short period is a practical approach: keep Freshdesk active for incoming tickets while you validate the migrated data in Enchant, then cut over once you're confident.

Rate limits and error handling

Migrating data at scale requires an understanding of technical constraints that only become apparent once you are deep in the process.

The most important constraint is the rate limit. Freshdesk sets limits based on your specific plan, while Enchant has a global limit of 100 credits per minute for the entire account.

If you exceed these, the API will return a 429 error. Build a retry mechanism with exponential backoff or a queue into your script:

import time
 
def api_call_with_retry(func, *args, max_retries=5):
    for attempt in range(max_retries):
        response = func(*args)
        if response.status_code == 429:
            wait = 2 ** attempt  # exponential backoff
            time.sleep(wait)
            continue
        response.raise_for_status()
        return response.json()
    raise Exception("Max retries exceeded")

Beyond 429s, handle partial failures gracefully. If a message creation fails for a single ticket, log the failure with the Freshdesk ticket ID and Enchant ticket ID so you can retry that specific record later without re-running the entire migration.

Another important behavior: unlike Freshdesk, which provides a simple URL for attachments, Enchant requires the attachment to be associated with exactly one message at the time of creation. The "upload then link" workflow described above is non-negotiable.

Post-migration configuration

After the data has been successfully moved, you need to rebuild your operational logic. Freshdesk Automations, including rules that run on ticket creation, ticket updates, or hourly triggers, must be manually recreated within Enchant.

This is also the time to set up your live workflows, such as automatic ticket assignment and notification rules, to ensure your team can handle new incoming requests immediately.

Summary

A successful migration from Freshdesk to Enchant is about meticulously preserving the links between your team and your customers.

By following a structured sequence, from setting up your Inboxes to encoding your attachments, you can move your history without losing a single detail.

Once the data is in place and your automations are rebuilt, your team will be ready to provide support in their new environment.

Further Reading:

• Enchant API documentation
• Freshdesk API documentation