The Complete Guide to Migrating from Trengo to Enchant

Moving from Trengo to Enchant requires mapping two different data models, working around API constraints, and sequencing imports so relational integrity holds. This guide covers the technical process end to end.

Defining Your Migration Scope

Not everything in Trengo has an equivalent in Enchant. Before writing any migration code, categorize every Trengo object into one of three buckets:

The "no equivalent" items cannot be migrated or recreated in Enchant. Archive them from Trengo before cutover so the data is preserved outside the migration scope.

Preparing Enchant for Data Import

Before pushing any data, set up the receiving environment:

1. Install the API app in Enchant settings. This gives you your site identifier and bearer token for authentication.
2. Create Inboxes. Every ticket in Enchant must belong to an inbox. Map each Trengo Team to an Enchant Inbox and create them before any ticket import.
3. Create Custom Fields in settings. The field structure must exist before data arrives. Enchant does not auto-create fields from API payloads.

Authentication uses a bearer token in the Authorization header. All requests require the Content-Type: application/json header — omitting it is a common cause of rejected requests.

Import Sequence and Dependencies

The import order is not arbitrary. Each step depends on the previous one because Enchant enforces referential integrity: a ticket cannot reference an assignee that does not exist yet, and a message cannot reference a ticket that has not been created.

Import in this order:

1. Users — Create agent accounts first. Every ticket assignment and internal note references a User ID.
2. Customers (Profiles) — Create customer records. Tickets reference customers by ID.
3. Contacts — Attach email addresses and phone numbers to existing Customer records.
4. Labels — Create all labels so they can be applied during ticket import.
5. Attachments — Upload each attachment individually to obtain an Enchant attachment ID. Attachment data must be Base64 encoded before sending. You need the returned IDs before you can link attachments to messages.
6. Tickets — Create tickets and assign them to the correct Inbox, User, and Customer. See the channel workaround below.
7. Messages — Import replies and internal notes, linking them to their parent ticket and attaching any pre-uploaded attachments.

If you reverse steps 1–2 and 6 (for example, importing tickets before users), ticket assignment fails silently or errors out depending on the endpoint. There is no bulk "re-link" operation — you would need to delete and re-import.

Non-email ticket workaround

The Enchant public API only supports creating tickets with the email type. Tickets originating from WhatsApp, SMS, Facebook Messenger, or other Trengo channels must be created as email-type tickets. To preserve channel provenance, apply a label indicating the original source (e.g., source:whatsapp, source:sms). This is a data-fidelity tradeoff: the ticket content is preserved, but the channel metadata is reduced to a tag.

Custom field workaround

Enchant does not expose custom field writes through its public API. Two options:

• Concatenate custom field key-value pairs into the Customer summary field. Format example: Plan: Enterprise | Renewal: 2025-09-01 | CSM: Jane Doe
• Add custom field data as a private note on the ticket. This keeps it searchable but not structured.

Both approaches lose the ability to filter or report on custom fields as discrete values.

Rate Limits and Migration Duration

The Enchant API enforces a rate limit of 100 credits per minute. Exceeding this returns a 429 Too Many Requests error.

Your migration script must implement backoff logic. A simple approach: after receiving a 429, wait 60 seconds before retrying. A better approach: track credit consumption per window and throttle proactively.

Timestamps in Enchant use ISO 8601 format in UTC, which matches Trengo's reporting structure. No timezone conversion is needed if your export preserves UTC.

Post-Migration Configuration

Once data is imported, rebuild the operational logic manually:

• Quick Replies — Recreate in Enchant UI. No API import path.
• Webhooks — Reconfigure endpoints in Enchant settings.
• Journeys / automations — Rebuild ticket routing and workflow rules.
• Phone integrations — If your team used VoIP logging in Trengo, verify that external phone integrations are linked in Enchant.

Validation

After import, run these checks before cutover:

• Record counts — Compare total Users, Customers, Tickets, and Messages between Trengo export and Enchant.
• Spot-check assignments — Verify that a sample of tickets are assigned to the correct User and Inbox.
• Attachment integrity — Open a sample of attachments to confirm they rendered correctly after Base64 encoding.
• Label coverage — Confirm that non-email tickets carry their source-channel label.
• Custom field data — Check that concatenated data appears in Customer summary fields or as private notes.

If counts do not match, check your logs for 429 errors or failed writes that were not retried.

Summary

Migrating from Trengo to Enchant is a relational data migration with several API constraints: email-only ticket creation, no custom field API, Base64 attachment encoding, and a 100-credit-per-minute rate limit. The workarounds are straightforward but must be planned for. The non-negotiable rule is import sequencing — Users and Customers before Tickets, Tickets before Messages.

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 v1 documentation
• Trengo API reference