migrating toBrowse playbooks
← All playbooks
Customer support migration

Zendesk → Intercom

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 Zendesk to Intercom with a reversible cutover, explicit exception ledger, and evidence-backed verification.

Typical timeline15–45 business days70–180 hours active work
Statusneeds review
Source profileZendesk documentation reviewed 2026-07-20
Destination profileIntercom documentation reviewed 2026-07-20
Documentation date
Review window
Evidence2 sources
This route needs review.Use it as a planning baseline, then verify the dated sources and test with representative data before production.
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Zendesk

Reasons to stay
  • 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
Reasons to leave
  • Customization, administration, licensing, and source-specific ticket semantics make migrations demanding
  • Conversation visibility, routing logic, SLAs, and reporting history are hard to reproduce exactly
New platform

Intercom

What gets better
  • 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
What gets worse
  • 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
Best of the move

Intercom: Messenger, inbox, automation, help center, and customer context create a strong conversational support experience. This removes a major source-side concern: Customization, administration, licensing, and source-specific ticket semantics make migrations demanding.

Worst of the move

What you lose: Mature ticketing, omnichannel support, help centers, routing, SLAs, and ecosystem depth serve complex teams. What you inherit: Seat and usage pricing, proprietary conversations, and automation complexity raise switching costs.

Connected catalog

2 destinations are documented from Zendesk. Compare nearby routes before committing.

Also from Zendesk
Also moving to Intercom
Jump to a section
01At a glance

Know the shape of the move.

Transfer outcome10 features audited
Transfer outcome distributionClean transfer: 0, Partial transfer: 6, Manual rebuild: 3, Not transferred: 1.
Clean0
Partial6
Manual3
Lost1
Mapping route8 of 9 fields have a destination path

This timeline assumes

  • Up to 500 agents, one million tickets, 250 automations, and 500 GB of attachments
  • Administrators control both Zendesk and Intercom, including billing, identity, APIs, integrations, and export permissions.
  • Zendesk remains intact and recoverable until Intercom 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.
02What transfers

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Customers, contacts, and organizationspartialcriticalIdentity 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 Zendesk and Intercom.Map customers, contacts, and organizations explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Tickets and conversationspartialcriticalTicket states, conversation parts, channel semantics, requester identity, and threading require transformation. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Map tickets and conversations explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Public replies and private notespartialcriticalComment visibility and author attribution can flatten or expose internal material. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Map public replies and private notes explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Attachments and inline mediapartialhighExports can preserve attachment metadata while binaries, inline images, or authenticated URLs remain behind. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Map attachments and inline media explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Agents, teams, roles, and permissionsmanualcriticalAgent accounts, restricted groups, custom roles, and licensing must be provisioned deliberately. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Inventory and rebuild agents, teams, roles, and permissions, then test normal, edge, failure, and rollback behavior.
Custom fields, forms, tags, and statusespartialhighField types, option values, required rules, lifecycle states, and tag behavior differ. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Map custom fields, forms, tags, and statuses explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Macros, triggers, routing, and SLAsmanualcriticalAutomation syntax, business hours, escalation clocks, assignment rules, and SLA calculations are runtime configuration. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Inventory and rebuild macros, triggers, routing, and slas, then test normal, edge, failure, and rollback behavior.
Help center articles and categoriespartialhighKnowledge hierarchy, locales, URLs, votes, and author metadata have separate import constraints. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Map help center articles and categories explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Reports, CSAT, and SLA historylosthighImported records do not recreate destination-native metrics, historical SLA calculations, or reporting baselines. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Archive reports, csat, and sla history as dated source evidence and define the new destination baseline.
Email channels, apps, bots, and webhooksmanualcriticalInbound addresses, sender authentication, marketplace apps, bots, API clients, and callbacks remain source-bound. A successful bulk job therefore does not prove semantic parity between Zendesk and Intercom.Inventory and rebuild email channels, apps, bots, and webhooks, then test normal, edge, failure, and rollback behavior.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Zendesk: Customers, contacts, and organizationsIntercom: approved customers, contacts, and organizations representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for customers, contacts, and organizations.
Zendesk: Tickets and conversationsIntercom: approved tickets and conversations representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for tickets and conversations.
Zendesk: Public replies and private notesIntercom: approved public replies and private notes representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for public replies and private notes.
Zendesk: Attachments and inline mediaIntercom: approved attachments and inline media representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for attachments and inline media.
Zendesk: Agents, teams, roles, and permissionsIntercom: approved agents, teams, roles, and permissions representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for agents, teams, roles, and permissions.
Zendesk: Custom fields, forms, tags, and statusesIntercom: approved custom fields, forms, tags, and statuses representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for custom fields, forms, tags, and statuses.
Zendesk: Macros, triggers, routing, and SLAsIntercom: approved macros, triggers, routing, and slas representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for macros, triggers, routing, and slas.
Zendesk: Help center articles and categoriesIntercom: approved help center articles and categories representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for help center articles and categories.
Zendesk: Reports, CSAT, and SLA historyNo destinationunsupportedRetain immutable source evidence; do not manufacture destination-native history.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Zendesk data, configuration, access, and operating evidence before any destination write.

  1. Export every available Zendesk object and binary in scope, including customers, contacts, and organizations, tickets and conversations, public replies and private notes, attachments and inline media.
  2. 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.
  3. Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
  4. 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.

Transformation · Version-controlled migration workbook, SQL, or typed transformation code

Identity, schema, and disposition registry

