Intercom → Zendesk
Move customers, contacts, and organizations, tickets and conversations, public replies and private notes, attachments and inline media, agents, teams, roles, and permissions, custom fields, forms, tags, and statuses, macros, triggers, routing, and slas, help center articles and categories from Intercom to Zendesk with a reversible cutover, explicit exception ledger, and evidence-backed verification.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Intercom
- Messenger, inbox, automation, help center, and customer context create a strong conversational support experience
- Tickets, customer context, knowledge, automation, and service reporting share one operating system
- Seat and usage pricing, proprietary conversations, and automation complexity raise switching costs
- Conversation visibility, routing logic, SLAs, and reporting history are hard to reproduce exactly
Zendesk
- Mature ticketing, omnichannel support, help centers, routing, SLAs, and ecosystem depth serve complex teams
- Tickets, customer context, knowledge, automation, and service reporting share one operating system
- Customization, administration, licensing, and source-specific ticket semantics make migrations demanding
- Conversation visibility, routing logic, SLAs, and reporting history are hard to reproduce exactly
Zendesk: Mature ticketing, omnichannel support, help centers, routing, SLAs, and ecosystem depth serve complex teams. This removes a major source-side concern: Seat and usage pricing, proprietary conversations, and automation complexity raise switching costs.
What you lose: Messenger, inbox, automation, help center, and customer context create a strong conversational support experience. What you inherit: Customization, administration, licensing, and source-specific ticket semantics make migrations demanding.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to 500 agents, one million tickets, 250 automations, and 500 GB of attachments
- Administrators control both Intercom and Zendesk, including billing, identity, APIs, integrations, and export permissions.
- Intercom remains intact and recoverable until Zendesk completes one representative operating cycle.
- A production-shaped pilot includes every object type, access class, edge case, and failure path.
- The migration team preserves stable source identifiers and records durable evidence for every blocking check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Customers, contacts, and organizations | partial | critical | Identity keys, merged profiles, organization membership, custom attributes, and consent do not share one model. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Map customers, contacts, and organizations explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Tickets and conversations | partial | critical | Ticket states, conversation parts, channel semantics, requester identity, and threading require transformation. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Map tickets and conversations explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Public replies and private notes | partial | critical | Comment visibility and author attribution can flatten or expose internal material. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Map public replies and private notes explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Attachments and inline media | partial | high | Exports can preserve attachment metadata while binaries, inline images, or authenticated URLs remain behind. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Map attachments and inline media explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Agents, teams, roles, and permissions | manual | critical | Agent accounts, restricted groups, custom roles, and licensing must be provisioned deliberately. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Inventory and rebuild agents, teams, roles, and permissions, then test normal, edge, failure, and rollback behavior. |
| Custom fields, forms, tags, and statuses | partial | high | Field types, option values, required rules, lifecycle states, and tag behavior differ. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Map custom fields, forms, tags, and statuses explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Macros, triggers, routing, and SLAs | manual | critical | Automation syntax, business hours, escalation clocks, assignment rules, and SLA calculations are runtime configuration. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Inventory and rebuild macros, triggers, routing, and slas, then test normal, edge, failure, and rollback behavior. |
| Help center articles and categories | partial | high | Knowledge hierarchy, locales, URLs, votes, and author metadata have separate import constraints. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Map help center articles and categories explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items. |
| Reports, CSAT, and SLA history | lost | high | Imported records do not recreate destination-native metrics, historical SLA calculations, or reporting baselines. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Archive reports, csat, and sla history as dated source evidence and define the new destination baseline. |
| Email channels, apps, bots, and webhooks | manual | critical | Inbound addresses, sender authentication, marketplace apps, bots, API clients, and callbacks remain source-bound. A successful bulk job therefore does not prove semantic parity between Intercom and Zendesk. | Inventory and rebuild email channels, apps, bots, and webhooks, then test normal, edge, failure, and rollback behavior. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Intercom: Customers, contacts, and organizations | Zendesk: approved customers, contacts, and organizations representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for customers, contacts, and organizations. |
| Intercom: Tickets and conversations | Zendesk: approved tickets and conversations representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for tickets and conversations. |
| Intercom: Public replies and private notes | Zendesk: approved public replies and private notes representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for public replies and private notes. |
| Intercom: Attachments and inline media | Zendesk: approved attachments and inline media representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for attachments and inline media. |
| Intercom: Agents, teams, roles, and permissions | Zendesk: approved agents, teams, roles, and permissions representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for agents, teams, roles, and permissions. |
| Intercom: Custom fields, forms, tags, and statuses | Zendesk: approved custom fields, forms, tags, and statuses representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for custom fields, forms, tags, and statuses. |
| Intercom: Macros, triggers, routing, and SLAs | Zendesk: approved macros, triggers, routing, and slas representation | manual | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for macros, triggers, routing, and slas. |
| Intercom: Help center articles and categories | Zendesk: approved help center articles and categories representation | transform | Preserve source IDs, ownership, timestamps, access intent, and an explicit exception status for help center articles and categories. |
| Intercom: Reports, CSAT, and SLA history | No destination | unsupported | Retain immutable source evidence; do not manufacture destination-native history. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Intercom data, configuration, access, and operating evidence before any destination write.
- Export every available Intercom object and binary in scope, including customers, contacts, and organizations, tickets and conversations, public replies and private notes, attachments and inline media.
- Capture configuration and runtime dependencies for agents, teams, roles, and permissions, custom fields, forms, tags, and statuses, macros, triggers, routing, and slas, help center articles and categories.
- Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
- Hash immutable exports, record tool versions and commands, and transform working copies only.
Proof to capture: A signed manifest accounts for every scoped record class, configuration object, binary, count, total, exception, and hash.
Identity, schema, and disposition registry
Preserve stable identity and make every mapping or exclusion reviewable.
- Inventory source types, identifiers, owners, states, and access.
- Define one approved destination representation or explicit archive decision.
- Reject unmapped critical items and produce an exception ledger.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Dependency-ordered migration package
Load prerequisite identities and configuration before dependent records and runtime actions.
- Normalize encoding, timestamps, identifiers, nulls, and destination limits.
- Run a representative pilot and retain request, response, and rejection evidence.
- Reconcile the final delta before enabling destination production writers.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
A completed migration hides missing or altered customers, contacts, and organizations
Headline counts look plausible while semantic, access, or relationship checks fail.
- Consequence
- The destination becomes authoritative with incomplete or misleading business data.
- Mitigation
- Reconcile by type, state, owner, access class, and representative record rather than total count alone.
Stop if: Any critical item lacks a verified destination, approved transformation, explicit exclusion, or recoverable archive.
Intercom and Zendesk both perform production actions
Users, schedules, webhooks, integrations, or traffic continue changing both systems.
- Consequence
- State diverges or customers receive duplicate, contradictory, or unsafe actions.
- Mitigation
- Freeze source writers and transfer one production owner at a time with an approved rollback.
Stop if: An unapproved source writer or destination duplicate action appears after the freeze.
Destination access or security is broader than approved
A representative restricted user can read, change, export, or trigger an unauthorized item.
- Consequence
- Confidential, regulated, financial, or security-sensitive data is exposed or changed.
- Mitigation
- Apply least privilege before bulk loading and test every access class using ordinary identities.
Stop if: Any unauthorized read, write, export, administrative action, or secret access succeeds.
Do the work in this order.
- Days 1–4 · inventory
Inventory and decisions
8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting- Inventory Intercom data, configuration, identities, integrations, limits, and billing.
- Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.
Depends on: Intercom and Zendesk administrator access
Stop / go checkpointExport?
Go when: Every critical item and production action has an owner and disposition.
Stop when: Authority, retention, billing, access, or system ownership is unclear.
- Days 3–8 · backup
Backup and reconcile
8–20 hours active2–5 days elapsedProvider export processing waiting- Create immutable data, configuration, binary, and audit exports.
- Reconcile source counts, totals, sizes, access classes, and hashes.
Depends on: Approved inventory and retention location
Stop / go checkpointTransform?
Go when: The signed source manifest and exports agree.
Stop when: Any critical dataset, binary, configuration, or recovery path is absent.
- Days 6–20 · pilot
Map, transform, and pilot
25–70 hours active5–12 days elapsedDestination processing and owner review waiting- Configure Zendesk and transform a production-shaped pilot.
- Test normal records, every feature class, edge cases, permissions, failures, and rollback.
Depends on: Verified source backup and approved mapping registry
Stop / go checkpointScale?
Go when: Every pilot mapping and blocking verification check passes.
Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.
- Days 18–35 · cutover
Bulk load, final delta, and switch
20–55 hours active2–8 days elapsedImports, propagation, indexing, or synchronization waiting- Freeze production writes and automated actions in Intercom.
- Apply and reconcile the final delta, switch ownership to Zendesk, and run all blocking checks.
Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback
Stop / go checkpointOpen production?
Go when: Zendesk is the sole production owner and every critical exception is resolved.
Stop when: A source writer remains active, a blocking check fails, or rollback is unavailable.
- Days 25–45 · observe
Observe and close
9–19 hours active7–14 days elapsedRepresentative operating-cycle evidence waiting- Monitor correctness, access, failures, latency, delivery, cost, and user outcomes.
- Sign the verification report and close rollback only after stable evidence.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the approved observation period.
Stop when: Data, access, delivery, routing, cost, or business results regress.
Cut over with a way back.
Cutover
Make Zendesk the only production system without losing the final Intercom delta.
- Freeze user, integration, schedule, and API writes in Intercom.
- Capture and reconcile the final source delta against the last verified checkpoint.
- Apply the approved delta and configuration changes to Zendesk.
- Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
- Run every blocking verification check and keep the source intact.
Proof to capture: Zendesk alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.
Rollback
Return production ownership to Intercom without losing destination-era changes.
- Stop new user, integration, schedule, and API writes in Zendesk.
- Restore prior Intercom traffic, domains, credentials, automation, and integration ownership.
- Export and classify the Zendesk post-cutover delta.
- Apply safe destination-era changes back to Intercom without duplicating actions.
- Run the same blocking checks against the restored source.
Proof to capture: Intercom again owns production with current data and no duplicate destination action.
- Unexplained critical count, value, relationship, or checksum variance
- Missing, corrupted, or exposed critical data
- Duplicate production action or unresolved split-brain state
- Failed access, security, delivery, routing, performance, or integration check
- A critical feature has no safe destination replacement or rollback path
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Customers, contacts, and organizations reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for customers, contacts, and organizations. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Customers, contacts, and organizations ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-02Blocking | Tickets and conversations reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for tickets and conversations. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Tickets and conversations ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-03Blocking | Public replies and private notes reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for public replies and private notes. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Public replies and private notes ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-04Blocking | Attachments and inline media reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for attachments and inline media. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Attachments and inline media ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-05Blocking | Agents, teams, roles, and permissions reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for agents, teams, roles, and permissions. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Agents, teams, roles, and permissions ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-06 | Custom fields, forms, tags, and statuses reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for custom fields, forms, tags, and statuses. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Custom fields, forms, tags, and statuses ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-07Blocking | Macros, triggers, routing, and SLAs reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for macros, triggers, routing, and slas. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Macros, triggers, routing, and SLAs ledger with counts, exceptions, sample IDs, and owner sign-off. | |
V-08 | Help center articles and categories reconciliation | Compare source inventory, transformed output, destination results, and a stratified sample for help center articles and categories. | Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive. | Help center articles and categories ledger with counts, exceptions, sample IDs, and owner sign-off. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check and exception.
- Create final Intercom exports and archive verification, access, financial, and rollback evidence.
- Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
- Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
- Keep the source intact and read-only through the approved legal and operational retention window.
- Cancel paid plans only after billing, legal, security, evidence, and recovery review.
- Schedule the next Zendesk backup, restore test, access review, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
A customer success operations manager describes using Help Desk Migration to move Intercom history into Zendesk. The testimonial emphasizes combining the migration tool with responsive human support rather than treating the transfer as an unattended export. It is a vendor-published account, but it directly records a completed source-to-destination move and the operational support the customer considered important.
- Run a representative test migration and review conversation threading, users, attachments, and custom fields before the full transfer.
- Keep a named support contact available during the production migration so mapping or access problems can be resolved quickly.
- The customer attributed the successful move to both automation and timely assistance from the migration team.
- A migration utility does not remove the need for human review when two help desks model conversations differently.
A company support lead reports a recent Intercom-to-Zendesk migration and identifies a concrete post-cutover gap: Intercom's configurable snooze control had no equivalent in their Zendesk workflow. Without it, deferred tickets accumulated in the open queue and required repeated manual review. The short field report is valuable because it documents a daily operational regression that a data-transfer test would not reveal.
- Test defer, snooze, and follow-up workflows with working agents before deciding that feature parity is sufficient.
- Define a Zendesk view or automation for deferred work before cutover if the team relies heavily on Intercom snoozing.
- Conversation history can migrate successfully while a small workflow difference still creates sustained queue-management overhead.
- Agent-level acceptance testing is necessary because administrators may not notice missing controls used throughout the support day.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- Intercom: official portability and migration documentationAccessed 2026-07-20
- Zendesk: official portability and migration documentationAccessed 2026-07-20