Zendesk to Intercom Migration: The 2026 Technical Guide

Migrating from Zendesk to Intercom is a data architecture translation, not a lift-and-shift. Zendesk organizes everything around tickets — structured records with discrete statuses, requesters, organizations, groups, agents, and comment threads. Intercom organizes everything around conversations and, since 2023, a dedicated Tickets object — both following a messenger-first, contact-centric model. Every field, timestamp, and relationship between records has to be deliberately mapped between these two models, and the gaps between them are where data gets silently dropped.

This guide covers the structural mismatches, API rate limits on both sides, the full data-mapping schema, attachment handling, notification traps, Intercom's built-in migration tool, and a direct comparison of migration methods — so you can pick the approach that matches your volume, timeline, and risk tolerance.

For the step-by-step walkthrough of the basic migration process, see The Complete Guide to Migrating from Zendesk to Intercom. For a deeper look at Intercom's architecture and AI workflows, see The 2026 Technical Guide to Mastering Intercom.

Zendesk Tickets vs. Intercom Conversations: The Data Model Mismatch

This is the core problem. Zendesk's data model is ticket-centric. A ticket has a requester (end user), belongs to an organization, is assigned to a group and an agent, and contains an ordered list of comments — each marked as public or private. Metadata like priority, type, status, custom fields, SLA policies, and satisfaction ratings are first-class properties. Side conversations, ticket audits, and metric events are separate API objects.

Intercom's data model is contact-centric. A contact (user or lead) initiates a conversation. That conversation is a thread of conversation_parts — each part is a message, a note, or an action. Tags and custom attributes hang off the conversation or contact. Intercom also has a dedicated Tickets object (introduced in API version 2.9) that supports structured, trackable requests with defined states and custom ticket type attributes. Intercom's Tickets documentation says teammates mostly live in Conversations, while Tickets are used for more structured follow-up work. (developers.intercom.com)

The structural mismatches that cause the most damage:

• Side conversations in Zendesk have no native equivalent in Intercom. They must be migrated as private notes (lossy) or dropped entirely. Intercom's native importer does not migrate them at all. (intercom.com)
• Ticket statuses differ. Zendesk uses New → Open → Pending → On-hold → Solved → Closed. Intercom's documented native mapping: New → Submitted, Open → In progress, Pending → Waiting on customer, On hold → In progress, Solved → Resolved. Custom Zendesk states map to the nearest standard Intercom state, not to your own custom-to-custom logic. (intercom.com)
• Conversation parts are capped at 500 per conversation in Intercom. If a Zendesk ticket has more than 500 comments, the overflow will be silently truncated or require a transcript-style approach.
• HTML is not supported in conversation message bodies. Zendesk ticket comments often contain HTML formatting that must be stripped or converted to plain text.
• The Tickets API allows only one contact on creation. If your Zendesk process relies on CC-heavy or multi-requester cases, you are in custom-logic territory from the start.

Pre-Migration Checklist: Prevent Customer Spam and Data Collisions

This step is non-negotiable. If you skip it, your migration will send emails to every customer whose historical ticket gets recreated in Intercom.

All closed tickets being imported will first go through the process of being opened, updated, and replied to before they are closed via the API. If workflows fire on any of those state transitions, your customers get spammed. Disable these specifically:

• Active outbound campaigns and Series
• Workflows that trigger on conversation creation or updates (add an exception for "Created via API" or turn them off entirely)
• Email notification settings for new conversations
• Any live bots or Product Tours that auto-fire

Beyond notifications, verify these settings before you run any import:

• Disable phone number validation in workspace settings — invalid phone formats from Zendesk contacts will block imports otherwise.
• Enable default assignment settings — choose "Keep it unassigned or assigned to the team" so tickets without mapped agents don't fail.
• Configure allowed attachment file types — Intercom only supports text files, images, videos, and PDFs by default. If your Zendesk data includes .zip, .csv, or other file types, you must whitelist them before import.
• Create teams and teammates in Intercom first. Intercom's importer expects them to exist before data arrives. The Admins API is read-only for existing admins, so permissions and seats are manual setup work. Keep a default team and default teammate for unmapped or deleted users. (intercom.com)
• Create required ticket types and custom attributes first. The native importer needs Customer and Back-office ticket types pre-configured. For API-based imports, Intercom contacts can only be written to custom attributes that already exist in the workspace.
• Choose a cutover model upfront. Intercom's native importer is a point-in-time snapshot, not a live delta engine. If your agents keep working in Zendesk until launch day, plan for delta sync explicitly. Reruns delete and reimport previously imported tickets rather than incrementally merging changes. (intercom.com)

