Zoho Desk to Intercom Migration: The Complete Technical Guide

What Is a Zoho Desk to Intercom Migration?

A Zoho Desk to Intercom migration is the process of extracting tickets, conversation threads, contacts, accounts, knowledge base articles, tags, and custom field data from Zoho Desk's department-centric helpdesk and loading them into Intercom's contact-centric platform — mapping Zoho Desk Tickets to Intercom Tickets or Conversations, Zoho Desk Contacts to Intercom Contacts (Users or Leads), and Zoho Desk Accounts to Intercom Companies.

This is not a lift-and-shift. It is a data architecture translation. Every field, relationship, and timestamp must be deliberately mapped between two fundamentally different models. You also need to decide early whether historical Zoho Desk tickets should land as Intercom Conversations, Intercom Tickets (Customer, Back-office, or Tracker), or a mix. That decision changes your mapping, visibility rules, and API scripts — get it wrong and you are looking at a re-run.

Why Teams Move from Zoho Desk to Intercom

The most common triggers:

• Messenger-first engagement. Intercom's embedded Messenger enables proactive outreach, product tours, and in-app support — capabilities Zoho Desk lacks natively. Teams moving upmarket or adopting product-led growth choose Intercom for this.
• AI-native support with Fin. Intercom's Fin AI agent resolves customer questions using help center content. Zoho Desk's Zia assistant is comparatively limited in autonomous resolution.
• Unified customer communication. Intercom combines live chat, email, tickets, and knowledge base in a single workspace. Teams running Zoho Desk alongside separate live chat tools consolidate into Intercom.
• Custom object and workflow flexibility. Intercom's Custom Objects and Workflows engine supports complex routing and automation logic that Zoho Desk's Blueprint system handles differently.

Why This Migration Is Non-Trivial

Three architectural differences make this harder than it looks:

1. Zoho Desk is department-centric; Intercom is workspace-centric. Zoho Desk scopes tickets, agents, and views by Department. Intercom uses a flat workspace model with Teams for routing. There is no 1:1 department mapping — you must redesign your routing logic.
2. Zoho Desk separates Threads and Comments; Intercom uses Conversation Parts and Ticket Parts. Zoho Desk stores customer replies as Threads (typed: REPLY, FORWARD) and agent notes as Comments. Public and private comments are different behaviors. Intercom stores all interactions as conversation_parts or ticket_parts, each with a part_type of comment, note, or assignment. Intercom limits tickets to 500 parts.
3. Attachment handling diverges significantly. Zoho Desk stores attachments behind secure, expiring download links. Intercom requires attachment URLs for conversation replies but has limited direct attachment support for ticket creation via API. Files must be fetched, staged, and re-hosted.

For a deeper look at Intercom's architecture and how it compares to traditional ticket-based systems, see Zendesk to Intercom Migration: The 2026 Technical Guide.

Zoho Desk to Intercom: Core Object Mapping

Before writing any extraction scripts, map your source objects to their destination equivalents. The table below is the working map most teams need.

Field-Level Mapping Considerations

• Picklist/enum fields: Zoho Desk picklists must be created as Intercom list-type data attributes before import. Values must match exactly — mismatched values are silently dropped. Intercom list attributes take option IDs, not labels. Push the label string instead of the ID and the value disappears without an error.
• Date/DateTime fields: Zoho Desk exports dates in GMT. Intercom expects Unix timestamps (seconds). Conversion is required for every date field.
• Multi-select fields: Zoho Desk supports multi-select picklists. Intercom does not have a native multi-select attribute type. Flatten to a comma-separated string or split into multiple boolean attributes.
• Status mapping: Zoho Desk's status field (Open, On Hold, Escalated, Closed) maps to Intercom's ticket_state (submitted, waiting_on_customer, in_progress, resolved). This requires explicit mapping logic.
• Subject/description: When loading into Intercom Tickets, Zoho Desk subject maps to _default_title_ and description maps to _default_description_.
• Custom field limits: Intercom allows up to 250 custom data attributes per workspace. If your Zoho Desk instance has more custom fields than this across all modules, consolidate or archive rarely used fields before migration.

