The Complete Guide to Migrating from Trengo to Intercom

Moving from Trengo to Intercom involves navigating API compatibility and understanding conceptual data model differences, especially concerning how user records and historical conversations are handled.

This guide covers scoping, preparation, execution order, and the technical pitfalls we've encountered running these migrations.

Define Your Migration Scope

Not every piece of data transfers using a direct API call. Some objects require automated workarounds while others must be recreated manually in the target system. Categorizing everything up front prevents surprises mid-migration.

Data Model Mapping

The table below shows how Trengo objects map to their Intercom equivalents and how each is migrated:

Objects Migrated via API

The bulk of your critical historical data and configuration settings can be moved using API methods.

This includes foundational items like Contacts (Trengo Contacts and Profiles map to Intercom Contacts), their Notes, and configuration definitions such as Custom Fields, Labels (mapping to Intercom Tags), Ticket Results (mapping to Intercom Ticket Types/States), and Help Center Articles.

Your historical Tickets and their associated Ticket Messages (conversation history) will be migrated through carefully executed API sequences.

Objects Requiring Manual Configuration

Certain structural and organizational entities lack API support for creation in Intercom, even if Trengo allows creation via API.

Users (Admins) and Teams must be manually provisioned and configured in Intercom before any records can be assigned to them. The Intercom API only supports fetching or identifying Admins and Teams — it does not support creating them.

Quick Replies (canned responses) also lack a creation API in Intercom, so manual recreation is required.

The top-level Help Center structure requires manual establishment as well.

Data for Archival and Review

Certain operational reports and peripheral functions — Trengo's reporting metrics, user reports, ticket detail reports, and VoIP call logs — should be extracted and archived externally before the migration if historical data is required.

While you can retrieve this data via GET endpoints in Trengo, importing reporting history directly into Intercom's live metrics systems is not feasible using APIs alone.

Pre-Migration Checklist

Before commencing the mass data transfer, verify that every dependency is in place:

• Admins/Users provisioned in Intercom with correct roles
• Teams created and assignment rules configured
• Trengo Custom Fields recreated as Intercom Data Attributes (contacts) or Ticket Type Attributes (tickets)
• Labels created as Tags in Intercom
• Ticket Results mapped to Intercom Ticket Types and Ticket States
• Top-level Help Center created manually
• Trengo Categories created as Intercom Collections
• API credentials configured for both Trengo and Intercom
• Test migration run completed against a subset of records
• Rollback plan documented (see below)

Migrate Objects

This section defines the precise order for data transfer, ensuring relational integrity is maintained across the new platform.

1. Contacts and Profiles

The customer data is paramount. Trengo separates customer information into Contacts and Profiles. In Intercom, the primary customer record is the Contact.

Trengo's dual-object model (Contact + Profile) collapses into a single Intercom Contact. The merge logic matters:

• Migrate all Contacts directly to Intercom Contacts
• Map fields previously stored in Trengo Profiles into corresponding Intercom Contact custom attributes
• Handle duplicates: if a Profile and Contact share the same email, consolidate them into one Intercom Contact rather than creating duplicates
• Transfer any associated Notes attached to these records

2. Labels and Contact Groups

Move your organized categorization systems next. All existing Labels should be applied as Tags to the corresponding Intercom Contacts (and later, Tickets).

For Trengo's Contact Groups, dynamic groups require manual setup as Intercom Segments. Static groups can often be replicated efficiently using Tags applied to the relevant contacts during this phase.

3. Help Center Content

With the structural framework (Help Centers and Collections) prepared, proceed to migrate the content itself.

Export Trengo Articles and import them as Intercom Articles, ensuring they are correctly placed within the newly created Collections (Trengo Categories). This process rebuilds your knowledge base for customer self-service.

4. Tickets and Historical Messages

This is the most complex phase, requiring careful sequencing.