For a deeper dive into managing triggers during a move, read Your Helpdesk Migration's Secret Saboteur: Automations, Macros, and Workflows.

Zendesk to Intercom Data Mapping Guide

The mapping must follow a strict order. Import tickets before contacts exist and every ticket fails. Import contacts before companies and the company association is lost.

Order of Operations

1. Companies — Migrate Zendesk Organizations to Intercom Companies via the Companies API. Intercom companies do not surface meaningfully until contacts are associated with them, so associate contacts immediately after creation.
2. Contacts — Migrate End Users to Contacts. Use external_id to map the legacy Zendesk user ID — this is your anchor for deduplication. Decide your matching rule order upfront: usually external ID first, email second, then controlled fallback. Deleted, inactive, and suspended Zendesk users are not migrated by the native importer; comments from those users are mapped to a default "Inactive Intercom Contact." (intercom.com)
3. Data Attributes — Create custom ticket attributes and contact attributes in Intercom that mirror your Zendesk Ticket Fields. Zendesk multiselect and lookup fields cannot be directly mapped by the native importer — the documented workaround is to flatten them into text, which preserves the value but weakens filtering and reporting. (intercom.com)
4. Tickets/Conversations — Import tickets. Associate each with the correct contact by Intercom-provisioned ID (retrieved after contact creation). Apply tags, attributes, and assignment.
5. Help Center — Import articles last, or use the built-in Zendesk article sync.

A practical custom field mapping might look like this:

legacy_zendesk_ticket_id: ticket.id
legacy_zendesk_group_id: ticket.group_id
requester_external_id: ticket.requester.external_id
requester_email: ticket.requester.email
company_external_id: ticket.organization.external_id
status_target:
  new: submitted
  open: in_progress
  pending: waiting_on_customer
  on_hold: in_progress
  solved: resolved
refund_reason_raw: join(zendesk.refund_reason_multiselect, ', ')

That last line exists because the native importer flattens multiselect values into text. If multiselect or lookup fields drive routing, analytics, or agent workflows, you need a custom path.

Comments vs. Audits: Know What You're Extracting

Do not confuse Zendesk comments with the full ticket timeline. Comments give you the visible conversation plus attachment content_url values and, for voice comments, a recording_url. Zendesk audits go deeper — they include comment events, notification events, field changes, privacy changes, redaction events, satisfaction events, and other administrative actions in the same audit stream. If you care about who changed status, when an SLA-related state changed, or how visibility evolved, you need audits, not just comments. Ticket-count parity is a weak success metric: you can recreate the right number of tickets and still lose a large slice of operational history. (developer.zendesk.com)

Handling Attachments, Inline Images, and Knowledge Base Articles

Attachments are the most common point of failure in helpdesk migrations. Zendesk attachments are hosted files on Zendesk's CDN. You cannot pass Zendesk attachment URLs to Intercom — once your Zendesk account is deactivated, those URLs break.

The correct process:

1. Download each attachment from Zendesk via the Attachments API (using content_url from comments; recording_url for voice comments).
2. Upload the file to a publicly accessible host (your own S3 bucket, for example) or directly to Intercom.
3. Reference the new URL when creating the conversation or ticket reply.

Intercom supports two attachment methods on replies: attachment_urls for image URLs and attachment_files where the file body is base64-encoded with name and content_type. Do not assume every Zendesk-hosted file URL can be passed through as an attachment_urls value — Intercom reserves that parameter for images and uses attachment_files for other file payloads. (developer.zendesk.com)

Attachment limits matter. Intercom accepts up to 10 attachment URLs per message. Intercom's built-in Zendesk migration tool handles up to 10 attachments and 10 inline images per ticket — anything beyond that is silently dropped. If a Zendesk ticket comment has more than 10 attachments, you need to split them across multiple reply parts or consolidate into a transcript note. The native importer also does not migrate call recordings. (intercom.com)