What Has No Clean Equivalent in Intercom

Zoho Desk Blueprints (visual process builders), Products (product-scoped ticket routing), Activities (Tasks, Calls, Events), Time Tracking entries, and the full ticket audit trail have no Intercom equivalent. Zoho Desk exposes detailed ticket history through GET /api/v1/tickets/{ticket_id}/History, including workflow, SLA, blueprint, and attachment events. (help.zoho.com) If those events matter for compliance or auditing, archive them separately or summarize them in imported notes.

The standard approach: archive Activities and time entries as reference data, store Product associations as tags or custom attributes, and rebuild Blueprint logic as Intercom Workflows post-migration.

How Do You Extract Data from Zoho Desk?

Zoho Desk offers three extraction paths, each with distinct limitations.

CSV Export (UI-based)

Zoho Desk allows users to export up to 50,000 records at once via the UI export feature. This export is department-specific and produces flat CSV files. It does not include ticket threads, comments, or attachments — only top-level ticket metadata. Date/time fields export in GMT. (help.zoho.com)

When to use it: Quick audits, contact lists, or lightweight migrations under 50K records where you do not need conversation history.

Limitations:

• No threads or conversation history
• No attachments
• Department-scoped (one export per department)
• 50,000 record cap per export

Data Backup (Full Export)

Zoho Desk's Data Backup feature provides a complete backup including email threads, attachments (as secure download links), contacts, products, KB articles, and more. The documented backup ceiling is 10 million records. (help.zoho.com)

Key constraints:

• Attachments in the backup are delivered as secure download links, not actual files. Download links expire after seven days. You need a separate API script to download the actual attachment files before those links expire.
• Only the primary contact on the Zoho Desk account can create and download backups.
• The backup cannot be scoped to specific modules — it exports everything.

When to use it: Full migration where you need threads and comment history but do not want to write extraction scripts from scratch.

REST API Extraction

The Zoho Desk API (/api/v1/tickets, /api/v1/contacts, /api/v1/tickets/{ticketId}/threads, etc.) gives you granular control over extraction. Pagination uses from and limit parameters. The ticket list endpoint supports limit=1..100, sortBy=createdTime|modifiedTime, and includes like products,departments,team,assignee.

Concurrency limits range from 5 (Free) to 25 (Enterprise), and concurrency is shared across all OAuth-authenticated integrations for the portal, not per token or per client.

Zoho Desk API credit system:

A GET /tickets call costs 3 credits. A GET /tickets/{id} call costs 1 credit. For an Enterprise org with 50 agents, that is 100,000 + (50 × 1,000) = 150,000 credits/day. Budget your extraction accordingly.

How Does Intercom's API Handle Inbound Data?

Private apps have a default rate limit of 10,000 API calls per minute per app and 25,000 API calls per minute per workspace. This means that if a workspace has multiple private apps installed, every one contributes towards total number of requests.

The rate limits are distributed into 10-second windows — effectively 1,667 requests per 10-second window. Burst above that and you get 429 Too Many Requests responses.

Key Intercom API endpoints for migration:

Search lag caveat: Intercom documents that a newly created contact may not be immediately searchable. Do not create a contact and immediately depend on POST /contacts/search to find it. Store the returned id from the creation response in your crosswalk table and use it directly.

Throughput Math [For Engineering]

The number of API calls per migrated ticket depends on ticket complexity. A simple ticket with 2 comments and a tag requires ~4 calls. A typical ticket with 5 comments, 2 attachments, and a tag requires ~9 calls. Complex tickets with long thread histories can require 15+ calls.

At 10,000 calls/minute:

Expect 30–50% lower throughput in practice due to error handling, retries, and dependency ordering. For most migrations, the bottleneck is Zoho Desk extraction (concurrency and credit limits), not Intercom loading.

