Intercom and Zendesk
Most teams asking about Intercom and Zendesk are in one of two situations: halfway through a migration, or running both and calling it temporary. The second is where the damage happens.
How companies end up running Intercom and Zendesk
Almost always the same story. Intercom arrives with product or growth, because it does in-app messaging, onboarding tours and proactive nudges. Zendesk arrives with support, because it does email properly, has real SLA machinery and a help centre that ranks.
For a year that's fine, because the two audiences barely overlap. Then a customer replies to an in-app message about something they already have an email ticket open for, and suddenly two agents in two tools are answering the same person without knowing the other exists.
There's a decision hiding in there, and postponing it costs more than making it badly.
If you are running both, split by surface
What moves in a migration, and what does not
Migration tooling for this route is mature, so the mechanics are rarely the problem. The fidelity is.
Moves reasonably well
Conversations as tickets, contacts as end users, companies as organisations, tags, help centre articles, and saved replies into something approximating macros. Enough that the historical record exists and is searchable, which is the point of moving it at all.
Degrades
Conversation structure usually flattens. A threaded Intercom conversation often arrives as one large comment, or as comments attributed to the API user rather than the agent who wrote them. Timestamps survive; authorship frequently does not.
Does not come across
Reporting history, in any usable form. First response and resolution times calculated under one tool's rules don't mean the same thing under another's, so keep the old instance read-only for a quarter and stop pretending the trend line is continuous.
Automations, too. Intercom workflows and bot flows have no equivalent shape in Zendesk triggers and automations. You rebuild them. Budget for it properly, because this is the task that takes three weeks longer than anyone said.
And article URLs. Redirect them or lose the search positions you spent two years earning. Nobody remembers this until traffic drops.
The double-running period breeds duplicates
This is the part that catches teams out, and it's worth being specific about.
While both systems are live, a customer emails support and also messages the widget. Two records, two tools, neither aware of the other, and often two agents replying with slightly different answers within the hour. The customer concludes you're disorganised, which is fair.
Then the import happens. Intercom conversations land in Zendesk as tickets, and some of those people already have live email tickets in Zendesk about the same thing. Same person, same problem, one imported record and one live one, no link between them. On top of that the import creates end users from Intercom emails, and a proportion of those people had already written to you from a different alias, so you get duplicate users as well as duplicate tickets.
Three things reduce it. Freeze new conversations in the old system before the import runs, not during. Import into a dedicated group or with a distinguishing tag so the imported records are findable. And run user deduplication after the import rather than before, because before is when the duplicates don't exist yet.
A cutover that doesn't hurt
Move email first, or move the widget first, but pick one and finish it before starting the other. Overlapping cutovers on both channels at once is how you end up with the double-running problem permanently.
Tell agents everything and customers nothing. Customers don't care which helpdesk you use, and announcing it invites questions you gain nothing by answering.
Export your raw data yourself before the migration tool touches anything, and keep the old instance read-only for a year rather than cancelling it the week the invoice lands. The first time legal asks for a conversation from eighteen months ago, that decision pays for itself.
If you're still deciding rather than migrating, the Zendesk vs Intercom comparison is the better starting point.
Frequently asked questions
What does an Intercom to Zendesk migration involve?
Conversations and contacts move with a migration service; macros, automations and reports get rebuilt. Any Intercom vs Zendesk migration plan should budget for the parallel weeks, and a Zendesk Intercom integration is only worth building if both are staying.
Can Intercom and Zendesk be integrated properly?
There are connectors that push conversations one way and sync contacts, but nothing that keeps two live inboxes genuinely in step. Treat running both as a temporary state with a deadline.
Do Intercom conversations import into Zendesk as tickets?
Yes, through migration tooling, though threaded conversations usually flatten and authorship often ends up attributed to the API user rather than the original agent.
What breaks most often in a migration?
Reporting history and automations. Neither survives, and the automation rebuild is consistently underestimated.
Which system should own the email address?
Whichever one you're keeping. Two systems on one support address produces two autoresponders and two ticket numbers for a single message.
Do we lose satisfaction history?
As structured, reportable data, generally yes. Scores may import as text or tags, but the survey model differs enough that historical CSAT comparisons stop being meaningful.
Two tools, one customer, two tickets
Duplicates peak during a migration and never fully go away afterwards. Ticket Merger matches on requester and time window, which is exactly the pair a double-running period produces.
Start free trial14-day free trial. No credit card required.