Migrating Zendesk Help Center Content

The same broken-link problem applies to Help Center articles. Article body HTML contains image URLs pointing to Zendesk's Guide media CDN.

Intercom now offers two official paths for Help Center migration: Import content for a one-time migration where Intercom becomes the new source of truth, or Sync content if Zendesk should remain authoritative and Intercom uses the content in a view-only synced form. Intercom says redirects are automatically created as permanent 301 redirects matched on the stable numeric Zendesk article ID — the right default if you care about old links and SEO continuity. (intercom.com)

As of April 2026, Intercom has announced that the legacy Zendesk article importer will be deprecated after April 25, 2026. (intercom.com)

Whichever path you choose, manually audit embedded image links post-import. Structure transfers cleanly; inline images often do not.

Navigating API Rate Limits: Zendesk Export & Intercom Import

Rate limits are the single biggest technical constraint for any migration script. Both platforms throttle aggressively, and the limits on each side are independent.

Zendesk Export Limits

Zendesk's Incremental Export API — the only efficient method for extracting tickets at scale — has its own rate limit, separate from the account-wide limit:

The High Volume API add-on requires a minimum of 10 agent seats and is available on Suite Growth plans and above. Enterprise Plus includes it by default.

Practical math: At 10 requests per minute, with each page returning up to 1,000 tickets, you can extract roughly 10,000 tickets per minute. A 200,000-ticket backlog takes at least 20 minutes of pure extraction time — assuming zero 429 errors, zero network issues, and no comment sideloads. With full comment history sideloaded, the payload per page grows and pagination slows.

Zendesk recommends cursor-based incremental exports and intentionally omits the most recent minute of ticket data to avoid race conditions. The Incremental Export compares start_time against a ticket's generated_timestamp, not its updated_at value — meaning the API can return tickets with an updated_at earlier than your start_time. Build overlap windows and idempotent upserts so the last active minute does not disappear during cutover. Deep pagination on GET /tickets.json is also rate-limited after page 500. (developer.zendesk.com)

The second Zendesk bottleneck is hydration. Pulling ticket shells is not enough. Comments, attachments, users, organizations, and audits each require separate API calls, compounding extraction time significantly.

For advanced export strategies, see 3 Advanced Ways to Export Tickets from Zendesk.

Intercom Import Limits

Intercom's API rate limits are more generous in raw numbers but have a subtlety that catches migration scripts:

The 10-second windowing is the trap. A rate limit of 10,000 per minute means roughly 1,666 operations per 10-second window. Burst past that in a single window and you get 429'd, even if your per-minute average looks fine.

Monitor the X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset response headers proactively rather than waiting for 429 responses. Use exponential backoff. Intercom supports created_at on replies, which lets you preserve source chronology if your replay pipeline is disciplined. (developers.intercom.com)

The real bottleneck is API call multiplication. A message-by-message migration inflates API calls by 10–100x compared to a transcript approach. Intercom's own documentation notes this explicitly. For a ticket with 15 comments, a message-by-message import requires: 1 conversation create + 14 reply calls + tag calls + attribute update calls + close call. That is 17+ API calls per ticket. At 100,000 tickets, that is 1.7 million calls minimum — roughly 170 minutes of continuous throughput at the 10K/min limit, assuming no retries.

A minimal import worker should follow this sequence:

1. Export Zendesk tickets by cursor window.
2. Resolve/create Intercom contacts and companies.
3. Create the target ticket or conversation.
4. Replay public replies, private notes, and attachments with source timestamps.
5. Set team, assignee, state, and tags.
6. Respect rate-limit headers and retry 429s with backoff.
7. Resume from the last successful checkpoint on rerun.

Intercom's Built-in Zendesk Migration Tool

Intercom offers a native Inbox Migration product that imports Zendesk data directly. Understand its capabilities and limits before choosing a method.

What it handles:

• Users, companies, and tickets from Zendesk
• Data attributes and ticket attachments (up to 10 per ticket)
• Automatic field mapping with manual override
• Team and teammate mapping
• Notes and inline images (up to 10 per ticket)