How Do You Handle Attachments and Knowledge Base Articles?

Attachment handling is the single most failure-prone part of this migration.

Zoho Desk Attachment Extraction

Zoho Desk's Data Backup provides secure download links for attachments — not the files themselves. These links expire after seven days. Your script must:

1. Parse the backup for attachment URLs (or use GET /api/v1/tickets/{ticketId}/attachments for per-ticket extraction)
2. Download each file via authenticated API calls before the links expire
3. Store files in intermediate storage (S3, GCS, or local disk)

Each download consumes API credits from your daily pool.

Loading Attachments into Intercom

Intercom's attachment handling is more restrictive than most helpdesks:

• Conversation replies support attachment_urls — an array of publicly accessible URLs that Intercom fetches and hosts.
• Ticket creation via API has limited direct attachment support. Currently, it is not possible to add attachments to a ticket via the API. The feature is under consideration by the Product Team. For now, you need to host files in a content management system and store the URL in a custom attribute.
• The expiry time for customer uploads is 30 minutes. This expiry affects any external system that stores or references the attachment URL.
• Intercom has a 20MB size limit for an email and its attachments. Files exceeding this must be hosted externally and linked.

Practical workaround for ticket attachments:

1. Upload Zoho Desk attachment files to persistent cloud storage (S3, GCS) with public or signed URLs
2. Reference these URLs in ticket part bodies as inline links
3. For conversation-based migrations, use the attachment_urls field in reply payloads

Knowledge Base Article Migration

Migrating Zoho Desk KB articles to Intercom Help Center requires:

1. Creating Intercom Collections and Sections to mirror your Zoho Desk category structure
2. Extracting article HTML content via the Zoho Desk API (GET /api/v1/articles)
3. Downloading every inline image from Zoho Desk's servers and uploading to persistent hosting. Intercom does not support direct uploads of files; instead, you must provide a URL to the file in your API request. Intercom pulls images from those URLs and rewrites them to Intercom-hosted links.
4. Sanitizing the HTML — Intercom's Help Center does not support forms, iframes, or arbitrary custom HTML (intercom.com)
5. Creating articles via POST /articles with the updated HTML body, a collection_id, and an author_id

Migration Approaches: Which Method Fits Your Team?

Quick Decision Guide

• < 5K tickets, no conversation history needed: CSV export + manual Intercom setup
• 5K–50K tickets, standard fields: Third-party tool or integration platform
• 50K–500K+ tickets, custom fields, attachments, full history: Custom API scripts or managed service
• Ongoing sync required: Integration platform with webhook triggers
• Zero-downtime, enterprise compliance: Managed migration service

If you are evaluating DIY vs. third-party options, read our guide on what happens when a help desk data migration fails.

Step-by-Step Zoho Desk to Intercom Migration Process

The order of operations matters. Loading records out of sequence creates broken relationships and orphaned data.

Step 1: Choose the Target Model

Decide early whether each Zoho Desk ticket becomes an Intercom Conversation, a Ticket (Customer, Back-office, or Tracker), or a mix. This decision affects your mapping, visibility rules, and API scripts. Mixed models are valid but multiply scripts and QA effort.

Visibility matters here: Intercom Customer tickets are always shared with customers. Back-office tickets are internal by default but can be shared. Tracker tickets are never shared. (intercom.com) A wrong choice between note, comment, and customer ticket is a trust problem, not just a data problem.

Step 2: Prepare Intercom Workspace

Before loading any data:

1. Create Ticket Types and their custom attributes in Intercom
2. Create Data Attributes for contacts and companies to mirror Zoho Desk custom fields
3. Set up Help Center Collections and Sections for KB article structure
4. Invite all agents as Admins in Intercom — they must exist before you can assign tickets
5. Create Teams to approximate Zoho Desk Department routing

Step 3: Extract and Transform

Use Zoho Desk Data Backup for the full historical set, then REST API endpoints for recent changes and lookup enrichment.

# Pseudocode: Extract tickets with threads from Zoho Desk
import requests
import time
 
