The Complete Guide to Migrating from Enchant to Trengo

Moving your support operations from one platform to another requires a clear understanding of how data translates between systems.

Enchant is a shared inbox solution that organizes conversations through tickets and messages. Trengo offers a multi-channel inbox that structures the same interactions around Profiles, Contacts, and Labels rather than Enchant's customer/tag model.

By following a structured migration path, you can ensure that your team maintains a complete history of every customer interaction without losing critical context.

Define Your Migration Scope

Before starting, you must categorize your data into three buckets: API migration, manual configuration, and archiving.

The API migration covers the bulk of your active and historical data. You will move Users, Customers (Profiles), Contacts, Labels, Tickets, and Custom Fields directly through programmatic means. Messages (Replies and Notes) and Attachments also move via the API, though they require specific handling to ensure they link correctly.

Manual configuration is required for organizational elements that are not accessible via Enchant's public API. This includes setting up your Teams and creating your library of Quick Replies.

Finally, you should determine what to archive. Some data in Enchant has no direct equivalent in Trengo and cannot be migrated under any circumstances — this includes reporting metrics, CSAT scores, SLA history, and Workflow/Journey logic. These should be exported separately for your own records before you begin.

Prepare Trengo for Data Import

To receive data correctly, Trengo must have its basic infrastructure built out first. You need to rebuild your organizational structure by creating your Teams and adding your Users to the platform.

Without these, you will have no one to assign tickets to during the migration.

Next, you must define your metadata shell. This involves creating Labels that match your Enchant tags and setting up Custom Fields to hold specific data points like VIP status or order numbers.

Trengo uses Profiles as a container, so ensuring these custom fields exist first allows the data to land in the right spot during the import.

Enchant to Trengo Object Mapping

The table below shows how Enchant objects map to their Trengo equivalents. Fields marked as No direct mapping must be handled outside the API migration.

Migrate Objects

Maintaining a logical sequence is the most important part of this process to ensure data integrity.

1. Users and Teams: Start by creating your team members in Trengo. This allows the migration script to map Enchant's user_id to the new Trengo user_id for ticket ownership.
2. Labels and Custom Fields: These are your organizational tags. By creating them early, you can categorize tickets as they arrive.
3. Profiles (Customers): Enchant's customers map directly to Trengo Profiles. A Profile is the master record for a person.
4. Contacts: In Trengo, a Contact (like an email address or phone number) must be attached to a Profile. You will pull the contact values from Enchant and link them to the newly created Trengo Profiles.
5. Tickets: Once the customers exist, you can create the Ticket shells. You will use the Enchant ticket state, such as open or closed, and map it to Trengo's status fields.
6. Attachments: Files must be handled separately. You will upload files to Trengo first to get a unique identifier for each file.
7. Messages and Notes: The final step is filling the tickets with their conversation history. You will migrate Enchant's reply type as a Trengo Message and Enchant's note type as a Trengo Note. You will link the previously generated attachment IDs to these messages during this step.

Timestamp formatting

Trengo's import endpoints expect timestamps in ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ). Enchant exports timestamps in a similar format, but verify timezone handling before bulk import — naive datetime strings without timezone offsets will be interpreted as UTC, which can shift conversation history by several hours for non-UTC teams.

Common failure modes

These are the error patterns most likely to break a migration at scale:

• Orphaned Contacts: A Contact record created before its parent Profile exists will fail to link. Always import Profiles before Contacts.
• Duplicate Profiles: If you retry a failed batch without idempotency checks, you will create duplicate Profile records. Use a local ID map (Enchant customer_id → Trengo profile_id) and check for existence before creating.
• Missing Custom Field IDs: Trengo assigns internal IDs to Custom Fields at creation time. Your migration script must look up these IDs after pre-creating fields in the Prepare step — hardcoding them will break if fields are recreated.
• Attachment token expiry: Upload tokens for attachments in Trengo have a limited validity window. Upload attachments immediately before creating the messages that reference them, not hours earlier in a separate pass.
• Malformed timestamps: See the ISO 8601 note above. This is the most common silent data corruption — conversations import but appear at the wrong time in the thread.

Volume and batching

For migrations under approximately 5,000 tickets, a single sequential pass is usually feasible in one run. Above that threshold, plan for batching: process tickets in chunks and write each completed Enchant ticket ID to a local log before moving to the next batch. This log is your rollback and resume point if the migration fails partway through.

Rollback strategy

Trengo does not provide a native bulk-delete endpoint. If the migration fails at step 5 or later, the cleanest recovery path is to create a fresh Trengo inbox (or use a test environment), identify the point of failure from your ID log, and re-run from the last successfully completed batch rather than attempting to unpick partially imported data.

Post Migration Configuration

Once the data is moved, you must manually rebuild the logic that makes your inbox "smart." Trengo's Workflows and Journeys must be configured from scratch as they do not have a 1:1 mapping in the migration.

You should also set up your Webhooks to ensure that any external systems integrated with your help desk continue to receive updates about ticket changes.

Finally, verify that your Help Center articles, categories, and sections are organized correctly if you chose to rebuild your knowledge base manually.

Import Endpoints vs. Standard Message Creation

Expert migrators know that the standard message creation methods are not ideal for historical data. Instead of sending a standard message, you should use Trengo's Import endpoints for email and text messages.

These endpoints are specifically designed for importing historical conversations. Unlike the standard message creation endpoints, they do not trigger outbound notifications to your customers during the migration process — critical for avoiding mass re-notification of closed conversations. You can find the Import endpoint reference in the Trengo developer docs.

Summary

Migrating from Enchant to Trengo is a process of rebuilding your support history within Trengo's Profile-centric data model.

By prioritizing the creation of Profiles and Users before importing Tickets and Messages, you maintain the vital links between your customers and your team.

While the API handles the heavy lifting for conversation data, the manual setup of your Teams and Workflows ensures your operation is ready for daily use.

Pay attention to timestamp formatting (ISO 8601 with explicit timezone offsets), implement an ID map to avoid duplicate records on retry, and use Trengo's Import endpoints rather than standard message creation to prevent customer notifications.

Further Reading:

• Enchant
• Trengo