• Create Tickets: Migrate the core ticket records first, using the API to create the corresponding Intercom Tickets. Ensure custom field values set in Trengo are mapped to the correct Intercom Ticket Attributes.
• Assign and Status: Apply Tags (Labels) to the newly created tickets. If possible, assign the ticket owner and team based on your preparatory manual steps. Finally, migrate the status (e.g., set to Closed or Open).
• Import History: Trengo allows the import of historical email and text messages. In Intercom, this history must be injected into the newly created Ticket using the Reply to a ticket mechanism or by creating a Conversation if necessary to establish history. This is the primary workaround for migrating message history, ensuring the chain of events is preserved within the new ticket structure.

Error Handling and Rollback

Migrations fail partially more often than they fail completely. Plan for it.

Common failure modes:

• A contact creation fails because a duplicate already exists → catch the conflict response, fetch the existing contact ID, and continue
• A ticket creation fails because the assigned admin doesn't exist in Intercom → log the failure, create the ticket unassigned, and flag for manual review
• Rate limit exceeded → implement exponential backoff with retry logic; do not simply retry immediately

Rollback strategy:

• Track every created record's Intercom ID alongside its Trengo source ID throughout the migration
• If a migration phase fails partway through, use the ID mapping to delete the partially created records before re-running that phase
• Never run a re-migration without first cleaning up partial data — duplicate contacts and orphaned tickets are harder to fix than a clean restart

Post-Migration Validation

After the data transfer completes, verify the migration before declaring it done:

• Compare record counts: total contacts, tickets, and articles in Trengo vs. Intercom
• Spot-check 10–20 tickets across different date ranges to confirm message history is intact and correctly threaded
• Verify that tags, custom attributes, and ticket states are populated correctly
• Confirm admin and team assignments on a sample of tickets
• Test the Help Center — verify articles appear in the correct Collections and render properly
• Check that no contacts were duplicated during the Profile merge

Post Migration Configuration

Once the data transfer is validated, final configuration steps are necessary to ensure the Intercom workspace is fully operational and optimized for your team.

Recreate operational efficiencies like Trengo Quick Replies manually in Intercom's canned response system. Beyond simple content recreation, you must rebuild complex automated operational logic. This involves configuring assignment rules, setting up triggers and responses, and implementing any complex workflow automation unique to your business processes.

Insider Secrets

Having executed these migrations, certain nuanced points stand out as critical to avoiding delays and unexpected behavior:

• Handling Profile Duplication: Be vigilant about merging customer data. Because Trengo uses both Contacts and Profiles, you must carefully consolidate this information into a single Intercom Contact record. Map fields unique to a Trengo Profile into descriptive custom attributes on the main Intercom Contact, ensuring no data is lost.
• The Velocity of Message Imports: Importing historical ticket messages requires special attention. Trengo offers API endpoints for importing text and email messages, but this process is restricted by rate limits — 60 requests per minute for message imports. Plan for this bottleneck: history import cannot be rushed, and throttling is necessary to prevent API rejection.
• Reporting Exports Require Precise Formatting: If you pull historical operational metrics or ticket details reports from Trengo, date fields must strictly adhere to the ISO 8601 JSON encoded format to avoid errors during extraction.
• Understanding Admin Limitations: The Intercom API only supports fetching or identifying Admins and Teams — it does not support creating them. Agent and team provisioning must be done manually outside of your data migration scripts.
• Test Before You Run Production: Run your migration scripts against a small subset of data first. Create 5–10 test contacts, a handful of tickets with message history, and verify the output in Intercom before processing your full dataset.

Summary

Migrating from Trengo to Intercom requires strategic preparation, rigorous data mapping, and adherence to a logical execution order.

By defining clear boundaries for automated API migration (Contacts, Tickets, Configuration) versus essential manual setup (Admins, Teams, Quick Replies), and by planning for error handling and validation, you can ensure a smooth transition of customer history and knowledge base content.

The careful handling of data transformation — particularly merging Trengo's Contact and Profile model into a single Intercom Contact — is the most technically interesting challenge in this migration and the place where most mistakes happen.

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

• Intercom API Reference
• Trengo API Reference