Migration
Zendesk to Intercom migration service
Support teams leave Zendesk for Intercom because they want an AI-first inbox rather than a better ticket queue — Fin resolving the repetitive questions out of the Help Center, and a messenger that behaves like a conversation instead of a case file. The data move is only the visible half. Tickets, macros and Help Center articles can be carried across in a few weeks; what breaks afterwards is everything Zendesk was quietly doing around them — triggers, hourly automations, SLA policies, routing groups and the article permissions that decided who could read what. This service covers both halves: the migration itself, and the rebuild of those support automations inside Intercom, where the engine is one visual workflow builder rather than four separate features.
The mechanics
How does a Zendesk ticket become an Intercom conversation?
A ticket becomes a conversation, its comments become conversation parts, and its custom fields become attributes on either the conversation or an Intercom ticket. Nothing about that mapping is automatic. Zendesk models a case; Intercom models a thread with a person, so the state machine and the field types are redesigned before anything loads.
The order of operations is the one every platform move uses — freeze, export, map, load, reconcile, cut over — and it is set out generically on the CRM migration services page, which covers the same discipline applied to customer databases. A help desk is a different system class, and what makes this crossing its own project is that two of the three things you are moving are not data at all. The tickets are data. The macros and the Help Center are content that a new AI agent is about to read out loud to your customers, and the automation layer around them has to be rebuilt in a tool that models it completely differently.
Conversations, parts, contacts and companies are the whole vocabulary. A conversation is one thread with a person, a conversation part is a single message or note inside it, a contact is a person (a user if they are identified, a lead if they are not), and a company groups contacts the way a Zendesk organization does. Alongside them Intercom carries its own ticket object for work that is tracked rather than chatted about. That is enough to express everything Zendesk holds, but the first decision is which Zendesk tickets should arrive as conversations and which as Intercom tickets, because the two behave differently in the inbox and in reporting.
The status model is the mapping that surprises people. Zendesk runs New, Open, Pending, On-hold, Solved and Closed, plus any custom statuses layered on top, and a great deal of reporting and automation hangs off exactly which of those a ticket sits in. Intercom works with open, snoozed and closed. Pending translates reasonably to snoozed; on-hold, which usually means waiting on a third party, has no native slot and becomes either a snooze with an attribute or an Intercom ticket state of its own. That decision is made once, on paper, because every workflow, view and report built afterwards reads it.
Custom fields become attributes, and the type is a decision. A Zendesk drop-down field becomes a list attribute whose values have to exist before a single record references them. A regex-validated text field becomes plain text, because the validation lived in the form, not the data — so if that check mattered, it moves into a workflow or into the messenger form that collects it. Ticket forms, which Zendesk uses to show different field sets to different request types, map onto Intercom ticket types, and multi-brand accounts have to decide whether brands become separate workspaces, separate inboxes, or an attribute.
Matching, and the ID that turns reconciliation into arithmetic. Zendesk identifies end users by email and keeps organizations as first-class records, so the export is usually clean. Intercom deduplicates contacts on an external ID or email depending on how you write them, which means a load run twice — or a delta load that overlaps the first — can create a second contact without complaint. The defence is the same one every migration uses: a custom attribute on every contact, company and conversation holding the original Zendesk ID. Counts then reconcile by joining on a key instead of by eye, the conversation load has something stable to attach to, and any integration you keep has a foreign key to point at afterwards. The Zendesk Tickets API reference (opens in new window) and the Intercom conversation schema (opens in new window) are the two documents the field map is written against, and it is worth reading them side by side before agreeing what a promise to move everything is going to mean.
The export itself is a step, not a formality. Zendesk gates full account exports behind an account-owner request, as its own data export documentation (opens in new window) sets out, and a CSV export deliberately leaves out ticket comments — the very thing that makes a historical ticket worth having. So the content comes through the API or a JSON export, the attachments are pulled separately because they live behind Zendesk-hosted URLs that stop resolving when the contract does, and the request is raised early enough that nobody discovers the lead time in cutover week.
| Zendesk artefact | How Zendesk models it | Where it lands in Intercom | The decision it forces |
|---|---|---|---|
| Tickets | A case record with a requester, an assignee, a status and a full event history | A conversation, or an Intercom ticket where the work is tracked rather than chatted about | Which request types are conversations and which are tickets, since the two report differently |
| Ticket comments | Public replies and internal notes on one thread, each with an author and timestamp | Conversation parts, written in order through the API | How far back to load, and whether original timestamps are preserved or the whole thread lands on import day |
| Ticket status | New, Open, Pending, On-hold, Solved, Closed, plus custom statuses | Open, snoozed and closed, or an Intercom ticket state | Where on-hold goes, since waiting on a third party is not the same as being snoozed |
| Custom ticket fields | Text, drop-down, multi-select, checkbox, date, number and regex-validated fields | Conversation or ticket custom attributes, typed | Which drop-downs become list attributes with a fixed value set, and where the lost regex validation is re-enforced |
| Ticket forms | Different field sets shown per request type, often per brand | Ticket types, each with its own attributes | How many types the team will actually maintain, and what multi-brand becomes |
| Tags | Free-text labels applied by agents, triggers and macros alike | Tags, or typed attributes where the tag was really a field | Which tags carry logic and must survive, and which are years of accumulated typos |
| End users | Records keyed on email, with identity verification optional | Contacts — users when identified, leads when not | Which external ID is authoritative, since it is what stops a second load creating a second person |
| Organizations | A first-class record grouping users, driving views and SLA policies | Companies, with contacts associated to them | Whether organization-level fields become company attributes or move to the CRM instead |
| Groups and agents | Groups route tickets; agents hold roles, including light agents | Teams and teammates, with inbox access per team | What happens to light agents, who read and comment without a full seat |
| Views | Saved filters over the ticket set, shared or personal | Inbox views built on the new attributes | Which views anyone opens daily, since a view built on a field that no longer exists is silently empty |
| Macros | Canned text plus field updates applied in one click | Macros and saved replies, with the field updates handled alongside | Which macros were really automations wearing a button, and belong in a workflow |
| Triggers | Event-based rules evaluated whenever a ticket is created or updated | Workflows started by a conversation event | Which rules are still wanted, since trigger lists accumulate for years and nobody deletes |
| Automations | Time-based rules that sweep hourly against conditions such as hours since update | The same workflow builder, using waits and conditions | How a wait behaves when the customer replies mid-wait, which is not how an hourly sweep behaved |
| SLA policies and business hours | Targets per priority against a schedule, with breach events driving triggers | SLAs and office hours, with breach handled in workflows | Which targets are real commitments to a customer and which were internal ambition |
| Guide categories, sections and articles | A three-level help centre with per-article labels and HTML bodies | Help Center collections, sections and articles created through the Articles API | Which articles are worth carrying at all, because Fin will answer from every one you keep |
| Article user segments | Visibility restricted to signed-in users or named segments | Help Center audience rules, which are coarser | What happens to content that was restricted for a reason, and whether it belongs in the public centre at all |
| Guide theme and help centre domain | A templated theme on your own subdomain, indexed by search engines | An Intercom-hosted Help Center on a custom domain, styled within its limits | The redirect map, since every existing article URL is a link somebody else already published |
| Answer Bot and Zendesk AI agents | Article suggestions and bot flows configured against Guide content | Fin, answering from the Help Center and other connected sources | What Fin is allowed to answer unaided, and exactly when it hands to a person |
| Satisfaction ratings | A native CSAT record attached to the solved ticket | Attributes on the imported conversation, not native ratings | Whether historical scores are loaded for reference or archived as a report and left behind |
| Side conversations | Parallel email threads with vendors or internal teams, attached to a ticket | No direct equivalent — internal notes, a linked conversation, or an external tool | Whether the workflow that relied on them survives the move in a different shape |
| Web Widget and support addresses | An embed on your site plus forwarding from support@ into Zendesk | The Intercom Messenger and its own forwarding and sending domain setup | Cutover timing, because two systems both receiving support@ for an afternoon is a real risk |
| Explore reports | A query layer over the full ticket event history | Intercom reporting over data it has witnessed since import | Which reports are exported and archived, since history that predates the load cannot be recomputed |
An AI agent answering customers is a disclosure decision, not just a configuration one. Fin will be the first thing many of your customers meet, and it will answer in your voice from your articles. Every deployment we build says plainly that it is an assistant, says so again when a person takes over, and is tested against real past tickets before it is allowed near a live inbox. The Federal Trade Commission's business guidance (opens in new window) is direct about deceptive AI claims and impersonation, and beyond compliance it is simply how a support team keeps the trust it spent years earning. A bot that hides what it is loses that the moment it is caught.
Sequence
What changes in the plan when the destination is Intercom?
The order holds — freeze, export, map, load, reconcile, cut over. What moves is where the judgement goes. Here it goes into the state model, into the Help Center rewrite that Fin will read from, and into consolidating four Zendesk automation features into one workflow builder without losing a rule nobody documented.
Audit the automation layer before the export
Every trigger, automation, macro and SLA policy on one page, each marked keep, simplify or retire. Accounts that have run for years carry rules whose author has left, and a rebuild that copies them all reproduces the mess in a nicer builder.
Load records first, then attach the threads
Contacts and companies land first with the Zendesk ID on an attribute. Conversations attach in a second pass, in order, keyed on that ID. Threads are the part a spreadsheet import cannot carry, so they are never left to one.
Fix the articles before you point Fin at them
Fin answers from the Help Center, so a thin or contradictory article becomes a thin or contradictory answer at scale. The article set is pruned, rewritten and gap-filled from real ticket history before the AI agent is turned on for anyone.
Four Zendesk features become one workflow builder
There is no converter between the two engines, and each rule is read and rebuilt by hand. The structural difference is consolidation. Zendesk splits its logic four ways: triggers fire the moment a ticket is created or updated, automations sweep hourly and act on elapsed time, SLA policies track targets against a schedule, and macros let an agent apply a block of changes by hand. Intercom puts almost all of that in one visual builder where a workflow starts on an event, waits, branches on conditions and takes actions in sequence. Most accounts simplify sharply in the move — three triggers chained together to fake a delay become one workflow with a wait in it. Two things need care. A wait is not an hourly sweep, so a rule that assumed a customer reply would interrupt it has to say so explicitly. And a macro that quietly set four fields was doing automation work behind a button; those are the ones that belong in a workflow, not in a saved reply.
The Help Center stops being documentation and becomes training material
In Zendesk, Guide articles were read by people who had already decided to search. In Intercom, the same articles are the source Fin answers from, which changes what good enough means. An article that assumes the reader can see the screen, or that covers three scenarios in one page without saying which is which, produces a confident and wrong answer rather than a mildly unhelpful search result. So the library is pruned before it is migrated — duplicates merged, dead product references removed, anything that only made sense inside the old UI rewritten. Then the gaps get filled, and the best source for those is the ticket history you are already exporting: the questions that generated the most tickets and had no article behind them are the articles to write first. Articles are created through the Intercom Articles API (opens in new window), which takes HTML or markdown, so the rewrite is scripted rather than pasted — and each article is checked afterwards, because the editor normalises what it is given and tables, embeds and inline images do not all survive a paste intact.
The redirect map is the part support teams forget
A Zendesk help centre sits on a subdomain, gets indexed, and accumulates links from your own product, your emails, your macros and other people's blog posts. Move it and every one of those URLs breaks unless a redirect catches it. So the article inventory is exported with its old URLs before anything is switched off, each old URL is mapped to its new Intercom address, and the redirects are in place on the day the domain moves — not in the following sprint, by which point search engines have already dropped the pages and the support inbox is collecting messages asking where the documentation went. Where two old articles merged into one new one, both old URLs point at the survivor. Where an article was deliberately retired, the redirect goes to the nearest useful page rather than the Help Center home, which search engines treat as a soft 404.
Cutover, reconciliation and disposing of the export
Cutover runs one channel at a time. Contact and company counts are compared in both directions on the stored Zendesk ID, conversation counts are compared against the ticket export, the article inventory is checked page by page against the redirect map, and a delta load picks up whatever arrived during the freeze. Email forwarding switches last and switches once, because two help desks both receiving support@ for an afternoon produces duplicate threads that nobody can reconcile afterwards. The Zendesk account stays live and read-only for a lookback period, because the per-field event history and the Explore reporting do not migrate and are still worth being able to open — and because every widget embed, integration and API token still pointing at it has to be found and replaced before it can be switched off. One step is easy to skip: the export is a complete copy of your customers' support history, including whatever they told an agent in confidence, sitting in a folder on somebody's laptop and probably in a shared drive as well. Destroying those working files at the end of the project — deliberately, everywhere they were copied, along the lines of NIST's media sanitization guidelines (opens in new window) — is part of the work, not an afterthought. So is token ownership: the load and any integration you keep run on API credentials that should belong to the business, not to whoever happened to run the migration.
Where this sits next to the rest of the work
This page is about one crossing and the rebuild on the far side. The general capability — triage, drafted replies, grounded answers, honest escalation — is the subject of our AI customer support automation page, which is the right read if the platform is not the problem and the queue is. If the customer database is moving in the same quarter, that is a separate project with separate objects, and the CRM migration services hub covers the pairs we handle. Where the tickets come from a subscription product and severity depends on the plan and usage behind them, AI automation for SaaS companies covers routing on account context, which is exactly the attribute work this migration should set up rather than postpone. Where the volume is order status, returns and delivery chasing, AI automation for ecommerce covers the patterns that suit a messenger better than a ticket form ever did. And before committing to any of it, our note on the most common AI automation mistakes is worth ten minutes — the first one on the list, automating a broken process instead of fixing it, is exactly what a platform migration tempts a team into doing at scale. How a scope gets agreed before any of this starts is set out under how engagements work.
The honest part
Why move from Zendesk to Intercom at all?
Usually because the roadmap is AI-first support and the team wants resolution by an AI agent grounded in its own documentation, on a messenger rather than a case queue. The trade is real: you give up a deep, highly configurable ticketing system for a lighter conversational one. Whether that suits you is what the first call decides.
| What | Treatment | Why |
|---|---|---|
| Contacts and organizations | Moves | They load cleanly once the attributes exist with the right types and an authoritative external ID has been chosen |
| Ticket threads and their replies | Moves, in a second pass | Conversations attach to contacts that already exist, in order, with original timestamps written rather than inherited |
| Ticket attachments and inline images | Moves deliberately | They live behind Zendesk-hosted URLs that stop resolving at contract end, so they are pulled and re-uploaded or knowingly dropped |
| Custom field values | Moves | Once each attribute and every list value exists first, values land — in that order, or the load rejects the rows |
| Help Center articles | Moves, after a rewrite | Recreated through the Articles API, but pruned and edited first because Fin will answer from whatever you keep |
| Ticket status | Rebuilt as a state model | Six statuses plus custom ones map onto open, snoozed and closed, so on-hold and any custom state are re-expressed on purpose |
| Triggers, automations and SLA policies | Rebuilt as workflows | A different execution model — waits instead of hourly sweeps — so each rule is re-expressed, re-tested and often merged with two others |
| Macros | Rebuilt, and sorted | The text becomes a saved reply; the field updates hiding inside it become workflow actions, which is where they always belonged |
| Views and routing | Rebuilt on the new attributes | A view or assignment rule built on a Zendesk field that no longer exists does not error — it just quietly returns nothing |
| Answer Bot flows | Rebuilt as Fin plus workflows | Fin is grounded in content rather than scripted in branches, so the configuration work is about sources, scope and handover |
| Help centre URLs | Redirected | Every indexed article and every link anyone ever shared points at the old domain, and a missing redirect is an invisible loss |
| Per-field ticket event history | Stays behind | Zendesk records who changed what and when on every ticket; Intercom knows the thread it was given and what has happened since |
| Explore reports and historical metrics | Stays behind | Resolution times and volumes computed over the old event trail cannot be recomputed, so the reports worth keeping are exported and archived |
| Side conversations and light agents | Stays behind, re-expressed | Neither has a native equivalent, so the working practice around them is redesigned rather than migrated |
| Widget embeds, integrations and API tokens | Replaced | Anything still calling Zendesk keeps creating tickets there after cutover, and nobody notices for weeks |
You own the result outright: an Intercom workspace on your own account and your own tokens, workflows documented against the event that starts them and the rule they replaced, an attribute map showing where every Zendesk field went, a redirect map for every article URL, a written note of where each function that left the help desk now lives, and an equally written note of what was left behind on purpose. If your own team would rather run the load, we will design the attribute model, build the field map and the conversation pass, and stay on as backup. And if the honest answer on the call is that Zendesk still suits you better — that the depth of its ticketing is doing real work for you and the AI you want could be added where you already are — that is what you will hear.
Questions
What support teams ask before committing to the move
Do Zendesk tickets keep their history when they become Intercom conversations?
The thread does, if it is loaded deliberately. Each public reply and internal note becomes a conversation part in the right order, with the original timestamps written through the API rather than inherited from the day of the import. What does not carry is the per-field audit trail Zendesk keeps behind every ticket event, and satisfaction ratings, which land as attributes on the conversation rather than as native records.
Do Zendesk triggers and automations convert into Intercom workflows?
No, they are rebuilt. Zendesk spreads the logic across triggers that fire on a ticket event, automations that sweep hourly against time conditions, SLA policies and macros. Intercom puts nearly all of it in one visual workflow builder with waits and branches, so most rules simplify. The risk is the undocumented trigger nobody remembers, which is why the trigger list is read line by line before anything is built.
What happens to Zendesk Guide articles and their URLs?
Categories and sections become collections and sections, and each article is recreated through the Articles API. Two things need explicit handling. Article HTML is normalised by Intercom's editor, so tables, embeds and inline images are checked rather than assumed. And every old Help Center URL needs a redirect, because search engines and every link anyone ever shared still point at the Zendesk domain.
Can Fin answer well from content that came out of Zendesk?
Only as well as that content reads. Fin, Intercom's AI agent, answers from the Help Center articles and other sources you point it at, so a library written for a search box and a patient human reader produces vague, hedged answers. The step worth doing before Fin is switched on is mining the Zendesk ticket history for the questions the articles never actually answered.
What has no equivalent on the Intercom side?
Side conversations, light agents, template-level Guide theming and the depth of Explore reporting are the usual four. The on-hold status and multi-brand ticket forms also need re-expressing rather than copying. None of them is fatal on its own, but each is a decision, and each is far cheaper to make on paper than in the week after the Zendesk contract lapses.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Moving the customer database in the same quarter? See the CRM migration services overview.