The Complete Guide to Migrating from Intercom to Zendesk

While migrating your customer support system from Intercom to Zendesk might seem daunting, it's entirely manageable with the right approach.

This guide will walk you through each step, from defining your migration scope to configuring Zendesk post-migration.

Whether you're moving operational data, creating custom fields, or preserving historical ticket data, we'll help you avoid common pitfalls and ensure a smooth transition for your team.

Object mapping reference

Before touching the API, know what maps to what — and where data loss is possible.

Intercom Object	Zendesk Equivalent	Notes / Data Loss Risk
Admin	Agent	Roles may need manual mapping
Team	Group	Names must be pre-created before ticket import
Contact	End User	Leads require a tag or custom field to preserve distinction
Lead	End User	No native Lead type in Zendesk — add a lead tag during import
Company	Organization	Map company_id to external_id to prevent duplicates
Conversation	Ticket	Initial message → Description; replies → Comments
Intercom Ticket	Ticket	1:1 mapping; most straightforward object to move
Collection	Category or Section	Choose hierarchy depth before import; cannot be changed cleanly after
Article	Guide Article	Embedded image URLs must be re-hosted on Zendesk
Data Attribute	Custom Field	Must be pre-created in Zendesk before data import begins
Segment	User Segment	Logic only — must be recreated manually
Event	Sunshine Event	Requires Zendesk Suite Team or higher
In-App Message / Tour	No equivalent	Archive as JSON/CSV or convert to Help Center articles
Tag	Tag	Can be applied via API; routing rules must be rebuilt manually

Define your migration scope

Before you move a single byte of data, you need to categorize your assets. Not everything in Intercom has a direct mapping in Zendesk, so we need to split the data into three buckets: API migration, manual configuration, and archives.

Migrate via API

The bulk of your operational data will move programmatically. This includes your Admins (who become Zendesk Agents) and Teams (which map to Zendesk Groups).

Your core customer data, specifically Companies and Contacts, will map directly to Zendesk Organizations and Users. Finally, your content, including Articles, Conversations, and Intercom Tickets, will be transformed into Guide Articles and Zendesk Tickets.

Configure Manually

Some Intercom features are logic-based and cannot be simply copied over. Segments in Intercom are dynamic rules; you cannot migrate the rule itself via the API.

Instead, you will need to recreate these logic rules manually as User Segments in Zendesk. Similarly, Data Attributes must be recreated as Custom Fields in Zendesk before you start pouring data in.

Archive

There is no direct equivalent in Zendesk Support for active In-App Messages like tours or campaigns. The best approach here is to archive this data as JSON or CSV files for historical reference, or manually copy the content into Help Center articles if it is still relevant documentation.

Pre-migration readiness checklist

Run through this before writing a single line of migration code.

• Export a full data snapshot from Intercom (conversations, contacts, companies, articles)
• Audit all Data Attributes — note field types (text, dropdown, boolean) and dropdown option values
• Recreate all Custom Fields in Zendesk (User Fields, Organization Fields, Ticket Fields) with matching dropdown options before any data import
• Create all Agents and Groups in Zendesk and record their new Zendesk IDs
• Confirm your Zendesk plan level — Sunshine Events require Suite Team or higher
• Decide your Collections → Categories/Sections hierarchy mapping before importing any Knowledge Base content
• Set up a test Zendesk sandbox and run a partial import (100–500 records) to validate field mapping
• Document your deduplication strategy for Contacts and Companies (see external_id usage below)
• Confirm whether you will preserve original timestamps via a custom date field or accept Zendesk's import date
• Plan your cutover window — identify whether you will run Intercom and Zendesk in parallel, and for how long

Prepare Zendesk for data import

You cannot just dump data into a fresh Zendesk instance; you need to build the workspace before you move the data in.

First, you must create your Admins (Agents) and Teams (Groups) in Zendesk. This is a critical first step because when you migrate tickets later, you will need the new Zendesk IDs for these agents and groups to ensure assignments route correctly.

Next, look at your Intercom Data Attributes. These act as custom fields for your users and companies. You need to recreate these as User Fields, Organization Fields, or Ticket Fields in Zendesk.

A crucial detail here is that if you have dropdown menus in Intercom, you must create those specific dropdown options in the Zendesk admin panel first. If the option does not exist in Zendesk, the data migration for that field will fail.

Migrate objects

The sequence matters immensely here. If you try to migrate a ticket before the user exists, the ticket has no requester, and the import fails.

1. Organizations and Users

Start with Companies. Use Intercom's GET /companies endpoint to fetch them and create them as Organizations in Zendesk via POST /api/v2/organizations. Intercom uses a specific company_id, but Zendesk uses its own system ID. Store the Intercom company_id in Zendesk's external_id field on each organization — this is the primary deduplication key. If you run the import twice without this, you will generate duplicate organizations with no reliable way to merge them.

Once Organizations are in place, migrate your Contacts via Intercom's GET /contacts endpoint and create them as End Users in Zendesk via POST /api/v2/users. Set the external_id field to the Intercom contact ID. Link each user to the correct Organization using the Zendesk organization ID you captured in the previous step.

2. Knowledge Base

Move your Help Center content. Intercom organizes content into Collections, whereas Zendesk Guide uses a two-level hierarchy of Categories (POST /api/v2/help_center/categories) and Sections (POST /api/v2/help_center/sections).

You will likely need a workaround here. You can create a Zendesk Category for each Intercom Collection and then place a Section inside it, or map Collections directly to Sections if you prefer a flatter structure. Commit to one approach before you start — restructuring the hierarchy after articles are imported requires re-parenting every article individually.