ZOHO_BASE = "https://desk.zoho.com/api/v1"
HEADERS = {"orgId": "YOUR_ORG_ID", "Authorization": "Zoho-oauthtoken YOUR_TOKEN"}
 
def extract_tickets(from_index=0, limit=100):
    resp = requests.get(
        f"{ZOHO_BASE}/tickets",
        headers=HEADERS,
        params={"from": from_index, "limit": limit, "include": "contacts,departments,team"}
    )
    if resp.status_code == 429:
        retry_after = int(resp.headers.get("Retry-After", 60))
        time.sleep(retry_after)
        return extract_tickets(from_index, limit)
    return resp.json().get("data", [])
 
def extract_threads(ticket_id):
    resp = requests.get(
        f"{ZOHO_BASE}/tickets/{ticket_id}/threads",
        headers=HEADERS,
        params={"limit": 100}
    )
    return resp.json().get("data", [])

Transform before loading:

• Convert Zoho Desk date formats (GMT) to Unix timestamps
• Map status values (Open → submitted, Closed → resolved, On Hold → waiting_on_customer, Escalated → in_progress)
• Flatten multi-select picklists to comma-separated strings
• De-duplicate contacts by email address
• Map picklist values to Intercom list attribute option IDs (not labels)

Step 4: Re-host Attachments and KB Media

Download every secure Zoho Desk attachment URL and stage KB images at publicly accessible URLs. This step prevents broken files and broken article images after import. Checksum each downloaded file so you can verify integrity later.

For KB articles, rewrite all <img src="..."> URLs in the HTML to point to the re-hosted copies. Intercom will pull images from those URLs and rewrite them to Intercom-hosted links during article creation.

Step 5: Load in Dependency Order

This order prevents broken references:

1. Companies → POST /companies (use company_id for idempotent creates)
2. Contacts → POST /contacts (link to companies, store returned Intercom IDs in your crosswalk table)
3. Tickets → POST /tickets (reference contact via returned id, set created_at, set skip_notifications: true)
4. Ticket Parts → POST /tickets/{id}/reply (add threads and comments as parts, oldest to newest, preserving created_at on each)
5. Tags → POST /tickets/{id}/tags
6. Articles → POST /articles (after collections/sections exist)

# Pseudocode: Create ticket in Intercom with historical timestamp
import requests
import time
 
INTERCOM_BASE = "https://api.intercom.io"
INTERCOM_HEADERS = {
    "Authorization": "Bearer YOUR_ACCESS_TOKEN",
    "Content-Type": "application/json",
    "Intercom-Version": "2.15"
}
 
def create_ticket(ticket_type_id, contact_id, title, description, created_at_unix):
    payload = {
        "ticket_type_id": ticket_type_id,
        "contacts": [{"id": contact_id}],
        "created_at": created_at_unix,
        "skip_notifications": True,
        "ticket_attributes": {
            "_default_title_": title,
            "_default_description_": description
        }
    }
    resp = requests.post(
        f"{INTERCOM_BASE}/tickets",
        headers=INTERCOM_HEADERS,
        json=payload
    )
    if resp.status_code == 429:
        time.sleep(10)  # Respect 10-second window
        return create_ticket(ticket_type_id, contact_id, title, description, created_at_unix)
    resp.raise_for_status()
    return resp.json()

Step 6: Validate

Run record-count reconciliation immediately after loading. See the Validation section below.

Step 7: Delta Sync and Cutover

Run a final sync to capture tickets created during the migration window. Switch email routing and live chat to Intercom. Keep Zoho Desk in read-only mode for 30+ days as a rollback option.

For cutover mechanics, see Zero-Downtime Help Desk Data Migration.

How Long Does a Zoho Desk to Intercom Migration Take? [For PMs]

Timeline depends on ticket volume, attachment complexity, and custom field depth.

One easy-to-miss dependency: only the primary contact on the Zoho Desk account can create and download full backups. Confirm who has this access before scheduling extraction.