What it does not handle:

• Datasets over 150,000 tickets
• Partial imports (all tickets must be migrated)
• Ticket tags (must be recreated in Intercom via API or manually)
• Side conversations and call recordings
• Error log export
• Re-importing only failed records — you must restart the entire import, and reruns delete and reimport previously imported tickets
• Multiselect or lookup fields (flattened to text)
• Deleted, inactive, and suspended Zendesk users (mapped to a default contact)

For teams with under 150K tickets and straightforward field mappings, this tool is a reasonable starting point. For anything larger, partial, or with complex requirements, you need a custom script or a migration service.

Migration Methods: DIY Script vs. Self-Serve Tools vs. Managed Service

Three realistic approaches. Each has clear trade-offs.

Option 1: DIY Script (In-House Engineering)

Build a custom Python/Node script that reads from the Zendesk API and writes to the Intercom API.

When it works: Small datasets (under 20K tickets), simple field mappings, and an engineering team with spare capacity and API experience.

Where it breaks:

• Rate limit management across two platforms simultaneously. Zendesk's 10 req/min incremental export and Intercom's 10-second windowing require careful orchestration, not just a sleep() call.
• Attachment re-hosting. Downloading from Zendesk, uploading to a public host, and referencing the new URL in Intercom adds I/O complexity and error surface.
• Author mapping. Every comment must have the correct author — the original agent or the original customer — or the entire history is attributed to the API token owner.
• State management. If the script crashes at ticket 47,312, you need idempotent logic to resume without duplicating records.
• The 500-part limit. Tickets with extremely long threads must be handled differently.

Realistic timeline: 2–6 weeks of engineering time, depending on complexity. Maintenance burden persists if you need delta syncs.

Option 2: Self-Serve Migration Tools

Tools like Help Desk Migration (Relokia), Migr8Now, and Intercom's own Inbox Migration product offer UI-driven migrations.

When it works: Standard migrations with typical field mappings, teams without dedicated engineering resources, datasets under the tool's volume caps.

Where it breaks:

