Migrate from Trengo to Zendesk

Each Trengo Conversation maps to one Zendesk Ticket. We preserve the original Trengo conversation ID in a custom field trengo_conversation_id__c for cross-reference and audit. Conversation status (open, resolved, pending) maps to Zendesk Ticket Status values; Trengo's custom status labels are recreated as Zendesk custom ticket statuses in the Admin settings before migration. The channel origin (WhatsApp, email, Instagram, Facebook, voice, live chat, SMS) is preserved as a tag with the prefix channel: (e.g., channel:whatsapp) so that routing provenance is queryable in Zendesk without a separate channel object.

All Messages nested inside a Trengo Conversation (inbound customer messages, outbound agent replies, and internal notes) map to Zendesk Ticket Comments. We set the Comment author type (end-user vs agent vs internal) using Zendesk's Comment.author_type field and the public/private visibility flag. Message timestamps are preserved as Comment.created_at so the full chronological thread is intact in Zendesk. Attachment URLs are extracted from Message records and re-linked as Zendesk Ticket Attachments after ticket creation.

Trengo Contacts map to Zendesk End Users. Standard fields (name, email, phone) map cleanly to Zendesk user.name, user.email, and user.phone. Custom contact properties (date, boolean, multi-select, text) are mapped to Zendesk custom user fields, applying type conversion (Trengo multi-select to Zendesk tag array, Trengo date to Zendesk date field). We resolve duplicate emails during import using Zendesk's duplicate detection so that existing Zendesk users are not over-written.

Trengo User profiles (name, email, role, active/inactive status) map to Zendesk Agents. Agent-level permissions and conversation ownership are preserved as a mapping note for the customer's Zendesk admin to configure Group membership and role-based access manually post-migration. We export the full user roster with trengo_owner_id preserved in a custom field agent_trengo_id__c for reconciliation.

Trengo Teams with their member assignments map to Zendesk Groups. Routing rules (which team handles which channel or inbox) are exported as structured JSON and delivered as a configuration document alongside the migration. The customer recreates these as Zendesk Views and routing rules in Admin because routing logic is destination-platform-native and cannot be lifted from Trengo directly.

Trengo Channels (WhatsApp, email, Instagram, Facebook, voice, live chat, SMS) do not have a direct Zendesk equivalent as data objects. We capture channel assignments per Conversation and apply them as Zendesk Tags with the prefix channel: for reporting segmentation. Channel credentials (WhatsApp Business API tokens, email SMTP configs) are flagged in the discovery inventory as items requiring manual reconfiguration in Zendesk Admin under Channels.

Trengo Knowledge Base articles with body content, categories, and publication status map to Zendesk Guide articles. Article-category hierarchy is preserved as Zendesk Section and Category structure. We map Trengo article IDs to a custom field trengo_article_id__c on Zendesk articles for cross-reference. Any linked widget associations (public vs internal article visibility) are mapped to Zendesk article permission settings (article is in Help Center or restricted). Zendesk Guide must be activated in the target account before article import begins; we confirm this during scoping.

Tags applied to Trengo Conversations or Contacts are exported as flat label arrays and applied as Zendesk Tags. We apply a naming map to avoid collision at the destination (prefixing with trengo_ for any tag that might conflict with Zendesk's system tag names). Tag taxonomy differences are documented in the handoff so the customer's admin can consolidate or rename tag sets post-migration.

Trengo workflow triggers and actions exported as structured JSON are delivered as a written workflow inventory. Because Trengo workflows use Trengo-specific event triggers (conversation opened, message received, channel assignment) that have no direct Zendesk equivalent, we document each workflow's trigger conditions, actions, and delay logic alongside a recommended Zendesk Trigger or Automation equivalent. The customer's admin rebuilds workflows in Zendesk Admin post-migration. This is not included in migration scope.

Historical aggregated reporting data (CSAT, response times, channel volumes) is exportable as CSV from Trengo. SLA thresholds and performance benchmarks from the source system do not carry forward as Zendesk SLA policies because SLA configuration is destination-platform-native. We deliver a CSV snapshot of historical metrics and a written mapping of each Trengo report metric to the corresponding Zendesk Explore report widget for the customer's admin to rebuild in Zendesk Explore.