Once the structure is up, migrate your Articles via POST /api/v2/help_center/articles into those sections.

3. Tickets and Conversations

This is the most complex part of the migration. Intercom has two main types of support records: the newer "Tickets" object and the traditional "Conversations."

Intercom Tickets map 1:1 to Zendesk Tickets via POST /api/v2/tickets, making them relatively straightforward to move. Conversations, however, are chat-based streams that require a workaround to fit into Zendesk's ticket model. Map the initial message of the conversation to the Zendesk Ticket Description.

For the back-and-forth replies (conversation parts), iterate through them and append them as Ticket Comments via PUT /api/v2/tickets/{ticket_id}. If there are Attachments in these conversations, you must download them from Intercom, re-upload them to Zendesk via POST /api/v2/uploads to get a token, and then associate that token with the comment creation.

4. Events

If you are on the Zendesk Suite Team plan or higher, you can migrate your Intercom Events into Sunshine Events via POST /api/v2/user_profiles/{user_id}/events. This allows you to keep a timeline of user actions, like "Item Purchased" or "Page Viewed," attached to the user profile in Zendesk.

If you are on a lower plan, Sunshine Events are not available and this data cannot be represented in Zendesk's standard data model. Your options are to archive the event log externally (JSON or a data warehouse) or to summarize key events as a note on the user profile.

Post Migration Configuration

Once the raw data is in, you have some configurations to build.

You need to manually rebuild your Segments. Since you cannot migrate the logic via API, look at your Intercom definitions and recreate them as User Segments in Zendesk Guide. User Segments control which customers can see which Help Center articles — getting this wrong means the wrong content is visible to the wrong users.

You will also need to apply Tags. While tags themselves can be migrated via API and applied to tickets or users, the business logic associated with them (like automated routing rules) needs to be configured manually in Zendesk triggers and automations.

What breaks and how to recover

These are the failure modes that surface most often, with the recovery path for each.

Duplicate users after re-run. If you run the user import more than once without checking for existing records, you will create duplicates. Use POST /api/v2/users/create_or_update (which merges on email) rather than POST /api/v2/users. If duplicates already exist, Zendesk's merge endpoint (PUT /api/v2/users/{id}/merge) can consolidate them, but ticket history must be verified after any merge.

Tickets with no requester. This happens when a Contact import is incomplete or fails silently. The ticket import will either fail or create an orphaned record. Always validate user import counts against Intercom's source count before starting the ticket phase.

Broken article images. Images embedded in Intercom articles point to Intercom's CDN. After account cancellation, these URLs return 404s. Re-upload images to Zendesk Guide via the Guide Media API and rewrite src attributes in article HTML before publishing.

Mismatched dropdown values. If a Ticket Field dropdown option in Zendesk does not exactly match the value being imported, the field import fails silently on that record. Run a pre-import validation pass that checks every distinct dropdown value in your Intercom export against the options configured in Zendesk.

Mid-migration failure recovery. If the migration fails partway through, do not restart from scratch. Use the external_id values you set during import to identify which records were successfully created. Query Zendesk for existing records, diff against your source export, and resume from the first unprocessed record. This is why setting external_id on every object is non-negotiable.

Cutover strategy

How you cut over matters as much as the migration itself.

For most teams, a parallel-run period of 3–5 business days is the minimum viable buffer. Keep Intercom active for inbound conversations while Zendesk is being validated. Any new conversations created in Intercom during this window will need a delta sync before you decommission it.

For the delta sync, pull all Intercom conversations updated after your initial migration start timestamp (updated_at > migration_start) and re-run just those records. Because you set external_id on every ticket, re-importing updated conversations will update existing Zendesk tickets rather than create duplicates.

Only decommission Intercom after:

• All open conversations have been re-synced and verified in Zendesk
• Your team has confirmed routing, triggers, and automations are functioning
• Article image URLs have been rewritten (before cancellation kills the CDN)

Insider Secrets

Here are a few things that usually catch people off guard during this specific migration.

The Lead Trap: Intercom distinguishes between "Users" and "Leads," but Zendesk treats them both as "Users." If you just migrate them blindly, you will lose the distinction. You must add a specific tag (like "lead") or a custom field value to these records during the migration so you can identify them later in Zendesk.

The Timestamp Problem: Zendesk does not allow you to backdate the creation time on standard ticket endpoints. If you migrate a conversation from 2021 today, Zendesk will say it was created today. To preserve history, you must create a custom date field in Zendesk and populate it with the original Intercom created_at value during the import.

Comment Context: Similar to tickets, you cannot natively backdate comments. All your historical replies will appear as if they were made right now. A pro tip is to prefix the body of the comment with the original timestamp text, for example: "Original date: 2023-01-01 - Message: ... ". This gives agents the context they need when reading old tickets.

Broken Images: If your articles contain embedded images, simply copying the HTML source code isn't enough. Those image URLs usually point to Intercom's servers. Once you cancel your Intercom account, those images will break. You must upload the images to Zendesk Guide Media and rewrite the image source URLs in the article body to point to the new Zendesk location.

Summary

Migrating from Intercom to Zendesk is a transformation of data structures as much as it is a movement of data.

By strictly following the order, you preserve the relationships that make your data useful.

While the conversational nature of Intercom requires some creative mapping into Zendesk tickets, using custom fields for historical dates and carefully handling attachments will ensure your agents have the full history they need on day one.

At ClonePartner, we've completed numerous Intercom-to-Zendesk migrations. Each project is handled by a dedicated engineer who customizes the data mapping to match your setup. If you want to avoid the technical complexity, ClonePartner can manage the entire migration for you, from planning and field mapping to validation and go-live.

Further reading:

• Intercom
• Zendesk