How to Migrate from Intercom to Zendesk
Intercom conversations become Zendesk tickets easily enough. What does not transfer is the Messenger — the in-product chat, tours and outbound messaging that were half of what you were paying for.
- Difficulty
- Complex
- Typical duration
- 4–8 weeks
- Downtime
- None — run both in parallel, then switch routing
- Native importer
- Partial — Zendesk API, or a third-party migration tool
| Intercom | maps to | Zendesk | What to watch |
|---|---|---|---|
| Conversation | Ticket | Direct in substance. Intercom conversations are often long and informal; expect Zendesk tickets that read differently from ones raised by email. | |
| Contact (user) | End user | Clean on email. Intercom leads without an email address have no useful Zendesk destination. | |
| Company | Organization | Direct, and Zendesk organizations can drive routing and SLA policies that Intercom handled through attributes. | |
| Team / Inbox | Group / View | Intercom's inbox assignment model splits into Zendesk groups plus views. Design the view structure deliberately — it is how agents will work. | |
| Workflow | Trigger / Automation | Intercom's visual workflows rebuild as Zendesk triggers and automations. More granular, less visual — expect redesign. | |
| Help Center article | Guide article | Separate import. Structure maps well; plan URL redirects. | |
| Macro / Saved reply | Macro | Text maps directly. Macros that set attributes need rebuilding with Zendesk field actions. | |
| Messenger, tours, outbound | — (no single equivalent) | The real gap. Zendesk has chat and messaging, but Intercom's in-product engagement suite is a different product category. |
What transfers cleanly
- Conversations as tickets with their full thread history.
- Contacts and companies with custom attributes, once matching Zendesk fields exist.
- Attachments on conversations.
- Tags, which map into Zendesk's tagging model.
- Agent assignment, where Intercom seats have Zendesk seats with matching emails.
What doesn't come across
- The Intercom Messenger. In-product chat, product tours, checklists and outbound campaigns are not a helpdesk feature. Zendesk covers part of this; the rest needs a separate product engagement tool.
- Fin AI resolution history. Resolution records and AI performance data stay in Intercom.
- Intercom Series and outbound campaigns. No Zendesk equivalent — these move to a marketing or product-engagement tool.
- Intercom custom objects. Zendesk's equivalent is different; data needs remapping rather than moving.
- Reporting continuity. Intercom reports on messaging and resolution; Zendesk Explore reports on tickets and queues. Historical trends will not line up.
- Leads without email addresses. These have no meaningful Zendesk destination.
Migration order that works
- List everything the Intercom Messenger does for you beyond support — tours, checklists, outbound, banners — and name a replacement for each.
- Decide which Intercom contacts are real users and which are leads; leads without emails generally should not migrate.
- Design the Zendesk group and view structure before importing. This is how agents will find work and it is the biggest day-one adoption factor.
- Create organizations, end users, custom fields and SLA policies in Zendesk first.
- Import companies, then end users, then conversations as tickets with their thread history.
- Import Help Center articles into Guide with a redirect map from the old URLs.
- Rebuild workflows as triggers and automations, run in parallel, then switch routing after agent training.
Teams leave Intercom for Zendesk for two recurring reasons: the per-resolution pricing stopped making sense at their volume and ticket mix, or they need the structured routing, SLA management and reporting that a mature ticketing system provides and a messaging platform does not.
Both are legitimate. Both also mean giving up something Intercom does that Zendesk simply does not.
The Messenger is the hidden scope
Intercom's in-product Messenger is not just a support widget. It runs product tours, onboarding checklists, in-app banners, proactive outbound campaigns and NPS surveys. In many companies, product and marketing depend on it as much as support does.
Zendesk covers the support conversation part. It does not cover the rest.
Before anyone signs anything, ask product and marketing what they use the Messenger for. The answer routinely uncovers workflows nobody in the support team knew existed, and the replacement — a dedicated product-engagement tool — is a real line item that belongs in the business case rather than surfacing in week six.
Design the view structure before you import
This is the single biggest determinant of whether agents adopt Zendesk happily.
Intercom agents work from an inbox: assigned conversations, unassigned, mentions. Zendesk agents work from views — saved queries defining queues by priority, group, status, age.
Get this right and Zendesk feels like an upgrade in control. Get it wrong and agents spend their first week unable to find their work, which is where migration resentment comes from.
Design the views with the agents who will use them, before the import, not after.
Historical reporting will not reconcile
Intercom measures conversations, response times and AI resolutions. Zendesk Explore measures tickets, queues and SLA attainment.
These are genuinely different frames, and any attempt to show a continuous trend line across the migration will be misleading. Export the Intercom figures you need for the record, then treat the Zendesk baseline as a fresh start and say so explicitly to whoever reads the reports.
Decide what to do with leads
Intercom captures a lot of anonymous and semi-identified visitors as leads. Zendesk has no useful place for a contact with no email address.
Filter these out during export rather than importing them into an end-user database where they will never be actionable.
Switch routing last
Import the history, rebuild the triggers, train the agents, then repoint email and messaging. The change that affects customers should be the final step, not the first.