Zendesk to Intercom Migration Data: Complete Guide
Switching helpdesk platforms is one of the highest-stakes infrastructure moves a support team can make. Your ticket history is not just archive data: it is the institutional memory that powers agent efficiency, CSAT benchmarking, and in some industries, regulatory compliance. When companies decide to move from Zendesk to Intercom, the conversation inevitably turns to one core concern: how do you get the data across cleanly, completely, and without breaking the relational links that make it useful? Zendesk to Intercom migration data is the discipline of extracting support records from Zendesk (tickets, contacts, organizations, tags, attachments, and conversation history) and loading them into Intercom's conversation and contact model while preserving the associations between those records. This is harder than it sounds. Zendesk and Intercom use fundamentally different data models: Zendesk is ticket-centric, while Intercom is conversation and user-centric. That architectural difference means a naïve export-and-import will produce broken records, missing context, and frustrated agents on day one of the new platform. This guide walks through every layer of that process: what data is involved, how the two platforms' models compare, what tools and approaches exist, how to execute the transfer step by step, and how to validate the result. Whether you are a support ops manager, a CTO, or an IT lead handed the project, the framework below reflects what PortMux has seen work across dozens of real migrations in 2026.
- KEY TAKEAWAY
- Moving your support data from Zendesk to Intercom is not a simple export-and-import task; it requires careful field mapping, API rate-limit management, and a validation pass before you cut over production traffic. Teams that skip pre-migration audits regularly lose 10 to 30 percent of their ticket history to orphaned records and unmapped custom fields, a loss that directly damages CSAT measurement and compliance reporting.
- COST / TIMELINE RANGE
- A DIY Zendesk to Intercom data migration using the native APIs costs primarily in engineering time, typically 40 to 120 hours for datasets under 500,000 tickets. Managed migration services from vendors like Help Desk Migration or PortMux-vetted partners range from $500 to $8,000 depending on record volume, custom field complexity, and whether attachments are included.
- PORTMUX RECOMMENDATION
- Run a test migration on a 5 to 10 percent sample of your oldest and most complex tickets before touching production data, and always keep your Zendesk account active in read-only mode for at least 30 days post-cutover. Avoid any tool or service that promises a one-click migration without a field-mapping step, because that shortcut is how teams lose years of customer context.
What Data Is Actually Involved in a Zendesk to Intercom Transfer
A Zendesk to Intercom data migration covers six primary object types: tickets (conversations), end-users (contacts), organizations (companies), agents (teammates), tags, and attachments. Each object type has its own export method, its own field structure, and its own risk profile. Understanding the full scope before writing a single line of migration code is the difference between a clean cutover and a multi-week remediation.
Core Object Types
- Tickets / Conversations: The backbone of any support platform. Zendesk tickets include subject, body, status, priority, channel, timestamps, and custom fields. Intercom maps these to conversations, but the status taxonomy differs (Zendesk uses open/pending/solved/closed; Intercom uses open/snoozed/closed).
- End-Users / Contacts: Zendesk end-users become Intercom contacts. Email is the join key. Duplicate emails on either side will cause merge conflicts that must be resolved before import.
- Organizations / Companies: Zendesk organizations map to Intercom companies. Custom organization attributes need manual mapping to Intercom company data attributes.
- Agents / Teammates: Zendesk agents do not migrate as data objects; they must be pre-created in Intercom and then referenced during conversation import so that assignment history is preserved.
- Tags: Zendesk tags are flat strings. Intercom tags work similarly but live in a different namespace. Tags can be bulk-imported via the Intercom Tags API after conversations are created.
- Attachments: File attachments in Zendesk tickets are stored as CDN-hosted URLs. They must be downloaded, re-uploaded to Intercom, and then re-associated with the correct conversation message. This is the most error-prone step in any migration.
Only about 60 percent of Zendesk custom ticket fields have a direct semantic equivalent in Intercom conversation attributes (source: Intercom Help Center, 2026), meaning roughly 40 percent require either a new custom attribute or a deliberate decision to discard.
How Zendesk and Intercom Data Models Differ
Zendesk is built around the ticket as the atomic unit of work. Every interaction, regardless of channel, is eventually resolved into a ticket with a numeric ID. Intercom, by contrast, is built around the user and conversation: a contact is the center of gravity, and conversations are attached to that contact record. This model inversion is the root cause of most migration complexity.
In Zendesk, one ticket can have multiple comment threads from different users, with each comment timestamped and attributed. In Intercom, a conversation is a single thread between a user and a team. If a Zendesk ticket has comments from three different end-users (common in shared-account or CC scenarios), there is no clean Intercom equivalent. Those tickets must be handled with a documented transformation rule before migration begins.
Field Mapping Differences at a Glance
- Zendesk
ticket.status(open, pending, solved, closed) maps to Intercomconversation.state(open, snoozed, closed), with "pending" requiring a business-rule decision. - Zendesk
ticket.priority(low, normal, high, urgent) has no native Intercom equivalent; a custom conversation attribute must be created. - Zendesk
ticket.type(question, incident, problem, task) also has no Intercom equivalent and requires a custom attribute. - Zendesk
requester_idlinks a ticket to an end-user. In Intercom, a conversation must be associated with a contact viacontact_id. Contacts must exist before conversations are imported.
The biggest mistake I see teams make is trying to start the import before the field mapping document is finalized. You will end up with thousands of conversations that have no contact association, and untangling that retroactively is ten times the work of doing the mapping upfront.
Ryan Loiacono, Founder, Untapped Connections
Zendesk to Intercom Migration Approach Comparison
There are three primary approaches to moving Zendesk data into Intercom: manual API scripting, a third-party migration tool, or a managed migration service. Each carries different tradeoffs in cost, control, and risk. The right choice depends on your data volume, engineering capacity, and how much custom field complexity you are dealing with.
| Approach | Timeline | Risk | Best For |
|---|---|---|---|
| Manual API scripting (in-house) | 4 to 12 weeks | High (rate limits, mapping errors, no rollback) | Engineering teams with strong API experience and highly custom data models |
| Third-party migration tool (e.g. Help Desk Migration, Trujay) | 1 to 3 weeks | Medium (limited custom field support, vendor dependency) | Teams with standard Zendesk setups and budgets under $3,000 |
| Managed migration service (PortMux-vetted partners) | 2 to 6 weeks | Low (dedicated validation, rollback plan included) | Mid-market and enterprise teams with complex custom fields and compliance requirements |
| Hybrid (tool for standard objects, scripts for custom fields) | 3 to 5 weeks | Medium-low (combines speed with control) | Teams that want speed on bulk records but precision on edge cases |
Third-party migration tools handle an estimated 70 to 80 percent of standard Zendesk field types automatically (source: Help Desk Migration, 2026), but the remaining 20 to 30 percent of custom configurations almost always require manual intervention regardless of which tool you choose.
Step-by-Step Zendesk to Intercom Migration Process
A successful migration follows a sequenced process where each step depends on the output of the previous one. Skipping or reordering steps is the primary cause of orphaned records and failed imports. The order below reflects the dependency chain of Intercom's data model.
-
Pre-migration audit: Export a full data manifest from Zendesk using the Zendesk API's
/api/v2/incremental/tickets.jsonendpoint. Count tickets by status, identify all custom fields in use, flag duplicate end-user emails, and document any multi-user ticket threads that will need transformation rules. This step typically takes 3 to 5 days for datasets over 100,000 tickets. - Field mapping and transformation design: Create a field mapping document that assigns every Zendesk field to either an existing Intercom attribute, a new custom attribute you will create before import, or a "drop" decision with documented justification. This document becomes the source of truth for your import scripts or migration tool configuration.
- Pre-create Intercom objects: Create all Intercom teammates (agents), companies, custom conversation attributes, and custom contact attributes before importing any records. Conversations and contacts reference these objects by ID, so they must exist first. Use Intercom's bulk import endpoints where available to reduce API call volume.
-
Import contacts and companies: Import Zendesk end-users as Intercom contacts and Zendesk organizations as Intercom companies. Use Intercom's
/contactsPOST endpoint. Resolve duplicate emails before this step, not after. Retain the mapping of Zendesk user IDs to Intercom contact IDs for the conversation import step. - Import conversations (tickets): Import tickets as Intercom conversations, using the contact ID mapping from step 4 to associate each conversation with the correct contact. Apply the field transformation rules from your mapping document. Import in batches of 500 to 1,000 records and implement exponential backoff to handle Intercom's API rate limits (currently 83 requests per 10 seconds on most plans).
-
Import attachments and tags: Download all Zendesk ticket attachments from their CDN URLs, re-upload to Intercom via the
/uploadendpoint, and patch the resulting attachment URLs back into the correct conversation messages. Then bulk-apply tags to conversations. Run a final record count comparison between Zendesk and Intercom before declaring the migration complete.
API Rate Limits and Technical Constraints to Plan For
Intercom's API rate limits are the most common cause of extended migration timelines. As of 2026, Intercom enforces a limit of 83 requests per 10 seconds on standard plans and 166 requests per 10 seconds on higher-tier plans. At 83 requests per 10 seconds and an average of 1 API call per conversation message, a dataset of 500,000 messages will take a minimum of 16 to 17 hours of pure API time, not counting retries, backoff periods, or the contact import phase.
Managing Zendesk API Limits During Export
Zendesk also applies rate limits on its export endpoints. The incremental export APIs are capped at 10 requests per minute for most plans. For large datasets, use the Zendesk Bulk Export (NDJSON) feature instead, which generates a downloadable file outside the rate-limit window. This single change can reduce the export phase from days to hours on datasets over 200,000 tickets.
Handling Import Failures
- Log every failed API call with the full request payload and HTTP error code.
- Build an idempotency key into your import script using the original Zendesk ticket ID so that re-runs do not create duplicate conversations.
- Run a nightly diff between your Zendesk manifest and your Intercom import log until the counts match exactly.
Intercom's API enforces a 10MB limit per conversation import payload (source: Intercom Developer Docs, 2026), which means tickets with large inline images or multi-part attachments must be split before import or they will fail silently at the payload level.
Validating Your Migration Before Cutover
Validation is not optional. A migration that passes an eyeball check but fails a systematic record count comparison will create compliance exposure and agent confusion the moment production traffic moves to Intercom. The validation phase should be treated as a formal QA sprint, not a quick sanity check.
Validation Checklist
- Record count parity: Total conversations in Intercom must equal total tickets exported from Zendesk (minus any records deliberately excluded by your migration scope).
- Contact association rate: Every conversation in Intercom should have a linked contact. Query for conversations with no contact association and investigate each orphan.
- Custom field spot-check: Pull 50 random tickets from Zendesk and manually compare them to their Intercom counterparts, field by field.
- Attachment integrity: Confirm that attachment URLs in imported conversations return HTTP 200 and are not broken CDN links pointing to deleted Zendesk storage.
- Tag accuracy: Verify that a sample of heavily-tagged Zendesk tickets have the correct corresponding tags applied in Intercom.
- Timeline integrity: Confirm that conversation timestamps in Intercom reflect the original Zendesk ticket creation and update times, not the import timestamp.
We always tell clients: your migration is not done when the import script finishes. It is done when you can answer a compliance auditor's question about a specific ticket from three years ago and get the right answer from Intercom. That is the bar.
Ryan Loiacono, Founder, Untapped Connections
Risk Factors and How PortMux Categorizes Them
Not all migration risks are equal. PortMux categorizes migration risks into three tiers based on their impact on data integrity and recovery cost. Understanding which tier a risk falls into helps teams prioritize remediation effort and set realistic timelines.
| Risk Factor | Tier | Impact | Mitigation |
|---|---|---|---|
| Orphaned ticket-to-contact links | Critical | Conversations inaccessible to agents; CSAT history broken | Pre-migration contact deduplication and post-import orphan query |
| Unmapped custom fields | High | Loss of workflow-critical metadata (e.g. SLA tier, product area) | Complete field mapping document before import begins |
| Broken attachment URLs | High | Missing evidence in compliance-sensitive tickets | Separate attachment transfer pipeline with integrity checks |
| Timestamp drift | Medium | Incorrect SLA reporting and customer timeline confusion | Explicit timestamp mapping using ISO 8601 format in all payloads |
| Rate limit throttling | Medium | Partial imports that look complete but are missing records | Exponential backoff, batch sizing, and nightly reconciliation logs |
Data migration projects across SaaS platforms have an average rework rate of 23 percent when no formal validation phase is included (source: Gartner research, 2026), meaning nearly one in four migrations requires a second pass that doubles the total project cost.
Tools and Services for Zendesk to Intercom Data Migration
Several commercial tools and service providers specialize in helpdesk-to-helpdesk migrations. The right choice depends on your budget, data volume, and tolerance for customization limits. Here is how the main options compare as of 2026.
Self-Service Migration Tools
- Help Desk Migration: A GUI-based tool that connects to both platforms via OAuth, maps standard fields automatically, and provides a preview migration on up to 20 records. Good for straightforward datasets. Pricing scales with record count.
- Trujay: Offers automated migration with a field-mapping interface. Supports Zendesk and Intercom natively. Works well for contact and ticket records but has limited attachment handling.
- Import2: A lightweight option for smaller datasets (under 50,000 tickets). Faster setup than Help Desk Migration but fewer customization options for complex field structures.
Custom API Scripting
For teams with complex custom fields, multi-brand Zendesk setups, or compliance requirements, a custom Python or Node.js migration script built against the Zendesk REST API and Intercom REST API gives the most control. The cost is engineering time (typically 60 to 120 hours for a mid-market dataset), but the output is a fully auditable, repeatable migration pipeline that can be run incrementally during the parallel-run period.
PortMux-Vetted Migration Partners
PortMux maintains a directory of migration service providers who have demonstrated field-mapping rigor, post-migration validation protocols, and rollback documentation on Zendesk-to-Intercom projects. These partners are particularly suited to enterprise migrations where data governance, GDPR compliance, and audit trails are non-negotiable requirements.
Conclusion: Getting Your Data Across Without Losing What Matters
A Zendesk to Intercom migration is fundamentally a data engineering project dressed up as a platform switch. The technology is tractable; the failure points are almost always in planning, sequencing, and validation. Teams that invest in a pre-migration audit, a detailed field mapping document, and a formal validation sprint before cutover consistently arrive at a clean Intercom instance with their support history intact. Teams that treat it as a weekend import task consistently spend weeks in remediation.
The PortMux framework for this migration has three non-negotiable phases: audit first, map everything, validate before cutover. Every shortcut in those three phases multiplies the cost of recovery after go-live. The platforms themselves are capable of holding your data cleanly; the work is in the transfer logic that bridges two different data models without dropping or distorting records along the way.
If you are planning a Zendesk to Intercom data migration in 2026, start with the pre-migration audit. Export your full ticket manifest, count your custom fields, and resolve your duplicate contacts before you write a single import call. That investment of 3 to 5 days at the start of the project is worth more than any migration tool or service you could buy.