Phased vs. Big-Bang vs. Incremental

• Big-bang: Migrate everything over a weekend. Works for sub-100K datasets with a clear cutover window. Risk: if validation fails, rollback means reverting to Zoho Desk.
• Phased: Migrate contacts and companies first, then historical tickets, then switch live traffic. Lower risk, longer timeline.
• Incremental: Run both systems in parallel with delta syncs. Best for zero-downtime requirements but requires continuous sync infrastructure.

Intercom's own migration guidance recommends planning a first migration run followed by a formal cutover plus delta run, which keeps support live while recent tickets continue changing. (intercom.com)

Risk Register

What Do Customers Notice During Migration? [For Customer Success]

If executed correctly, customers notice the new Messenger UI and potentially a brief gap in ticket continuity during cutover. What they should not notice is missing history or exposed internal notes.

What changes for customers:

• Historical conversations appear under their contact record in Intercom (if migrated correctly)
• Ticket numbers change — Zoho Desk ticket IDs do not carry over. Store the original Zoho Desk ticket ID in a custom attribute for cross-reference.
• CSAT ratings from Zoho Desk are not natively migrated — store as custom attributes for reporting continuity
• SLA clocks reset — Intercom's SLA engine starts fresh on migrated tickets

Visibility is a trust problem, not just a data problem. In Intercom, Customer tickets are always shared with customers, Back-office tickets are internal by default but can be shared, and Tracker tickets are never shared. A bad company mapping or a wrong choice between note/comment/customer ticket can expose internal agent chatter to end-users. Validate visibility rules aggressively before go-live.

Change management checklist:

1. Notify customers 1–2 weeks before cutover about the new support channel
2. Set up email forwarding from old Zoho Desk addresses to Intercom
3. Brief agents on Intercom's Inbox, Ticket, and Conversation workflows
4. Prepare a support script explaining where old conversations now live
5. Monitor first-response and resolution times daily for the first 30 days

What Data Cannot Be Migrated from Zoho Desk to Intercom?

Be honest with stakeholders about what does not transfer:

• Blueprints and workflow automations. Must be rebuilt as Intercom Workflows from scratch. Document your current automation logic before migration.
• SLA policies and SLA history. Intercom's SLA model is different. Historical SLA compliance data does not migrate.
• Time tracking entries. Intercom has no time tracking. Archive for reference.
• Products. No Intercom equivalent. Convert to tags or custom attributes.
• Activities (Tasks, Calls, Events). Archive or convert to contact notes.
• Audit logs and ticket history events. Zoho Desk exposes detailed history via its History API (workflow, SLA, blueprint, comment, and attachment events). Export for compliance archives; Intercom's audit trail starts fresh.
• Agent productivity metrics. Zoho Desk analytics do not transfer. Export historical reports before decommissioning.
• Multi-department scoping. Intercom's workspace model does not replicate Zoho Desk's department-level data isolation.
• Macros and assignment rules. Must be manually recreated as Intercom Macros and Assignment Rules.

Edge Cases and Known Limitations

Duplicate contacts. Zoho Desk allows multiple contacts with the same email across different departments. Intercom enforces unique emails per contact. De-duplicate before import or the API will reject entries.

Thread ordering. Zoho Desk threads have a direction field (in, out) and explicit timestamps. When loading into Intercom as ticket parts, preserve the created_at timestamp on each reply to maintain chronological order.

Inline images in ticket bodies. Zoho Desk stores inline images as embedded references. These URLs break after migration. Extract every inline image URL from thread HTML, re-host the file, and replace the URL in the HTML body before loading into Intercom.

Conversation creation HTML limitation. The Intercom create-conversation payload does not support HTML. Sanitize the opening message if you are loading into Conversations rather than Tickets.

500-part limit. Intercom limits tickets to 500 parts. Zoho Desk tickets with more than 500 thread entries and comments combined will be truncated. This is rare but possible for long-running enterprise tickets. Split oversized tickets or archive older parts as a note summary.

