Migrate from Zendesk
to Intercom
Migrating from Zendesk to Intercom shifts customer support from a ticket-centric model to a conversation-first platform that unifies messaging, help center content, and proactive outreach in a single interface. This migration is best suited for teams that want tighter coupling between support, product engagement, and customer communication rather than treating support as an isolated ticketing function.
When Zendesk stops working
Zendesk stops being viable when the ticket-based model creates friction in how your team actually communicates with customers. Modern support increasingly happens through in-app messaging, chat, and asynchronous conversations rather than discrete tickets with open-pending-solved lifecycles. When your team is bolting on Zendesk Chat, adding third-party bot tools, and running a separate onboarding communication tool alongside Zendesk Support, the platform fragmentation creates data silos and context loss. Zendesk's pricing at scale also becomes a factor as agent seat costs compound with add-on products like Guide, Chat, Talk, and Explore, each carrying separate per-agent fees that can exceed Intercom's unified pricing for equivalent functionality.
What Intercom unlocks
Intercom provides a unified messenger that serves as the single interface for live chat, async messaging, help center article surfacing, product tours, and proactive outreach. The conversation model means customer context flows naturally from automated bot interactions to human agent responses without the jarring ticket-creation step. Intercom's product tours and in-app messaging enable support-adjacent workflows like onboarding, feature announcements, and NPS surveys within the same platform. The Fin AI agent handles resolution of common questions using help center content without custom bot-building, reducing first-response times. Custom bot workflows (called Workflows) allow branching logic, data collection, and routing that replaces Zendesk's trigger-and-automation system with a visual builder.
Who should not migrate
Organizations with complex multi-brand support operations where each brand requires isolated ticket queues, help centers, and agent pools will find Zendesk's multi-brand architecture more mature than Intercom's workspace model. Teams that rely heavily on Zendesk Talk for phone-based support should note that Intercom's phone channel is less mature and lacks features like IVR trees and advanced call routing. Enterprises with strict SLA management requirements involving multi-level escalation paths, operational level agreements, and contractual penalty tracking will find Zendesk's SLA engine more configurable than Intercom's simpler SLA rule system.
What usually goes wrong
The most painful failure mode is treating this as a data migration when it is fundamentally a workflow migration. Teams export ticket history from Zendesk but then discover that their entire support operation—macros, triggers, automations, views, SLA policies, and satisfaction surveys—must be rebuilt from scratch in Intercom's completely different paradigm. Zendesk macros with placeholder variables and conditional logic do not map directly to Intercom's macro system, which uses a different variable syntax and has different capabilities. Reporting is another major gap: teams accustomed to Zendesk Explore's custom dashboards, calculated metrics, and multi-dataset reporting find Intercom's built-in reporting less flexible, requiring supplementary tools like Looker or Metabase for equivalent analytics. Help center content migration often goes smoothly at the article level but breaks at the structural level—Zendesk Guide's category-section-article hierarchy does not map directly to Intercom's collection-article structure, and any custom Guide theme styling is lost entirely.
Risk Matrix: Zendesk to Intercom
Zendesk tickets contain internal notes, side conversations, satisfaction ratings, custom field values, and CC'd stakeholders that do not all have direct equivalents in Intercom's conversation model. Bulk imports via CSV or API often flatten this rich context into plain text, losing the thread structure and metadata that agents rely on for context.
Use Intercom's official Zendesk migration tool or a dedicated migration service that preserves conversation threading, timestamps, and agent attribution. Accept that some metadata like side conversations and light agent comments may not transfer and archive the original Zendesk data in a searchable format for historical reference during the transition period.
Zendesk's trigger and automation system uses condition-action pairs that evaluate ticket properties, tags, and time-based criteria. Intercom's Workflow builder uses a visual flow-based model with different condition operators and action types, making one-to-one translation impossible for complex trigger chains.
Export all active Zendesk triggers and automations and classify each by business function rather than technical implementation. Rebuild each function using Intercom's Workflow paradigm, which may require combining multiple Zendesk triggers into a single workflow or decomposing one complex trigger into several simpler workflows. Test each rebuilt automation against historical ticket data to verify equivalent outcomes.
Zendesk agents develop efficient workflows around views, keyboard shortcuts, macro sequences, and ticket field muscle memory that have no equivalent in Intercom's conversation-based interface. The shift from ticket queues to inbox-style conversation management requires relearning fundamental daily workflows.
Provide agents with a side-by-side comparison guide mapping their top 20 Zendesk actions to Intercom equivalents. Run a two-week training period where agents handle a reduced volume in Intercom while maintaining access to Zendesk for overflow. Set explicit expectations that productivity will dip 20-30% in the first two weeks and plan staffing accordingly.
Zendesk supports multi-policy SLA configurations with different targets per priority level, business hours schedules, and breach notifications. Intercom's SLA rules are simpler and may not support the same granularity, particularly around multi-tier escalation and operational-level agreements between internal teams.
Document every active SLA policy in Zendesk with its specific response and resolution targets. Map each to Intercom's SLA capabilities and identify gaps. For contractual SLAs that cannot be replicated natively, implement monitoring through Intercom's API and external alerting to ensure compliance is maintained even if the enforcement mechanism differs.
Zendesk Guide articles have established URLs, meta descriptions, and search engine rankings. Migrating to Intercom's help center changes URL structures, and if redirects are not implemented correctly, existing organic search traffic to support articles drops significantly.
Crawl the existing Zendesk help center to map every published article URL. Set up 301 redirects from old Zendesk URLs to new Intercom article URLs. Preserve meta titles and descriptions during migration. Monitor Google Search Console for crawl errors and ranking changes for 90 days post-migration.
What Must Not Change During This Migration
All open and pending tickets must be resolved or explicitly migrated as open conversations in Intercom before Zendesk agent access is revoked.
Help center article content, including embedded images and internal links, must render correctly in Intercom and maintain equivalent discoverability through search.
Customer-facing SLA commitments must be met continuously throughout the migration with no gap in measurement or enforcement.
Every Zendesk macro that agents use more than five times per week must have a tested Intercom equivalent before the team begins handling live volume in the new platform.
Integration data flows between the support platform and CRM, billing, and product analytics tools must be validated end-to-end before cutover.
Migration Process: Zendesk to Intercom
Support operations audit
Document every active Zendesk configuration: ticket forms and fields, triggers, automations, macros, views, SLA policies, business hours schedules, satisfaction survey settings, and agent roles and permissions. Capture usage metrics for each—how often each macro is used, which triggers fire most frequently, and which views agents rely on daily. This inventory becomes the migration requirements document.
Help center content migration
Export all Zendesk Guide articles with their category and section hierarchy, metadata, images, and internal cross-links. Restructure content to fit Intercom's collection model, merging or splitting sections as needed. Import articles into Intercom, verify rendering and image display, fix internal links, and set up 301 redirects from old Zendesk URLs. Configure Intercom's help center search and verify article discoverability.
Workflow and automation rebuild
Recreate Zendesk triggers, automations, and macros in Intercom using Workflows, macros, and rules. Map Zendesk ticket fields to Intercom conversation attributes and custom data. Build routing rules that replicate Zendesk's group and assignee logic. Configure Intercom's Fin AI agent with help center content and test its resolution accuracy against common ticket types from Zendesk's historical data.
Integration reconnection
Identify every Zendesk integration (CRM sync, billing lookups, Jira issue linking, Slack notifications, analytics webhooks) and re-establish each in Intercom. For native integrations, configure and test data flow. For integrations that used Zendesk's API or webhooks, update endpoints and authentication to point to Intercom's API. Validate that bi-directional data sync works correctly for CRM and billing integrations.
Agent training and parallel run
Train agents on Intercom's inbox interface, conversation handling, macro usage, and internal note conventions. Run a parallel period where a pilot team handles live conversations in Intercom while the remaining team continues in Zendesk. Route a subset of incoming volume to Intercom through chat widget placement or email forwarding rules. Compare resolution times, satisfaction scores, and agent feedback between platforms during the parallel period.
Full cutover and monitoring
Migrate all remaining agents to Intercom, switch the primary chat widget, update email routing to Intercom's inbound address, and disable Zendesk's customer-facing channels. Monitor conversation volume, first-response times, resolution times, and CSAT scores daily for the first two weeks. Maintain read-only Zendesk access for 90 days so agents can reference historical ticket context. Run weekly retrospectives with the support team for the first month to identify and resolve workflow gaps.
How This Migration Changes at Scale
More than 100,000 historical tickets to migrate
Bulk ticket import requires API-based migration with rate limiting management. Plan for a multi-day import window and prioritize migrating tickets from the last 12 months first, with older tickets archived in a searchable external store rather than imported into Intercom.
Multi-brand Zendesk configuration with separate help centers
Intercom's workspace model handles multi-brand differently than Zendesk's brand separation. Each brand may require a separate Intercom workspace, which increases cost and complicates shared agent workflows. Evaluate whether brand separation can be achieved through Intercom's team inbox and conversation tagging instead.
Heavy reliance on Zendesk Talk for phone support
Intercom's phone capabilities are less mature than Zendesk Talk. Teams handling significant phone volume should plan for a supplementary phone solution like Aircall or Dialpad that integrates with Intercom, adding integration complexity and potentially maintaining two agent interfaces.
Related Migration Paths
Teams migrating support platforms often simultaneously evaluate their CRM. If HubSpot serves as the CRM alongside Zendesk, coordinating both migrations prevents building integrations to a platform that will itself be replaced.
Support-to-engineering escalation workflows that currently connect Zendesk to Jira will need rebuilding. If Jira is also being replaced with Linear, coordinate both migrations to build the Intercom-Linear integration once rather than creating a temporary Intercom-Jira bridge.
Custom integrations built against Zendesk's REST API may benefit from being re-architected as MCP tools, enabling AI-powered support agents to interact with backend systems through a standardized protocol rather than bespoke API calls.
Related Analysis
Zendesk vs Intercom
For support teams evaluating whether to move from ticket-based to conversation-based customer support, the architectural differences between Zendesk and Intercom shape team workflows, customer experience, and cost.
Read analysisWhen Zendesk Stops Scaling
5 warning signs that Zendesk has outgrown its limits.
Read analysisIf you're evaluating a migration from Zendesk to Intercom, the first step is validating risk, scope, and invariants before any build work begins.