Migrate from Intercom to Zendesk

Intercom Contacts (Users) map directly to Zendesk End Users. Email, name, custom attributes, and created_at timestamps migrate 1:1. The intercom_user_id is preserved as a custom field zendesk_migration_source_id for audit and cross-referencing. Intercom Leads are treated as Contacts with a custom attribute lead_status__c to preserve source classification.

Intercom Companies map to Zendesk Organizations. The company domain becomes the Organization's domain field. We preserve the company-contact association so that all migrated End Users are linked to their parent Organization. plan and monthly_spend from Intercom migrate to custom fields on the Organization record.

Intercom Conversations map to Zendesk Tickets. Each conversation becomes a single Ticket with the conversation subject or first message body as the Ticket subject. Conversation state (open, closed, snoozed) maps to Zendesk Ticket status (open, pending, solved, closed). The original intercom_conversation_id is stored as a custom field for audit. Multiple Intercom conversations from the same Contact can optionally be merged into a single Zendesk Ticket using a conversation-grouping rule defined during scoping.

Intercom Conversation Parts (messages, notes, assignments, rating submissions) merge into a single Zendesk Ticket as sequential Comments. Message body, author (agent or contact), and timestamp are preserved. Internal notes in Intercom map to Zendesk internal Comments. Part type (comment, note, assignment, close, rating) is stored as a comment attribute. We use the Intercom retrieve-conversation endpoint to pull full transcript content because the S3 JSON export excludes message bodies.

Intercom Admins map to Zendesk Agents. We match by email address. Agent role (admin, agent, viewer) maps to Zendesk role. Intercom away/available states do not transfer; agents set availability in Zendesk on first login. We flag any Admin without a matching Zendesk User for the customer's admin to provision before the production migration phase.

Intercom Teams map to Zendesk Groups. Group membership migrates so that ticket routing rules defined in Zendesk reference the correct Groups. If Intercom's team-based routing is configured via Inbox rules, we document the routing logic for manual reconstruction in Zendesk Triggers or Automations.

Intercom Tags applied to Contacts and Conversations migrate as Zendesk Tags. Tags on Contacts become Tags on the mapped End User. Tags on Conversations become Tags on the mapped Ticket. Tag preservation maintains segmentation continuity for reporting and filtering.

Intercom Segments are dynamic rule-based audience definitions that recompute on access. These cannot migrate as live dynamic queries. We take a membership snapshot at migration time and create Zendesk Saved Searches (Zenhooks) or Views with equivalent filter criteria so that the same audience can be replicated. The customer reconciles dynamic recomputation post-migration.

Intercom Help Center Articles map to Zendesk Guide Articles. Title, body (HTML), author, publication state, and URL slug transfer. Intercom Collections decompose into Zendesk Sections, and Sections decompose into Categories. We flag any Article with translations to migrate as separate locale versions in Zendesk Guide. Article-specific public URLs do not transfer because Zendesk generates its own article slugs.

Intercom Data Attributes on Contacts and Companies require pre-creation as typed Custom Fields in Zendesk on User and Organization before data migration begins. We audit the full Intercom attribute list during scoping, define the Zendesk field types (text, dropdown, checkbox, date, number), and deploy the schema to Zendesk before any records move. Custom attributes on Conversations require pre-creation on the Ticket object.

Intercom's newer structured Ticket object (distinct from the Conversation-first model) maps to Zendesk Ticket with direct field-to-field mapping. Ticket type, status, priority, and custom ticket attributes transfer. If the team uses both Conversations and Tickets in Intercom, we map both to Zendesk Tickets and flag duplicates if a single customer issue appears in both objects.

Intercom Custom Objects (user-defined data structures with their own schema) migrate to Zendesk Custom Objects. We pre-create the destination object type and attributes in Zendesk Sunshine before migration, using Intercom's custom_object_instances API endpoints. Relationships between Custom Object Instances and Contacts or Companies migrate as Zendesk Custom Object record associations.