• Volume limits (Intercom's tool caps at 150K tickets).
• No export of error logs — you cannot selectively re-import failed records.
• Limited control over edge cases: custom author mapping, conditional field transforms, attachment handling for non-standard file types.
• Side conversations are typically migrated as private notes (lossy) or dropped entirely.

Vendors position themselves differently — Migr8Now emphasizes delta migrations, Help Desk Migration markets no-code moves and optional side conversation handling, Klamp markets AI-driven mapping. Those are vendor claims, not universal guarantees. The right buying question is not "does your homepage say zero downtime?" It is "show me exactly how a side conversation, inline image, deleted user, and custom status render in my Intercom pilot."

Realistic timeline: Days to a couple of weeks including test runs.

Option 3: Managed Migration Service

Hand the migration to a team that has done it before — repeatedly.

When it works: Large datasets, complex field mappings, zero-downtime requirements, compliance constraints, or teams that cannot afford a failed migration.

What to look for:

• Does the service handle rate limit orchestration natively (backoff, retry, header monitoring)?
• Can they run a delta sync to cover tickets that arrive between the initial bulk migration and cutover?
• Do they preserve legacy IDs so agents can search by old Zendesk ticket numbers?
• Do they handle attachment download, re-hosting, and re-linking?
• Can they map authors correctly on every single comment?

What You'll Need to Rebuild Manually

No matter which migration method you choose, some things do not migrate via API and must be configured by hand in Intercom:

• Workflows: Zendesk Triggers and Automations have no API migration path to Intercom Workflows. The logic rarely translates 1:1 — Zendesk triggers fire on ticket events; Intercom workflows fire on conversation events, reply events, or time-based conditions. Rebuild in Intercom's visual workflow builder.
• Macros / Saved Replies: Recreate in Intercom's UI.
• SLA Policies: Intercom supports SLAs but the configuration is different. Rebuild from scratch.
• Views / Inbox Configuration: Custom views in Zendesk map loosely to Intercom Inbox Views, but the filter syntax and available fields differ.
• Fin AI Agent Training: If you are using Intercom's Fin AI, ensure your migrated Help Center content and conversation history are structured to support Fin's training.
• User Segments: Zendesk segment logic rarely translates directly to Intercom's filtering logic. Rebuild manually.

Budget a separate rebuild stream for these items rather than assuming they come along for the ride.

When Not to Migrate Everything

Not every byte of Zendesk data belongs in Intercom. Before committing to a full historical migration, ask:

• Do agents actually reference tickets older than 2 years? If the answer is "rarely," consider migrating only recent history and archiving the rest to a queryable database or data warehouse.
• Is the migration for compliance? If you need the data for regulatory reasons but agents don't need it in their inbox, a structured archive (JSON in S3, for example) may be cheaper and faster than importing into Intercom.
• Message-by-message vs. transcript? Importing each comment as a separate conversation part preserves the full thread but costs 10–100x more API calls. Importing a single transcript note per ticket is faster and cheaper — but agents lose the ability to see individual reply timestamps and authors in the thread. Intercom's own migration documentation recommends the transcript approach for most teams, reserving message-by-message for cases where agent context on individual replies is operationally important. (intercom.com)

The right question is: when an agent opens a 2023 Zendesk record inside Intercom, what exact context must still be there for them to do their job? If the answer is subject, requester, company, key transcript, attachments, team ownership, and final state, the simplest approach may be enough. If the answer includes tags, side conversations, precise audit history, or call recordings, you need a custom plan.

Post-Migration Validation

After the import completes, verify:

• Ticket counts match. Compare total tickets exported from Zendesk against total conversations/tickets in Intercom. But count parity alone is a weak success metric — you can recreate the right number of tickets and still lose operational history.
• Spot-check 50+ records across different ticket types, statuses, and date ranges. Look for: correct author attribution, correct timestamps, intact attachments, correct tag application, and correct team/teammate assignment.
• Search for edge cases: Tickets with 100+ comments, tickets with 10+ attachments, tickets from deleted Zendesk users, tickets with side conversations, tickets with only private notes, multiselect fields that were flattened to text.
• Re-enable outbound messaging only after you've confirmed the import is clean. Turn on workflows, campaigns, and notifications one at a time.
• Test Fin AI responses against migrated Help Center articles to ensure content is being surfaced correctly.

For a complete post-migration QA framework, see Post-Migration QA: 20 Tests to Run After Your Helpdesk Migration.

How ClonePartner Executes Zero-Downtime Zendesk to Intercom Migrations

We do not force custom code when the native Intercom importer genuinely fits. If your move is under 150K tickets, covers all tickets, and falls within the importer's boundaries, the honest answer may be to use the native tool and keep the project small.

Where teams bring us in is the space between "the native importer almost works" and "the support operation cannot accept silent data loss." We run the migration as an engineering project following the delta migration model that Intercom's own documentation recommends:

1. Initial bulk run: All closed tickets up to a fixed "delta date" are migrated to a launch-ready but non-live Intercom workspace. Your team continues working in Zendesk with zero interruption.
2. Delta sync: On cutover day, we migrate everything that changed since the delta date — newly closed tickets plus all open/pending tickets.
3. Cutover: Forward your support email to Intercom, launch the Messenger, and go live.

For the full methodology, see Zero-Downtime Helpdesk Migration: How to Keep Support Running During the Move.

What we handle that DIY scripts typically don't:

• Attachment pipeline: We download every attachment and inline image from Zendesk, re-host it, and link it correctly in Intercom — including files beyond the 10-per-message limit.
• Rate limit orchestration: Our scripts monitor both Zendesk and Intercom rate limit headers in real time, adjusting throughput dynamically rather than relying on fixed delays.
• Legacy ID preservation: We store the original Zendesk ticket number as a custom attribute in Intercom so agents can search historical references without losing context.
• Author fidelity: Every comment is attributed to its original author — agent or customer — with correct timestamps.

Our QA does not stop at count parity. We test the edge cases that usually reveal real risk: tickets with private notes only, tickets from deleted or suspended users, heavy attachment history, flattened multiselect fields, custom status mapping, and sample accounts that agents actually reopen in real work.

If the migration is simple, keep it simple. If it needs custom engineering, make sure someone owns the edge cases end to end.