Migrate from Trengo to Intercom

Trengo's Conversations map to Intercom Tickets as the primary case record. Each conversation's 7-day rolling window status (open, closed) is resolved at migration time: threads with a last-message timestamp within 7 days of the migration date are migrated as open Intercom Tickets; threads with no activity beyond 7 days are migrated as closed Tickets with the original resolved timestamp preserved. The Trengo conversation ID is stored in a custom attribute trengo_conversation_id__c for audit and cross-reference.

Trengo Messages (inbound, outbound, and internal notes) map to Intercom Conversation Parts. Every message body, timestamp, sender attribution (agent vs customer), and attachment reference migrates as a separate Conversation Part within the parent Ticket. The original message sequence order is preserved by setting Intercom's part_created_at to the Trengo message timestamp. Attachments transfer as Intercom attachment URLs pointing to the migrated file storage.

Trengo Contacts map to Intercom Contacts using email as the primary dedupe key. Standard fields (name, email, phone, avatar) migrate directly. Custom contact properties from Trengo (date, boolean, string, and multi-select types) map to Intercom custom contact attributes by matching the property name and applying type conversion. Trengo's contact channel history (which channels the contact used) migrates as a text attribute listing the channel identifiers.

Trengo does not have a native Company object but supports company associations on contacts via its CRM-like contact profiles. Where contacts in Trengo reference a company name or domain, we create a corresponding Intercom Company record and link the Contact via the Intercom contact-company relationship. The Trengo company identifier is preserved in a custom attribute trengo_company_id__c.

Trengo Users (agents) map to Intercom Admins and Operators based on their role in Trengo. Agent name, email, and active/inactive status migrate directly. Permissions and conversation ownership are not replicated as structured data; we document the role-to-Intercom-permission mapping in a configuration guide for the customer's admin to apply post-migration. Inactive Trengo agents are set to away status in Intercom.

Trengo Teams and their member assignments map directly to Intercom Teams. We export the team roster and recreate the team structure in Intercom. Trengo's channel-to-team routing rules (which team handles which channel or inbox) are exported as configuration data and documented as Intercom Inbox routing rules in the workflow handoff document.

Trengo's Channel objects (WhatsApp, email, Instagram, Facebook, live chat, voice, SMS) define the communication layer. Each Trengo channel is mapped to a corresponding Intercom Inbox or an inbox connection (for email, chat, and voice). WhatsApp Business API channels require re-authentication in Intercom's channel settings since channel credentials do not transfer between platforms. We document the channel mapping and provide the customer with the required reconnection steps for each channel before cutover.

Trengo Tags applied to conversations are exported as flat label arrays and migrate to Intercom Conversation Tags. Tag naming collisions are resolved by prefixing tags from high-volume sources (e.g., social channels) with the channel name to preserve semantic meaning in Intercom's tag list.

Trengo Knowledge Base Articles with body content, categories, and publication status migrate to Intercom Help Center Articles. Article-category hierarchy from Trengo maps to Intercom's Collection-Section structure: each Trengo category becomes a Collection, and sub-categories become Sections within that Collection. Article body HTML is preserved and Intercom re-renders it using its article content renderer. We flag articles with widget associations (Trengo-specific embeds) for manual replacement during the help center rebuild phase.

Trengo workflow triggers and actions are exported as structured JSON where the API exposes them. Intercom's workflow equivalent is the Operator rules engine (Inbox rules, assignment rules, SLA rules). Because workflow semantics differ significantly between platforms, we do not migrate automations as code. We deliver a written inventory of every active Trengo workflow with its trigger type, conditions, actions, and a recommended Intercom Operator rule equivalent for the customer's admin to configure post-migration.