Helpdesk migration
Field-level mapping, validation, and rollback between Intercom and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
Intercom
Source
Gorgias
Destination
Compatibility
13 of 15
objects map 1:1 between Intercom and Gorgias.
Complexity
CModerate
Timeline
1-2 weeks
Try the reverse
Overview
Moving from Intercom to Gorgias is a shift from a conversation-centric to a ticket-centric support model. Intercom organizes around Contacts, Companies, and threaded Conversations with message Parts; Gorgias uses Customers, Tickets, and a unified inbox with deep Shopify integration for order-level ticket context. We resolve the conversation-to-ticket mapping during scoping, pull full message history via the Intercom REST API (bypassing the S3 export that deliberately omits transcripts), and preserve tag, team, and admin ownership across both platforms. Intercom Workflows, bots, and Outbound sequences do not migrate as code; we deliver a written inventory for the customer's admin to rebuild in Gorgias Macros and Rules. The Help Center article import uses Gorgias's native import path with appearance and custom scripts scoped separately.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Intercom platform overview
Scorecard, SWOT, gotchas, and pricing for Intercom.
Destination platform
Gorgias platform overview
Scorecard, SWOT, gotchas, and pricing for Gorgias.
Data migration guide
The complete Gorgias migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Source platform guide
Intercom migration guide
Understand the data you're exporting from Intercom before mapping it.
Destination checklist
Gorgias migration checklist
Pre- and post-cutover tasks for moving onto Gorgias.
Source checklist
Intercom migration checklist
Exit checklist for unwinding your Intercom setup cleanly.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Intercom object lands in Gorgias, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Intercom
Contact (User)
Gorgias
Customer
1:1Intercom Contacts (Users and Leads) migrate to Gorgias Customer records. Email, name, phone, language, timezone, and external_id map directly. Custom attributes on Contacts map to Gorgias Customer custom fields, which we pre-create in the destination workspace during schema setup. Intercom contact-type distinction (user vs lead) is preserved in a custom field ic_contact_type__c. The Gorgias API supports external_id for dedupe validation.
Intercom
Company
Gorgias
Customer (organization field)
1:1Intercom Companies link to Contacts and carry attributes (name, plan, monthly_spend, custom attributes). We map Company.name to the organization field on the Gorgias Customer record, preserving the company-contact association so agents see the customer's organization context in the Gorgias ticket view. Any Company-level custom attributes map to Customer custom fields with an ic_company_ prefix.
Intercom
Conversation
Gorgias
Ticket
1:1Intercom Conversations map to Gorgias Tickets. The Intercom conversation ID becomes the Gorgias external_id for reconciliation. Conversation status (open, closed, snoozed) maps to Gorgias ticket status with a custom field ic_conversation_state__c preserving the original state. Assignee, team, and tags carry across. Note that Gorgias splits any ticket with more than 250 comments into multiple closed tickets; we flag and document this during scoping for tickets exceeding the threshold.
Intercom
Conversation Part (message)
Gorgias
Ticket comment
1:1Intercom message Parts (body, attachments, delivery metadata) map to Gorgias Ticket comments in chronological order. We pull full message content via the Intercom REST API retrieve-conversation endpoint rather than the S3 JSON export, which deliberately omits transcripts. The author (customer or agent) maps to the Gorgias comment sender. Attachments migrate as files linked to the comment.
Intercom
Conversation Part (note)
Gorgias
Internal ticket note
1:1Intercom internal notes (Conversation Parts with part_type = note) map to Gorgias internal ticket notes. These are visible to agents but not to customers. We preserve the note body, author, and timestamp, and flag any redacted notes from the Intercom API that cannot be retrieved.
Intercom
Admin
Gorgias
Agent
1:1Intercom Admins migrate to Gorgias Agents. Role, avatar, and away/available state are preserved. We map admins by email match to the Gorgias user table. Any Intercom Admin without a matching Gorgias Agent is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Intercom admins migrate as inactive Gorgias agents to preserve assignment history.
Intercom
Team
Gorgias
Team
1:1Intercom Teams group Admins for routing and inbox assignment. Team membership and routing associations migrate 1:1 to Gorgias Teams. Team names, member lists, and the team-level inbox assignment rules are preserved to maintain escalation paths post-migration. We flag any routing rules that reference Intercom-specific conditions (e.g., Inbox routing) for manual rebuild in Gorgias Rules.
Intercom
Tag
Gorgias
Tag
1:1Intercom Tags migrate to Gorgias Tags. Tags applied to Conversations and Contacts carry across to the corresponding Gorgias Tickets and Customers. Tags are preserved as plain string labels; tag color and grouping metadata (if any) do not have a Gorgias equivalent and are documented in the scoping inventory. Tags used only on Contacts with no associated Conversations migrate as customer tags in Gorgias.
Intercom
Segment
Gorgias
Customer tag or list (snapshot)
lossyIntercom Segments are dynamic audience definitions recomputed from Contact attributes and behavior. Gorgias does not have dynamic Segments; the migration captures the membership snapshot at migration time and reapplies those customers as Gorgias customers tagged with the segment name. Dynamic recomputation post-migration is not available; we document the segment criteria in the scoping inventory for the admin to rebuild using Gorgias filters and customer attributes.
Intercom
Article (Help Center)
Gorgias
Help Center article
1:1Intercom Help Center Articles migrate to Gorgias Help Center articles using Gorgias's native Intercom import path (Settings > Channels > Help Center > Import from another provider). Published articles map to Gorgias Public status, private articles to Unlisted, and draft articles to Draft. Article body, title, author, and category assignments migrate. Appearance settings and custom scripts do not migrate and are documented separately for the admin to reconfigure. Multiple article collections map to Gorgias categories.
Intercom
Ticket
Gorgias
Ticket
1:1Intercom's structured Ticket object (distinct from Conversations) maps to Gorgias Tickets with its own set of fields, statuses, and custom attributes. Ticket status, priority, assignee, and custom ticket fields migrate. We note that Intercom Tickets are a more recent feature layer and may have limited data volume depending on how the workspace uses them versus the Conversation-first model.
Intercom
Custom Attribute (Contact)
Gorgias
Customer custom field
1:1Intercom custom attributes on Contacts map to Gorgias Customer custom fields. We audit all Intercom Data Attributes via the API during scoping, identify attribute types (string, number, boolean, date, list), and pre-create matching Gorgias custom fields on the Customer object before migration. The external_id on each custom field carries the original Intercom attribute name for audit traceability.
Intercom
Custom Attribute (Company)
Gorgias
Customer organization field or custom field
1:1Intercom custom attributes on Companies map to Gorgias Customer custom fields with an ic_company_ prefix to distinguish from Contact-level attributes. Organization name maps to the standard organization field on Customer. All other Company custom attributes (plan, monthly_spend, etc.) are preserved as Customer custom fields so the ecommerce context remains visible on the ticket.
Intercom
Custom Object Instance
Gorgias
Customer custom field or linked ticket note
lossyIntercom Custom Objects have user-defined schema and relationships with no direct Gorgias equivalent (Gorgias supports custom fields only on Ticket and Customer). For each Custom Object, we during scoping identify whether the data is customer-referenced or standalone. Customer-referenced instances are mapped to Customer custom fields or stored as structured JSON in a dedicated custom field. Standalone Custom Object data is documented in the scoping inventory as a candidate for a separate data store or a post-migration database integration. This is a high-scope item that requires per-object review during discovery.
Intercom
Conversation rating
Gorgias
Ticket satisfaction rating
1:1Intercom Conversation ratings (1-5 star or thumbs up/down) migrate to Gorgias ticket satisfaction ratings. The rating value, the rated-at timestamp, and the comment (if any) map to the Gorgias satisfaction fields. We note that Gorgias uses a different rating scale model (CSAT thumbs) from Intercom's star rating; we preserve the original value in a custom field ic_rating_value__c for historical reporting.
| Intercom | Gorgias | Compatibility | |
|---|---|---|---|
| Contact (User) | Customer1:1 | Fully supported | |
| Company | Customer (organization field)1:1 | Fully supported | |
| Conversation | Ticket1:1 | Fully supported | |
| Conversation Part (message) | Ticket comment1:1 | Fully supported | |
| Conversation Part (note) | Internal ticket note1:1 | Fully supported | |
| Admin | Agent1:1 | Fully supported | |
| Team | Team1:1 | Fully supported | |
| Tag | Tag1:1 | Fully supported | |
| Segment | Customer tag or list (snapshot)lossy | Fully supported | |
| Article (Help Center) | Help Center article1:1 | Fully supported | |
| Ticket | Ticket1:1 | Fully supported | |
| Custom Attribute (Contact) | Customer custom field1:1 | Fully supported | |
| Custom Attribute (Company) | Customer organization field or custom field1:1 | Fully supported | |
| Custom Object Instance | Customer custom field or linked ticket notelossy | Fully supported | |
| Conversation rating | Ticket satisfaction rating1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Intercom gotchas
S3 JSON export omits conversation transcripts
Workspace isolation prevents workflow migration
Fin AI resolution fees compound with automation success
Two-year conversation history limit on historical export
Private app rate limits share workspace quota
Gorgias gotchas
AI Agent adds outcome-based fees on top of billable ticket costs
Overage billing for tickets scales nonlinearly
API rate limits restrict bulk export throughput
Agent data visibility cannot be restricted by role for GDPR use cases
Knowledge Base translations require separate API calls per locale
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the source Intercom workspace across object volume (Contacts, Companies, Conversations, message Parts, Admins, Teams, Tags, Segments, Articles, Tickets, Custom Attributes, Custom Objects), workspace tier (Essential, Advanced, Expert), active bot and workflow count, and the two-year history window to determine how much conversation data falls outside the export cap. We pair this with a Gorgias plan assessment to determine whether Standard, Advanced, or Premium is appropriate for the customer's ecommerce support scope. The discovery output is a written migration scope document with record counts, a data gap report for conversations older than two years, and a Custom Object inventory with per-object mapping recommendations.
Schema design and field-level mapping
We design the destination schema in Gorgias. This includes provisioning Customer custom fields (typed to match Intercom attribute types: string, number, boolean, date, list), Ticket custom fields for Ticket-level Intercom attributes, and any company-attribute fields with an ic_company_ prefix. We pre-create Tags in Gorgias matching the Intercom tag list. For Articles, we configure the Help Center categories that correspond to Intercom collections before triggering the native import. Agent accounts are provisioned in Gorgias with matching email addresses before the migration phase begins.
Sandbox migration and reconciliation
We run a full migration into a Gorgias trial or staging environment using a representative data sample (all object types, at least 500 tickets, 50 customers, 5 agents) to validate field mappings, tag preservation, article import completeness, and Custom Object handling. The customer's support team lead spot-checks 25-50 random tickets against the Intercom source for content accuracy, conversation thread completeness (including message ordering and attachment presence), and tag application. Any mapping corrections are documented and applied before the production migration. This step also validates the conversation-split threshold for threads exceeding 250 comments.
Customer and organization import
We import Intercom Contacts and Companies in dependency order: Contacts first (with organization field linking to the Company), then Companies (for cross-reference validation). Custom attribute values carry into the pre-created Gorgias custom fields. Any Contacts without an associated Company are imported with the organization field blank. Tags on Contacts are applied post-import. The agent mapping is validated during this phase: every Intercom Admin referenced on a Contact must have a matching Gorgias Agent account or be placed in the reconciliation queue.
Ticket and conversation import
We import Intercom Conversations as Gorgias Tickets via the REST API. For each Conversation, we pull full message history via retrieve-conversation (bypassing the transcript-excluding S3 export), sequence the Parts chronologically, and write them as comments to the Gorgias Ticket. Internal notes map to internal ticket notes. Conversation assignee, team, and tags carry across. The Intercom conversation ID is stored as external_id on the Gorgias Ticket for reconciliation. Attachments are uploaded and linked to the corresponding comment. Tickets exceeding 250 comments are split per the threshold identified during scoping, with a cross-reference field linking the split tickets to the original conversation ID.
Agent reconciliation and team mapping
We match every distinct Intercom Admin by email against the Gorgias Agent table. Admins without a matching Gorgias Agent go to a reconciliation queue. The customer's Gorgias admin provisions any missing Agent accounts (active or inactive matching the original Intercom state). We then map Intercom Teams to Gorgias Teams, preserving member lists and team-level routing associations. Routing rules that reference Intercom-specific inbox logic are documented separately for manual rebuild in Gorgias Rules.
Cutover, Help Center import, and automation rebuild handoff
We freeze Intercom writes during cutover, run a final delta migration of any records modified during the migration window, then enable Gorgias as the system of record. We trigger the Help Center article import via Gorgias's native Intercom import path for articles and categories, noting that appearance and custom scripts require manual reconfiguration. We deliver the workflow and automation inventory document to the customer's admin team. We support a one-week hypercare window where we resolve any reconciliation issues. We do not rebuild Intercom workflows as Gorgias Macros or Rules inside the migration scope; that is a separate engagement.
Platform deep dives
Intercom
Source
Strengths
Weaknesses
Gorgias
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 5 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Intercom and Gorgias.
Object compatibility
5 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Intercom: 10,000 req/min per private app; 25,000 req/min per workspace (private apps share workspace quota).
Data volume sensitivity
Intercom doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Intercom to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your Intercom to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Intercom
Other ways to arrive at Gorgias
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.