Migrate from Zendesk to Intercom

Zendesk Tickets map to Intercom Conversations. The Zendesk Ticket ID is preserved in a custom Intercom conversation attribute for cross-reference. Ticket status (New, Open, Pending, Solved, Closed) maps to Intercom's open/closed state, with Zendesk Pending mapped to Snoozed. The assignee, requester, group, priority, and tags transfer as conversation attributes. Internal notes on Zendesk tickets become part of the conversation body and are marked as note-type messages in Intercom. Comments from agents and requesters populate as standard conversation messages in chronological order. Status transitions in Zendesk that have no Intercom equivalent are logged as conversation state changes in the attribute history.

Zendesk end-users (requesters) map to Intercom Contacts. We import name, email, phone, custom user fields, organization membership, and creation timestamp. The Zendesk user ID is preserved as a custom attribute for cross-referencing. Role assignment (agent vs. end-user) is handled via Intercom's Contact vs. Admin split: agents become Intercom Admins or Teammates; end-users become Contacts. The requester's organization membership in Zendesk maps to a Company membership in Intercom.

Zendesk Organizations map to Intercom Companies. Domain names, details fields, and user memberships transfer. The Zendesk organization ID is preserved as a custom attribute on the Intercom Company. Cross-reference between Zendesk users and their organization memberships maps to Intercom's Contact-Company relationship. Organizations with no members still migrate as Company records with a note flagging the orphan for the customer's admin to reconcile.

Zendesk agents map to Intercom Admins and Teammates. Zendesk role names (admin, agent, light agent, contributor) are preserved in a custom attribute and mapped to the closest Intercom role: Zendesk admins become Intercom Admins; Zendesk agents become Intercom Teammates. Group memberships in Zendesk map to Intercom Teams. We resolve agents by email match against the Intercom destination workspace; any Zendesk agent without a matching Intercom user goes to a reconciliation queue for the customer's admin to provision.

Zendesk Brands have no direct Intercom equivalent. Multi-brand Zendesk accounts require a pre-migration decision: either consolidate all brands into a single Intercom workspace (with brand identity preserved in conversation tags and attributes) or provision separate Intercom workspaces per brand. We document the brand structure during discovery and deliver a written brand mapping plan. Customers who need strict brand isolation in Intercom must configure separate Inboxes per brand and use routing rules; we provide the routing rule specification as part of the handoff documentation.

Intercom has no native SLA enforcement. Zendesk SLA Policies (first-response and resolution targets) cannot be recreated as a native feature. We migrate SLA Policy definitions as custom conversation attributes on each Conversation (e.g., sla_policy_name, first_response_target, resolution_target, plan_tier) and store a written SLA inventory document. The customer's admin or an Intercom integration partner can rebuild SLA tracking using third-party SLA tools (e.g., SLAzen, CAIWA) or a custom webhook-based solution. We do not implement SLA tracking software as part of the migration scope.

Zendesk Views (saved ticket filters with columns and sort order) have no direct Intercom equivalent. Intercom uses Inboxes with assignment rules rather than saved filters. We export View definitions as structured data and deliver a written specification mapping each Zendesk View to a recommended Intercom Inbox configuration and assignment rule set. The customer's admin recreates the inbox views manually. We test the inbox configuration during the sandbox migration phase and flag any Views with no achievable Intercom equivalent.

Zendesk Macros (canned reply templates with variable substitution) map to Intercom Templates and Saved Replies. Variable placeholders like {{ticket.requester.name}} require manual conversion to Intercom's {{contact.name}} syntax. We export full macro content and deliver a written macro-to-template mapping document. Macros with complex conditions (e.g., 'apply only if ticket priority is high') cannot be enforced in Intercom without manual operator behavior; we flag these in the handoff documentation with a recommendation to use Intercom Rules for condition-based application.

Zendesk Triggers (event-driven automation on ticket creation or update) map partially to Intercom Rules. Intercom Rules support conversation events, assignment, and routing but lack time-based batch processing and the 1,000-tickets-per-hour bulk action model that Zendesk Automations provide. We export full trigger definitions and deliver a written Trigger-to-Rules mapping document. Complex triggers with multiple conditions, field updates, and notification chains require manual rebuild in Intercom's Rules engine. We do not migrate Triggers as code.

Zendesk Automations (time-based, hourly batch processing) have no direct Intercom equivalent. Intercom Rules are event-driven only, not scheduled. Any Zendesk Automation that fires on a time delay (e.g., 'close ticket if no response in 48 hours') cannot be recreated natively in Intercom. We audit active automations during discovery, flag any with no Intercom Rule equivalent, and deliver a written inventory specifying which automations require a third-party workflow tool (e.g., Zapier, Make) or custom webhook solution post-migration.

Zendesk tags (flat string labels on tickets, users, and organizations) map to Intercom Tags. We migrate all tag assignments and recreate them on Intercom. Tag naming collisions are handled by appending the source object type suffix (e.g., ticket_billing vs. contact_billing). Tags used for routing in Zendesk (e.g., routing to specific groups or teams) are documented in the routing rule handoff and mapped to Intercom Team assignment rules.

Zendesk Help Center articles map to Intercom Articles. We use Zendesk's Help Center API to iterate over Sections and Categories, download article HTML content and attachments, and reconstruct the KB structure in Intercom. Article section hierarchy maps to Intercom's collection structure. Published, draft, and archived states transfer. Article translations (Dynamic Content variants) map to Intercom's locale support per article. Articles embedded in Zendesk's Guide are not available to Fin AI during the migration window; we document the Fin AI training step required post-import to activate resolution bot deflection.