Zendesk → Intercom
Move your support data from Zendesk to Intercom with confidence. This guide explains tickets, contacts, organizations, custom fields, attachments, field mapping, route limitations, and best-practice migration planning.
Compatibility summary
Field mapping reference
| Zendesk source | Intercom target | Mapping note | |
|---|---|---|---|
| Subject | → | Subject | Direct match |
| Description | → | Description | HTML content preserved where supported |
| Status | → | Status | Mapped with approved status values |
| Priority | → | Priority | Mapped automatically or by rule |
| Requester | → | Contact / requester | Linked by email where possible |
| Assignee | → | Agent / owner | Mapped to existing users |
| Tags | → | Tags | Preserved as labels or tags |
| Custom fields | → | Custom fields | Requires type and value review |
| Created at | → | Created time | Timezone converted |
| Updated at | → | Updated time | Timezone converted |
Route insights & quirks
Status mapping differences
Status names may differ and should be approved before the full import.
Automations not migratable
Triggers, workflows, macros, SLA policies, and rules should be recreated in Intercom.
Custom fields need review
Names, types, required values, and dropdown options should be mapped carefully.
Attachments preserved
Ticket attachments and inline images should be validated during the HDM demo migration.
Migration checklist
- Connect Zendesk and Intercom accounts
- Review and confirm field mappings
- Run an HDM demo migration with sample data
- Validate migrated data in Intercom
- Schedule full migration and final delta
Best practices
- Run a sample migration before the production import.
- Map custom fields carefully because names and behavior may differ.
- Communicate read-only periods during cutover.
- Export recent data and run a delta migration if needed.
- Review reports after migration to catch skipped records.
Zendesk to Intercom migration: what to plan before importing data
A successful Zendesk to Intercom migration is not only a matter of moving records from one API to another. The real work is understanding how the source data model differs from the target data model, what objects have direct equivalents, what fields require mapping, which settings should be rebuilt manually, and which historical records need validation before production cutover.
This route is usually about moving from traditional ticketing to conversational support and keeping enough history for agents to understand customer context.
This guide is written for teams comparing help desk data importer options, support leaders preparing a platform switch, consultants planning a customer migration, and operations teams that need a clear checklist before they run a demo or full import with HDM / Help Desk Migration.
For this Zendesk to Intercom route, do not approve the migration by record count alone. Ask one support admin and one working agent to review a demo set that includes old tickets, recent tickets, private notes, attachments, custom fields, and at least one awkward edge case. That review usually catches the issues that a generic export checklist misses.
What this route guide covers
1. Data model differences between Zendesk and Intercom
Zendesk uses a mature ticketing model built around tickets, users, organizations, groups, brands, ticket forms, comments, tags, custom fields, triggers, automations, macros, views, SLAs, and reporting. When you export historical support data from Zendesk, you are not simply exporting a flat list of tickets. You are exporting a connected support history made of customers, agents, teams, comments, notes, file links, field values, and operational context.
Intercom uses a conversation-first model built around people, companies, teammates, inboxes, teams, conversations, conversation parts, tags, notes, custom attributes, bots, workflows, and customer timeline context. That means the target account should be prepared before records are imported. If the target does not have the right users, teams, fields, statuses, companies, inboxes, departments, or pipelines, the imported data may technically arrive but still be hard for agents to use.
The goal is not to reproduce every source setting exactly. The goal is to preserve useful support history while making the data work naturally inside Intercom. A clean migration plan should decide which objects become native Intercom records, which source fields become custom fields, which data should be transformed, and which operational rules should be rebuilt manually.
Route-specific watch list
- Zendesk ticket structure does not always translate into Intercom conversation structure.
- Forms, brands, groups, and views need to be redesigned rather than imported directly.
- Automations, triggers, and macros are not historical records and should be rebuilt.
- Custom fields may become Intercom attributes, but field types and visibility need review.
The items above should be included in your demo migration review. If they are ignored until production cutover, the migration may look successful by record count but still fail for agents who rely on status logic, assignment history, customer context, or old attachments.
2. Migration scope: what usually moves from Zendesk to Intercom
The first planning step is to define scope. Many teams say they want to “migrate everything,” but in practice “everything” includes historical records, operational settings, reporting configuration, app integrations, and platform-specific behavior. A reliable help desk data import separates those categories before any data is moved.
Core historical records usually include tickets or conversations, public replies, internal notes, customers, contacts, organizations or companies, agents, tags, attachments, and custom fields. Operational configuration usually includes triggers, automations, macros, SLAs, views, reports, bots, workflows, routing rules, and channel settings. Those operational items often need to be recreated in Intercom instead of imported as records.
| Data type | Typical migration status | Planning note |
|---|---|---|
| Tickets / conversations | Usually migratable | Move historical support records from Zendesk into the closest Intercom ticket or conversation object. |
| Public replies | Usually migratable | Preserve chronological conversation history where both APIs expose message bodies and authors. |
| Private notes | Usually migratable with validation | Validate visibility so internal notes do not become public comments in the target. |
| Contacts / requesters | Usually migratable | Match by email where possible; resolve duplicates before the full import. |
| Companies / organizations | Requires mapping | Company, account, or organization models differ between platforms and need relationship review. |
| Agents / teammates | Requires preparation | Create or invite users in the destination before mapping ownership and assignment. |
| Groups / teams / inboxes | Requires mapping | Team structures rarely match exactly and should be mapped to the operating model in the target. |
| Custom fields | Requires mapping | Review field type, required status, dropdown values, multi-select behavior, and defaults. |
| Attachments | Usually migratable with checks | Test large files, inline images, old links, and file-level access in the demo migration. |
| Tags / labels | Usually migratable | Tag behavior may change if the target uses labels, properties, or custom fields. |
| SLAs / automations / macros | Rebuild recommended | Treat workflow logic as configuration, not historical data. |
3. Source export constraints in Zendesk
Before the migration starts, audit the source account. For Zendesk, pay special attention to ticket forms, brands, groups, custom ticket fields, suspended users, deleted users, side conversations, merged tickets, attachments, private notes, followers, tags, and trigger-related history.. These objects and settings are common sources of surprises because they may be hidden in day-to-day support work but become important during export and validation.
Export constraints are not always obvious. A platform may expose tickets but paginate comments separately. It may expose attachment metadata but require a separate file download. It may expose users but not deleted-user details. It may export custom fields but not the exact display labels your agents see in the interface. That is why the demo migration should include old tickets, new tickets, tickets with many replies, tickets with private notes, tickets with files, and tickets that use custom fields.
Do not judge the migration by one simple sample record. Choose sample records that represent the difficult parts of your help desk history.
4. Target import preparation in Intercom
Prepare Intercom before importing production data. The target setup should include teammates, teams, inboxes, tags, custom attributes, people/company structure, conversation routing, help center collections, assignment behavior, and reporting segments.. If these structures are missing, records may import with incomplete ownership, unexpected status values, missing relationships, or fields that are difficult to report on later.
Target preparation also prevents accidental customer-facing side effects. For example, automations and notifications should be reviewed before historical records are imported. If the target sends notifications for imported comments, reopens closed records unexpectedly, or applies live assignment rules to historical tickets, agents and customers may see confusing activity.
A practical target preparation checklist should include user creation, company or organization import, custom field creation, dropdown value review, permissions review, notification review, and a plan for when to enable workflows after validation.
5. Field mapping for Zendesk to Intercom
Field mapping is the center of this migration. The most important mapping areas are users, organizations, groups, statuses, priorities, ticket forms, custom field types, tag behavior, requester/assignee ownership, and comment visibility.. The destination platform may use similar words but different logic. A field called “status” can have different closed-state behavior. A field called “company” may not behave like an organization. A user role in the source may not map cleanly to an agent permission in the target.
For this reason, mapping should be reviewed before the full import. The review should include business owners, support admins, and at least one agent who understands how historical records are used day to day. The goal is to avoid silent data loss: records may import, but if fields land in the wrong place or values are changed unexpectedly, reporting and agent workflows can suffer.
| Zendesk field or concept | Intercom target concept | Recommended review |
|---|---|---|
| Requester / customer | Contact, user, person, or customer record | Match by email where possible and review duplicates. |
| Organization / company / account | Company, organization, account, or custom relationship | Decide whether domain matching is safe. |
| Agent / teammate / owner | Agent, teammate, owner, or assignee | Create destination users before import. |
| Status | Status or lifecycle stage | Approve open, pending, solved, resolved, and closed behavior. |
| Priority | Priority | Confirm value names and reporting impact. |
| Tags | Tags, labels, attributes, or custom fields | Clean unused tags before migration if possible. |
| Custom fields | Custom fields or properties | Review field types, required values, and dropdown options. |
| Private notes | Internal notes or private comments | Validate visibility in the demo migration. |
6. Status mapping and lifecycle behavior
Status mapping deserves separate attention because it affects agent queues, reporting, SLA behavior, and customer communication. A historical record that was “solved” in Zendesk should not accidentally become active in Intercom. A ticket that was waiting on a customer should not look like an agent-owned unresolved issue unless your team intentionally wants that behavior.
| Source status concept | Target status concept | Review note |
|---|---|---|
| Open / New | Open / New | Usually a direct mapping, but default statuses should be confirmed. |
| Pending / Waiting | Pending / Waiting on customer | Often needs a decision about who the ticket is waiting on. |
| On-hold | Pending, hold, or custom status | This is frequently route-specific and should be approved. |
| Solved / Resolved | Resolved / closed equivalent | Some targets separate solved from closed; confirm reporting impact. |
| Closed | Closed / archived | Closed records may have editing restrictions after import. |
7. What should usually be rebuilt, not imported
The following items are usually better rebuilt in Intercom because they control live operations rather than historical context: triggers, automations, macros, views, marketplace apps, SLA policies, business rules, channel configuration, and most reporting logic.. Rebuilding them gives your team a chance to improve the workflow instead of recreating old complexity.
- Automations, triggers, workflow rules, and assignment logic
- Macros, saved replies, canned responses, and agent shortcuts
- SLA policies, business hours, escalation logic, and reporting dashboards
- Marketplace apps, app settings, webhooks, bots, and channel configuration
- Permissions, team rules, and security settings that should be reviewed by admins
8. Attachments, inline images, and historical files
Attachments are often the difference between a useful migration and a frustrating one. Support teams rely on screenshots, logs, invoices, CSV files, screen recordings, contracts, and troubleshooting artifacts. If those files are missing or disconnected from the right comments, the imported ticket history may be technically complete but operationally weak.
For a Zendesk to Intercom migration, validate three attachment scenarios: normal attached files, inline images pasted into message bodies, and old files linked through private source URLs. Inline images can be especially tricky because the image may appear in the source UI but actually reference a private file URL. During migration, that file may need to be downloaded, uploaded to Intercom, and re-linked in the correct message body.
The demo migration should include records with large attachments, old attachments, several files on one ticket, inline screenshots, private notes with files, and conversations where attachments appear in the middle of a long thread. After the demo, open imported records in Intercom, download the files, and confirm that the right file belongs to the right comment.
9. Migration methods: manual export, API script, or HDM
There are three broad ways to approach this route. The first is a manual export and import process. This can work for small datasets, but it becomes risky when you need comments, notes, attachments, users, organizations, and custom fields to stay connected. CSV files rarely capture the full relationship model of a help desk platform.
The second method is a custom API script. This gives control but also creates engineering responsibility. Your team needs to handle pagination, retries, authentication, file downloads, rate limits, user matching, field transformations, logging, skipped records, and incremental updates. For one-off migrations, that can become more expensive than expected.
The third method is using HDM / Help Desk Migration. HDM is designed specifically for help desk migration workflows, including demo migration, mapping review, full import, and delta migration. For commercial migrations, this is usually the most practical path because it provides a repeatable process and reduces the need to build import tooling from scratch.
10. When HDM is a good fit
- You need to preserve ticket or conversation history with comments and private notes.
- You have custom fields, statuses, companies, organizations, or multiple teams to map.
- You need attachments and inline images validated before cutover.
- You need a demo migration that stakeholders can review inside Intercom.
- You want a delta migration for new and updated records after the main import.
- You want to avoid building a one-off API importer for a single platform switch.
11. Step-by-step Zendesk to Intercom migration plan
Export object counts, identify custom fields, list active/inactive agents, review organizations or companies, and collect complex sample records.
Create users, teams, fields, statuses, inboxes, groups, departments, pipelines, or companies in Intercom before import.
Review statuses, priorities, requester mapping, organization/company mapping, custom fields, tags, and attachment handling.
Import a sample dataset and validate the output inside Intercom with admins, agents, and business stakeholders.
Update mapping rules, add missing fields, clean duplicates, adjust target configuration, and rerun the demo if needed.
Schedule the production import for a planned window and monitor warnings, skipped records, file handling, and throughput.
Move new or updated records created during the transition window so the final target account is current.
Validate counts, open migrated records, test searches and reports, enable workflows, and hand the destination to agents.
12. Post-migration QA checklist
- Compare source and target counts for tickets, comments, contacts, companies, users, tags, and attachments.
- Open random migrated records from different years, teams, statuses, and customer segments.
- Check public replies, internal notes, authorship, timestamps, attachments, and inline images.
- Validate custom fields, dropdown values, required fields, tags, and status mapping.
- Confirm that closed or resolved records did not reopen unexpectedly.
- Review skipped records and decide whether to retry, transform, or accept the exception.
- Ask agents to search for old customer history and confirm that it is usable.
- Enable workflows, SLAs, automations, and reporting only after historical data is accepted.
13. SEO quick answer for this route
Can you migrate from Zendesk to Intercom? Yes, core support data such as tickets or conversations, contacts, companies or organizations, comments, notes, tags, custom fields, and attachments can usually be migrated with the right mapping and validation process.
What needs the most attention? The highest-risk areas are custom fields, status mapping, requester identity, company or organization relationships, private note visibility, large attachments, inline images, and operational settings that should be rebuilt in Intercom.
Best next step: run an HDM demo migration with representative records before you approve the full Zendesk to Intercom import.
Zendesk to Intercom migration FAQ
Can I migrate from Zendesk to Intercom?
Yes, a Zendesk to Intercom migration is usually possible for core support records, but the exact scope depends on enabled objects, API access, custom fields, historical data volume, and the way your teams use the source platform. The safest approach is to run an HDM demo migration and validate the sample inside Intercom before approving the full import.
Will ticket history and comments be preserved?
In most help desk migrations, ticket or conversation history can be preserved with public replies, internal notes, authorship, and timestamps where both platforms expose the needed data. You should test long threads, private notes, attachments, merged tickets, and older archived tickets during the demo migration.
What happens to custom fields?
Custom fields require field-level mapping. Text fields are usually straightforward, but dropdowns, multi-select fields, required fields, numeric fields, date fields, dependent fields, and system fields need review. If the destination does not support the same field type, the data may need to be transformed, stored in a note, or mapped to a different object.
Are automations, macros, and SLA policies migrated?
Automations, triggers, macros, canned responses, SLA policies, views, reports, and business rules should usually be rebuilt directly in Intercom. They are operational configuration rather than historical support records, and importing them blindly can create incorrect routing, notifications, or reporting behavior.
Can attachments and inline images be migrated?
Attachments can usually be migrated when the source provides downloadable files and the target accepts uploaded files through its API. Inline images need special review because they may be stored as private source URLs embedded in message bodies.
Do I need a demo migration?
Yes. A demo migration is the most practical way to verify how your real tickets, contacts, companies, notes, attachments, and custom fields appear in the destination.
Can I run a delta migration?
A delta migration is commonly used when support continues in the source while the main migration is being validated. The final delta moves records created or updated during the cutover window.
How do I validate the migration?
Validate record counts, open random migrated tickets, check customers and companies, review custom fields, download attachments, compare private note visibility, inspect timestamps, and ask agents to test business-critical scenarios in the destination.
What data may stay behind?
Data may stay behind when the destination has no equivalent object or the API does not expose the source data. Common examples include workflow rules, historical reporting configuration, app data, bots, advanced SLA logic, and merged-ticket metadata.
Why use HDM for this route?
HDM is designed for help desk data migrations and provides a practical workflow for demo migrations, mapping review, full migration, and post-migration validation.
Plan your Zendesk to Intercom migration with HDM
Use this guide to prepare your source audit, target configuration, field mapping review, demo migration, full import, delta migration, and post-migration QA. For real validation, run an HDM demo migration and check how your actual support records appear inside Intercom.
Run free demo migration with HDM →