Enum mismatches. Intercom list attributes take option IDs, not labels. Push the label string and the value is silently dropped — no error, no warning.

Missing companies. Intercom companies are only visible once at least one associated user exists. Load contacts and link them to companies in the same step to avoid invisible company records.

Search lag. Newly created contacts in Intercom may not be immediately searchable. Merged contacts are excluded from search results. Always store the returned Intercom id from the creation response rather than relying on search. (developers.intercom.com)

Spam and suspended tickets. Filter out spam or suspended tickets in Zoho Desk during the extraction phase. Importing them clutters your Intercom workspace and wastes API calls.

Zoho Desk attachment size. Zoho Desk's API allows attachments up to 20 MB per file. Intercom has a 20MB size limit for an email and its attachments. Files exceeding this must be hosted externally and linked.

Validation and Testing

Record-Count Reconciliation

After every migration run, compare counts:

Field-Level Spot Checks

Sample 2–5% of migrated records across each object type:

• Verify custom field values populated correctly (especially picklists and dates)
• Confirm ticket status mapping (Open → submitted, Closed → resolved)
• Check that conversation/ticket thread order is chronological
• Validate attachment URLs resolve without requiring a Zoho Desk login — click-test 20–30 attachments
• Verify contact-to-company associations
• Confirm the original requester is correctly linked to each ticket
• Check that created_at timestamps match the original Zoho Desk ticket creation dates

UAT Protocol

1. Have 2–3 agents work in Intercom for a full day on migrated tickets
2. Agents verify: Can they find historical customer context? Are notes and internal comments visible only to agents? Do linked articles render correctly?
3. Log every discrepancy. Categorize as critical (data loss, visibility breach), major (wrong assignment), or minor (formatting)
4. Gate go-live on zero critical issues

For a comprehensive post-migration testing framework, see Post-Migration QA: 20 Tests to Run After Your Help Desk Data Migration.

Rollback Plan

Before cutover:

• Keep Zoho Desk active and accessible for a minimum of 30 days post-migration
• Do not delete any Zoho Desk data until validation is complete
• Maintain your source-to-target ID crosswalk and exported attachment files
• If Intercom data is corrupt, your rollback is: revert MX/email routing to Zoho Desk, clear the Intercom workspace, fix scripts, re-run

Should You Build In-House or Use a Managed Service?

When In-House Makes Sense

• Under 30K tickets with minimal custom fields
• You have a backend developer who can commit 2–3 weeks
• Attachments are minimal or not required
• You are comfortable managing API rate limits, error handling, and retry logic
• Timeline is flexible — you can absorb a re-migration if the first attempt has issues

When In-House Gets Expensive

The hidden cost of DIY is not the initial build — it is the second and third migration attempts. Common failure modes:

• Broken thread ordering — tickets with out-of-order conversations that confuse agents
• Missing attachments — secure download links expire before files are fetched
• Rate limit cascading — unhandled 429 responses corrupt partial records
• Duplicate contacts — email matching edge cases create fragmented customer profiles
• Visibility errors — internal notes exposed to customers, or enum values silently dropped because labels were used instead of IDs

Each failed migration attempt costs 1–2 weeks of engineering time plus the operational disruption of agents working with incomplete data.

Where a Managed Service Removes Risk

A managed migration service handles the extraction, transformation, rate limit management, attachment re-hosting, and validation — including the delta sync that captures tickets created during the migration window.

ClonePartner has completed over 1,500 helpdesk migrations, including complex Zoho Desk extractions with full thread history preservation, attachment handling, and custom field mapping. Our platform automatically handles Zoho Desk's secure attachment URLs, respects Intercom's 10-second interval limits, and guarantees data fidelity without pulling your engineers off product work.

For teams where migration accuracy is non-negotiable and engineering bandwidth is limited, that track record matters. If a previous DIY attempt has left you with broken data, see Help Desk Data Migration Failed? The Engineer's Rescue Guide.