Preserve stable identity and make every mapping or exclusion reviewable.

  1. Inventory source types, identifiers, owners, states, and access.
  2. Define one approved destination representation or explicit archive decision.
  3. 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.

Transformation · Official APIs, provider importers, checksums, and reconciliation scripts

Dependency-ordered migration package

Load prerequisite identities and configuration before dependent records and runtime actions.

  1. Normalize encoding, timestamps, identifiers, nulls, and destination limits.
  2. Run a representative pilot and retain request, response, and rejection evidence.
  3. 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.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Import

A completed migration hides missing or altered customers, contacts, and organizations

criticalpossible likelihood

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.

Cutover

Zendesk and Intercom both perform production actions

criticalpossible likelihood

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.

Verification

Destination access or security is broader than approved

criticalpossible likelihood

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.

06Precise timeline

Do the work in this order.

Estimate forUp to 500 agents, one million tickets, 250 automations, and 500 GB of attachments
Total elapsed15–45 business days
Active work70–180 hours
BufferAdd time for large Zendesk exports, destination rate limits, unsupported features, identity exceptions, regulated data, or a strict downtime objective.
01
Days 1–4Inventory and decisions2–4 days
02
Days 3–8Backup and reconcile2–5 days
03
Days 6–20Map, transform, and pilot5–12 days
04
Days 18–35Bulk load, final delta, and switch2–8 days
05
Days 25–45Observe and close7–14 days
  1. Days 1–4 · inventory

    Inventory and decisions

    8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting
    • Inventory Zendesk data, configuration, identities, integrations, limits, and billing.
    • Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.

    Depends on: Zendesk and Intercom administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item and production action has an owner and disposition.

    Stop when: Authority, retention, billing, access, or system ownership is unclear.

  2. 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 checkpoint

    Transform?

    Go when: The signed source manifest and exports agree.

    Stop when: Any critical dataset, binary, configuration, or recovery path is absent.

  3. Days 6–20 · pilot

    Map, transform, and pilot

    25–70 hours active5–12 days elapsedDestination processing and owner review waiting
    • Configure Intercom 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 checkpoint

    Scale?

    Go when: Every pilot mapping and blocking verification check passes.

    Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.

  4. 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 Zendesk.
    • Apply and reconcile the final delta, switch ownership to Intercom, and run all blocking checks.

    Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback

    Stop / go checkpoint

    Open production?

    Go when: Intercom 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.

  5. 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 checkpoint

    Close rollback?

    Go when: No trigger occurs during the approved observation period.

    Stop when: Data, access, delivery, routing, cost, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Intercom the only production system without losing the final Zendesk delta.

Recommended window: A low-volume weekday morning with platform, data, security, networking, finance, and business owners available.

  1. Freeze user, integration, schedule, and API writes in Zendesk.
  2. Capture and reconcile the final source delta against the last verified checkpoint.
  3. Apply the approved delta and configuration changes to Intercom.
  4. Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: Intercom alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Zendesk without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, keys, or retention settings are changed.

  1. Stop new user, integration, schedule, and API writes in Intercom.
  2. Restore prior Zendesk traffic, domains, credentials, automation, and integration ownership.
  3. Export and classify the Intercom post-cutover delta.
  4. Apply safe destination-era changes back to Zendesk without duplicating actions.
  5. Run the same blocking checks against the restored source.

Proof to capture: Zendesk again owns production with current data and no duplicate destination action.

Rollback immediately when
  • 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
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingCustomers, contacts, and organizations reconciliationCompare 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-02BlockingTickets and conversations reconciliationCompare 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-03BlockingPublic replies and private notes reconciliationCompare 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-04BlockingAttachments and inline media reconciliationCompare 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-05BlockingAgents, teams, roles, and permissions reconciliationCompare 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-06Custom fields, forms, tags, and statuses reconciliationCompare 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-07BlockingMacros, triggers, routing, and SLAs reconciliationCompare 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-08Help center articles and categories reconciliationCompare 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.
09Post-migration cleanup

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.

  1. Create final Zendesk exports and archive verification, access, financial, and rollback evidence.
  2. Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
  3. Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
  4. Keep the source intact and read-only through the approved legal and operational retention window.
  5. Cancel paid plans only after billing, legal, security, evidence, and recovery review.
  6. Schedule the next Intercom backup, restore test, access review, and migration-playbook review.
10Experiences from the field

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.

Independent case studyNick Ryabchenko · SupportYourApp

97% Faster Responses: Community Sauna's Zendesk-to-Intercom Migration Case Study2026

SupportYourApp documents rebuilding Community Sauna Baths' support operation while moving from Zendesk to Intercom. The project migrated data and recreated saved replies, automations, and key settings, then redesigned inboxes, ownership, workflows, WhatsApp handling, chatbot deflection, and reporting. The consultancy reports response time falling from three days to two hours and bot interactions doubling; those outcome claims come from the implementing service provider.

What they recommend
  • Treat the move as an operating-model redesign and assign owners for inboxes, saved replies, automation, channels, and reporting.
  • Baseline response time and bot deflection before cutover so claimed improvements can be separated from workflow and staffing changes.
Worth noticing
  • The reported gains followed a ground-up workflow rebuild, not merely copying Zendesk records into Intercom.
  • Clear ownership, standardized replies, and new automation changed alongside the help-desk platform.
Sources and evidence

Verify against the primary material.

Platform behavior changes. Check these sources and the review dates above before executing a production migration.

  1. Zendesk: official portability and migration documentationAccessed 2026-07-20
  2. Intercom: official portability and migration documentationAccessed 2026-07-20