The Complete Guide to Migrating from Enchant to Freshdesk

Migrating from Enchant to Freshdesk requires careful attention to the structural differences between the two platforms.

While both offer shared inbox functionality, their underlying data models diverge in ways that will break your migration if you do not account for them upfront.

This guide covers the technical steps for moving your data with historical context intact.

Define your migration scope

Before you write a single line of code, decide what travels via API and what requires manual configuration.

Most of your core data moves via API due to volume: agents, customers, inbox structure, and the full ticket history including replies, notes, and attachments.

Some elements are better configured manually to ensure they behave correctly in the new environment: business hours, SLA policies, and complex automation workflows.

Enchant handles archived tickets differently from Freshdesk. Plan to migrate archived records into a closed status in Freshdesk. This keeps historical data accessible for reporting without cluttering active ticket views.

Prepare Freshdesk for data import

You cannot move data into a system that is not ready to receive it.

Rebuild your custom data models first. If you used custom fields in Enchant to track order numbers or product versions, create the equivalent Ticket Fields or Contact Fields in Freshdesk before starting the import. Custom fields must exist before any record that references them is created.

Establish your organizational framework. Set up Roles to define what your team can see and do. If you use advanced routing, configure Skills as well.

Define Business Hours and SLA Policies before importing tickets. Freshdesk calculates due dates at ticket creation time. If SLA policies are not in place when tickets are created, migrated records will have incorrect or missing due dates that cannot be retroactively corrected without re-importing.

Migrate objects in dependency order

The sequence in which you migrate objects is the most critical factor in a clean migration. Creating a ticket before its assigned agent exists breaks the association permanently.

Follow this order:

1. Groups — Migrate Enchant Inboxes as Groups in Freshdesk. These are the primary containers for your team's work and must exist before agents are assigned to them.

2. Agents — Migrate Users as Freshdesk Agents and assign them to the Groups created in step 1.

3. Contacts — Migrate Enchant Customers into the Freshdesk Contact model. This step requires careful transformation. Enchant separates the Customer record from its individual contact identifiers. Freshdesk combines these into a single Contact object. You must bundle all associated emails and phone numbers from an Enchant customer record into the email, phone, and other_emails fields on the Freshdesk Contact.

4. Tickets — Map Enchant labels to the Freshdesk tags array. You must also translate Enchant's text-based states into Freshdesk's numeric status values: 2 = Open, 3 = Pending, 4 = Resolved, 5 = Closed. Write an explicit mapping function for this; do not assume string matching will work.

5. Conversations — Migrate Messages as Conversations. This includes all replies and internal notes.

6. Attachments — Attachments in Enchant are returned as URLs (typically S3 presigned links). Your migration script must download the file from that URL and re-upload it to the corresponding Freshdesk ticket or reply using a multipart/form-data POST to the /api/v2/tickets/{id}/attachments endpoint. Do not attempt to pass the Enchant URL directly to Freshdesk; the presigned links expire and Freshdesk does not accept external attachment URLs in the standard ticket creation payload.

Field mapping reference

Post-migration configuration

Once data is in Freshdesk, rebuild your operational layer.

Start with automation rules: those that trigger on ticket creation, those that respond to ticket updates, and those that run on a schedule.

Recreate your Scenario Automations — the one-click macros your agents use for repetitive tasks.

If you use canned responses, bulk import your templates into folders once the data structure is stable.

Reconfigure satisfaction surveys so you can continue measuring customer happiness from day one.

Known edge cases and workarounds

Snoozed tickets. Enchant has an explicit snoozed state. Freshdesk has no direct equivalent. Map snoozed tickets to status: 3 (Pending). They will not count against active response SLAs but will remain visible to agents. If the snooze timestamp matters for your team, store it in a custom ticket field before migration.

Rate limits. Freshdesk enforces per-minute request limits that vary by plan. Build a retry mechanism that reads the X-RateLimit-Remaining and Retry-After response headers. When X-RateLimit-Remaining reaches zero, pause and wait the number of seconds specified in Retry-After before resuming. If you are migrating a large volume, contact Freshdesk support before starting to request a temporary rate limit increase.

Contact deduplication. Freshdesk will auto-create a Contact if the requester email does not exist when a ticket is created. This auto-created record will be incomplete — no phone, no additional emails, no custom field values. Always create Contacts explicitly in step 3 before importing tickets. If a contact with a matching email already exists in Freshdesk when you attempt to create it, the API will return a 422 with a duplicate email error. Your script must handle this by fetching the existing contact's ID and using it in the subsequent ticket payload rather than retrying the contact creation.

Missing agent on ticket assignment. If a ticket references an agent who was not migrated (deactivated accounts, deleted users), Freshdesk will reject the assignment. Audit your Enchant ticket assignments before migration and map any missing agents to a fallback agent ID or leave responder_id null.

Ticket requester vs. contact. Freshdesk combines requester name and contact details into the same API call during ticket creation. Pass the requester_id (the Freshdesk contact ID from step 3) rather than an email string. Using an email string triggers auto-contact creation and bypasses your deduplication logic.

Enchant attachment URL expiry. Presigned S3 URLs returned by the Enchant API expire. If your migration script fetches attachment metadata in a first pass and uploads in a second pass, the URLs may be expired by the time you attempt the download. Fetch and upload attachments in a single pass per ticket, or re-fetch the Enchant ticket before the upload step.

Summary

Migrating from Enchant to Freshdesk requires a strict dependency order — groups before agents, agents before contacts, contacts before tickets. The field mapping between the two data models is manageable but not trivial: numeric status values, contact bundling, and attachment re-uploading are the three steps most likely to produce silent data loss if handled incorrectly.

API handles the volume. Manual configuration of SLAs, workflows, and automations provides the operational layer that makes the platform functional on day one.

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