Gorgias to Intercom Migration Guide (2026)

A Gorgias-to-Intercom migration is a double paradigm shift: you're simultaneously leaving an e-commerce-native helpdesk (with deep Shopify actions, macro variables, and revenue tracking) and moving into a messenger-first customer data platform. This guide covers the exact object mapping, API constraints, rate limit math, Shopify integration gap, macro rewrite strategy, email channel cutover, Intercom plan tier requirements, Fin AI configuration, and every decision point you'll hit along the way.

For the strategic case behind the move, see Why Smart Teams are Choosing Intercom. For the reverse direction, see How to Migrate from Intercom to Zendesk.

Why Teams Migrate from Gorgias to Intercom

Teams initiate this move when they're evolving beyond transactional D2C support — WISMO tickets and refund requests — toward relationship-driven customer engagement. The specific triggers:

• Fin AI agent for automated resolution — an LLM-powered agent that understands natural language, far more capable than Gorgias's rule-based autoresponders. Well-configured Fin deployments with high-quality knowledge bases typically target 25–40% autonomous resolution within the first 90 days.
• Intercom Messenger for in-product communication, onboarding flows, product tours, and rich message types (carousels, buttons, forms)
• Proactive messaging for customer lifecycle engagement — outbound messages triggered by behavior, not just support requests
• Unified CDP — a single customer view across support, marketing, and product, with roles (user/lead), company associations, custom events, and segments
• Workflows — visual, multi-step automations with branching, Fin AI integration, and custom actions that far exceed Gorgias's rules engine
• Scaling beyond e-commerce — teams adding B2B, SaaS, or multi-product support alongside D2C

The trade-off is real: Gorgias gives agents native Shopify order data, in-ticket refund actions, e-commerce macro variables, and revenue attribution. None of these exist natively in Intercom. The migration plan must address each gap explicitly.

Cost considerations

Intercom's per-seat pricing is typically 2–5x higher than Gorgias. A 20-agent Gorgias team on their Advanced plan (~$60/seat/month + usage) will likely pay $79–$135/seat/month on Intercom (Advanced or Expert tier), plus Fin AI resolution-based pricing ($0.99/resolution as of mid-2026). Factor in the Intercom plan tier required to replicate Gorgias capabilities — see the plan tier mapping below — before committing.

Intercom plan tier mapping for Gorgias feature parity

Budget the Intercom plan that covers your must-have Gorgias features. Teams that only need Messenger + Fin AI may operate on Advanced; teams with complex routing and multi-brand setups typically require Expert. (intercom.com)

Gorgias to Intercom Object & Field Mapping

Every Gorgias object maps to an Intercom equivalent, but the data models differ significantly.

• Gorgias Tickets → Intercom Conversations AND/OR Intercom Tickets. Intercom has two distinct objects: Conversations (real-time, messenger-style) and Tickets (tracked, async issues with status fields and a required ticket_type_id). Each Gorgias ticket must be routed to one during migration. See the Tickets-vs-Conversations routing decision tree below. (developers.intercom.com)
• Gorgias Ticket Messages → Intercom Conversation Parts. Each message becomes a conversation part with correct author attribution (admin vs. contact), public/private flag (comment for replies, note for internal notes), and HTML body. The opening conversation body does not support HTML — sanitize first-message content instead of copying raw Gorgias HTML. Subsequent replies and notes support some HTML. Intercom caps conversations at 500 parts; tickets with extremely long message threads must be truncated or split. (developers.intercom.com)
• Gorgias Internal Notes → Intercom Conversation Parts with type = "note". Direct mapping.
• Gorgias Customers → Intercom Contacts (role = "user" for known customers, role = "lead" for anonymous visitors). Core fields (name, email, phone) map directly. E-commerce data (order history, LTV, Shopify customer ID) must be stored in Intercom custom attributes — Intercom has no native fields for these. Contacts are unique by external_id or email. Standardize on a stable external ID early: Intercom CSV imports that contain both email and user_id can create duplicates if the existing record has no user_id. (intercom.com)
• Gorgias Customer Notes → Intercom Contact Notes. Direct mapping.
• Gorgias Companies → Intercom Companies. Intercom's model is richer (monthly_spend, plan, user_count, segments). Map core data; leave Intercom-native fields for future population. Intercom's CSV import does not support company data — use the API. Company records only become visible in Intercom once they have at least one associated user. (intercom.com)
• Gorgias Tags → Intercom Tags. Intercom maintains separate namespaces for conversation and contact tags. Gorgias tag names are case-sensitive — normalize before import.
• Gorgias Custom Fields → Intercom Custom Attributes. Type matching is required: Gorgias text → Intercom string, Gorgias dropdown → Intercom list with pre-defined values. Intercom conversation data attributes support Text, List, Number, Decimal Number, Boolean, Date & Time, Reference, and File Upload. List options can be bulk-loaded up to 1,000, and the combined conversation/ticket attribute limit is 5,000 per workspace. (developers.gorgias.com)
• Gorgias Views → Intercom Inbox Views. Must be recreated manually.
• Gorgias Teams → Intercom Teams. Direct conceptual mapping.
• Gorgias Agents → Intercom Admins/Teammates. Profiles recreated manually. Gorgias Lite Agents have no direct Intercom equivalent — assign Intercom seats with restricted permissions or manage access via team-level inbox visibility.
• Gorgias Rules → Intercom Workflows. Must be manually rebuilt — this is a redesign, not a 1:1 copy. Workflows require Intercom Advanced or Expert tier.
• Gorgias Macros → Intercom Macros. See the macro rewrite section below.
• Gorgias Help Center → Intercom Articles. Intercom's collection/section/article hierarchy is richer. Articles directly power Fin AI, making this migration more impactful than in other helpdesk moves.
• Gorgias Chat Widget → Intercom Messenger. A capability upgrade.
• Gorgias Satisfaction Surveys → Intercom CSAT. Configuration must be recreated. Historical CSAT scores can be stored as custom attributes on migrated conversations but won't appear in native reporting.

What has no clean equivalent: Gorgias revenue statistics, macro e-commerce variables ({{last_order.tracking_url}}), Gorgias Convert (in-chat sales campaigns), proactive chat campaigns with e-commerce triggers (cart value, checkout page), the Lite Agent role, and e-commerce stack integration configs (Recharge, Loop Returns, Klaviyo, Yotpo) which must be reconfigured via Intercom's App Store or custom integrations.

Tickets-vs-Conversations routing decision tree

This is a first-class migration decision. Use this framework:

For each Gorgias ticket, evaluate:

1. Is this a real-time, back-and-forth exchange (chat, Messenger)?
   → Import as Intercom Conversation

2. Is this a tracked, async issue with defined resolution stages
   (bug report, return request, escalation)?
   → Import as Intercom Ticket (requires ticket_type_id)

3. Is this a simple email inquiry (WISMO, product question)?
   → Import as Intercom Conversation (default)

4. Does your team need post-migration reporting by ticket type?
   → Import as Intercom Tickets with ticket_type_id mapped
     from Gorgias tags or custom fields

5. Unsure or mixed?
   → Default to Conversation. Intercom Conversations can be
     converted to Tickets post-import; the reverse is not possible.

Recommendation for most teams: Import all historical Gorgias tickets as Intercom Conversations for simplicity and speed; reserve Intercom Tickets for net-new tracked issues post-migration. If you need a split, route by Gorgias channel, tag, or custom field value during the transform step. The split adds complexity to the ETL pipeline (two different API endpoints, two different payload schemas) — only do it if you have a specific reporting or workflow requirement.

The tag normalization decision

Gorgias auto-generates intent and sentiment tags on every ticket. Importing all of them into Intercom creates significant tag bloat. Decide per project: preserve them with a prefix (e.g., gorgias_intent_wismo) for historical analysis, or discard to keep the Intercom tag namespace clean.

Migration Approaches for Gorgias to Intercom

CSV is not the migration. For Gorgias-to-Intercom, CSV handles contacts and archives; API work handles real history.

• CSV Export + Intercom CSV Import — Complexity: Low. Gorgias can export up to 1 million tickets from a view, but its message-content CSV is limited to the most recent 30 days and 100,000 tickets, includes public messages only, and prints timestamps in the exporter's timezone. Intercom's CSV tool imports users or leads and custom user attributes, has a 20 MB file limit, and does not import company data or conversation history. Useful only as a supplementary method for contact seeding. (docs.gorgias.com)

• API-Based Migration — Complexity: High. The only method that preserves full conversation history with message threading and timestamps. Gorgias API uses cursor-based pagination (GET /api/tickets, GET /api/tickets/{id}/messages). Intercom's POST /conversations endpoint accepts a created_at timestamp for historical imports. The compound rate limit problem (Gorgias extraction at ~2–4 req/s AND Intercom load at up to 10,000 req/min) means the data transfer phase runs as a multi-day background job. (developers.gorgias.com)

• Clean-Break Migration — Complexity: Low. Export Gorgias data as an archive, set up Intercom from scratch, import only contacts. Keep Gorgias in read-only mode for 6–12 months for rare lookups. This approach is more common for Gorgias → Intercom than for other helpdesk migrations because the platform shift is so fundamental that many teams treat it as a fresh start. In Intercom's own historical-migration guidance, the first planning question is why you need the old data at all. (intercom.com)

• Hybrid: Contacts via CSV + History via API — Complexity: Medium. Import contacts via CSV (fast, handles dedup), then import conversation history via API. Pragmatic middle ground for mid-size migrations.

• Managed Migration Service — A provider handles extraction, mapping, transformation, loading, the timestamp challenge, and the Tickets-vs-Conversations routing decision. Best for >50K tickets, complex macro libraries, or limited engineering bandwidth.

Which approach fits?

• Small team (<5 agents, <10K tickets): Clean-break or hybrid
• Mid-market (20–50 agents, 100K+ tickets) needing preserved history: API-based or managed service
• Low engineering bandwidth: Managed service
• Moving primarily for Fin AI: Clean-break — invest time in building great Articles instead of importing old tickets
• Moving primarily for CDP/Messenger: API-based with full history if agents need historical context

For general principles on what data to migrate vs. leave behind, see Help Desk Data Migration Playbook.

Migration Architecture: Overcoming the Compound Rate Limit

The extraction bottleneck is Gorgias, not Intercom. Gorgias enforces a leaky bucket rate limit of 40 requests per 20-second window for API key auth, or 80 requests per 20 seconds for OAuth2 — effectively 2–4 requests per second. This is a per-account limit, not per-key, meaning your migration script competes with every other integration running on the same Gorgias account. (developers.gorgias.com)

Intercom's API allows 10,000 calls per minute per private app (and 25,000 per workspace total), distributed across 10-second windows. The Intercom side is rarely the bottleneck.

Throughput math

For a ticket with 8 messages, extraction requires ~2 Gorgias API calls (ticket list page + messages fetch). At 4 req/s (OAuth2), that's ~120 tickets/min extraction rate. On the Intercom side, the same ticket requires 1 conversation create + 7 reply/note adds = 8 API calls. At 10,000 req/min, you can theoretically load ~1,250 conversations/min — but Gorgias extraction will only feed ~120/min.

For 100K tickets: extraction alone takes ~14 hours of continuous runtime. With message pagination, retries, attachment downloads, and a typical retry rate of 3–8% on Gorgias 429 responses, plan for 5–10 days of combined extraction + load time running 16 hours/day.

Rate limiter implementation

Standard retry-on-429 is not sufficient for Gorgias. The leaky bucket requires proactive rate limiting, not reactive. Build a token-bucket or fixed-delay rate limiter that spaces requests evenly. Read the X-Gorgias-Account-Api-Call-Limit response header to track your current bucket level.

import time
import requests
 
class GorgiasRateLimiter:
    def __init__(self, requests_per_window=80, window_seconds=20):
        self.delay = window_seconds / requests_per_window  # 0.25s for OAuth2
        self.last_request = 0
 
    def wait(self):
        elapsed = time.time() - self.last_request
        if elapsed < self.delay:
            time.sleep(self.delay - elapsed)
        self.last_request = time.time()
 
limiter = GorgiasRateLimiter()
 
def fetch_ticket_messages(base_url, ticket_id, auth):
    limiter.wait()
    resp = requests.get(f"{base_url}/api/tickets/{ticket_id}/messages", auth=auth)
    if resp.status_code == 429:
        retry_after = int(resp.headers.get("Retry-After", 5))
        time.sleep(retry_after)
        return fetch_ticket_messages(base_url, ticket_id, auth)
    return resp.json()

If you're authenticating with OAuth2 for a long-running migration, the access token expires (Gorgias OAuth2 tokens have a limited lifespan — verify the current expiry in their developer docs, as it may differ from the standard 24-hour window). Build token refresh logic into your pipeline. (developers.gorgias.com)

Critical order of operations

1. Create Intercom custom attributes (typed) before any data references them
2. Import contacts and companies first — conversations require a valid contact_id and admin_id
3. Run the timestamp test (10–50 conversations in sandbox)
4. Import conversations with parts, applying the Tickets-vs-Conversations routing decision
5. Upload attachments (download from Gorgias first — hosted URLs will expire after account closure)
6. Apply tags
7. Migrate FAQ articles to Intercom Articles
8. Configure email channel (DNS, SPF, DKIM — see email cutover section)
9. Enable and test Fin AI on migrated articles

For zero-downtime strategies during the migration, see Zero-Downtime Help Desk Data Migration.

Email Channel DNS & Forwarding Cutover

Email channel migration is a go-live blocker that requires DNS changes and careful timing. Gorgias handles inbound email by either forwarding or direct connection. Intercom requires its own email configuration.

Steps to cut over email

1. Inventory your support email addresses. List every address connected to Gorgias (e.g., support@, help@, returns@). Note whether each uses email forwarding to Gorgias or a direct IMAP/SMTP connection.

2. Set up email channels in Intercom. In Settings → Channels → Email, add each support address. Intercom will provide specific DNS records to configure.

3. Update DNS records:

   • Add Intercom's SPF record (typically an include: directive for Intercom's mail servers) to your domain's existing SPF record. Do not create a second SPF record — merge includes.
   • Add the DKIM record (a CNAME or TXT record provided by Intercom) for email authentication.
   • If using a custom sending domain, add the custom domain verification CNAME.
   • If using forwarding, update your mail server's forwarding rules to point to Intercom's inbound address instead of Gorgias's.

4. Verify in Intercom. Intercom's email setup validates SPF/DKIM. Send test emails to confirm delivery and correct threading.

5. Remove Gorgias email configuration. After verification, disable email forwarding to Gorgias and remove any Gorgias-specific DNS entries. Timing: do this at go-live, not before.

Common pitfall: If you forward to both Gorgias and Intercom during a parallel-run period, you'll create duplicate tickets in both systems. Use a hard cutover for email — switch forwarding at a defined time, not gradually.

DNS propagation: Allow 24–48 hours for DNS changes to propagate. Schedule DNS updates 48 hours before your planned go-live date and verify with dig or an online DNS checker.

What Happens to My Shopify Integration When I Switch?

This is the #1 concern for e-commerce teams. The honest answer: the gap has narrowed significantly since earlier migration guides were written.

As of mid-2026, Intercom's Shopify integration includes order management directly in the Inbox — agents can view customer and order data, show tracking links, edit shipping addresses, create and duplicate orders, process full refunds, and cancel orders from the conversation sidebar without leaving Intercom. Multi-store support is live. Fin AI can resolve order queries using real-time Shopify data via Data Connector templates. (intercom.com)

What agents keep:

• Customer data sync (Shopify customer data flows into Intercom contacts)
• Order data visibility in the conversation sidebar
• Full order refunds in one click
• Shipping address editing
• Order cancellation and duplication
• Order lookup exposed inside Messenger for shoppers

What still requires workarounds:

• Partial refunds: Intercom's refund flow is full-refund only as of this writing. Partial refunds are in development.
• Macro variables with order data: Gorgias macros like {{last_order.tracking_url}} have no direct Intercom equivalent. Agents reference order data from the sidebar, or you build Workflow custom actions to fetch and populate order data into conversation custom attributes.
• Revenue attribution: No native Intercom equivalent. Must be replaced with custom event-based tracking (send order.completed events to Intercom via API with order value as metadata) or accepted as a lost metric.
• Proactive chat campaigns with Shopify triggers: Gorgias triggers messages based on cart value or checkout page. Intercom supports URL-based and event-based targeting, but Shopify-specific events (cart update, checkout initiation) must be sent to Intercom as custom events via Shopify webhooks → your backend → Intercom Events API.

Third-party e-commerce integration status

Plan 1–2 weeks for third-party integration reconfiguration if you rely on more than two of these.

How to Rewrite Gorgias Macros for Intercom

Intercom's macro feature has evolved significantly. As of 2026, Intercom macros can trigger multiple actions — tagging, assigning, snoozing, or closing — and can be organized into folders. If you're working from an older guide that describes Intercom Saved Replies as text-only, re-check the current feature set before planning your rewrite. (intercom.com)

Audit every Gorgias macro and classify it:

• Type A — Text-only or action-only macros (no e-commerce variables): Migrate directly to Intercom macros. Map Gorgias variables to Intercom equivalents: {{customer.first_name}} → {{first_name}}, {{ticket.id}} → {{conversation.id}}. Macros that set tags, assign teams, or change statuses can be recreated as multi-action Intercom macros.

• Type B — Macros with e-commerce variables ({{last_order.name}}, {{last_order.tracking_url}}): These break in Intercom. Intercom variables are oriented around contact, company, and custom attribute data — not Shopify store data. Options: (1) Rewrite as static text with instructions for agents to copy order data from the Shopify sidebar. (2) Build a Workflow custom action that fetches order data from Shopify and populates conversation custom attributes, then reference those attributes in the macro. Option 2 is most scalable but requires development.

For a typical Gorgias e-commerce team, 30–50% of macros use e-commerce variables. Only the remainder are direct Type A migrations. (docs.gorgias.com)

Caveats to watch:

• Each Intercom macro can belong to only one folder
• Intercom macro search matches titles only, not body content — use naming conventions like [Shipping] Tracking update or [Returns] Full refund approved (intercom.com)

For more on automations and macro migration strategy, see Your Help Desk Data Migration's Secret Saboteur: Automations, Macros, and Workflows.

How to Rebuild Gorgias Rules as Intercom Workflows

Gorgias rules are simple and linear. Intercom Workflows are visual, multi-step, and event-driven. Most teams have 10–30 rules. The rebuild is a redesign, not a 1:1 copy:

• Auto-assignment rules → Intercom Workflows with assignment actions or native round-robin
• Auto-tag rules → Workflows that add tags based on message content or conversation attributes
• Auto-close rules → Workflows with time-based conditions
• Auto-reply / autoresponders → The biggest redesign opportunity. Gorgias autoresponders match intent and send canned replies. In Intercom, Fin AI replaces this: Fin reads the customer's message, searches Articles, and either resolves autonomously or hands off to a human. For WISMO autoresponders that send tracking info, build a Workflow custom action that fetches order data from Shopify via API. More powerful, but requires more setup.
• SLA-related rules → Intercom SLAs (configurable in Inbox settings, available on Advanced+)

If you plan to use Fin over both email and chat, split the Workflows — Intercom documents channel-specific workflow limits.

Timeline estimate: Rule audit and Workflow build takes 1–2 weeks for 10–30 rules. Autoresponder redesign with Fin AI setup adds 1–2 weeks.

How to Migrate Gorgias FAQ to Intercom Articles and Configure Fin AI

This step dictates the success of your Fin AI deployment. Fin relies on Intercom Articles (plus PDFs, webpages, and internal content) to resolve customer queries. The quality of your help center content directly determines Fin's autonomous resolution rate. (intercom.com)

Gorgias FAQs are typically flat and minimal. Intercom Articles use a Collection > Section > Article hierarchy. For small libraries (<30 articles), manual rewrite is often faster and produces better AI answers than automated migration. Rewrite each article for Fin's consumption: clear question-and-answer formatting, self-contained answers, no ambiguity.

For larger libraries, export from Gorgias, import programmatically via Intercom's Articles API, then rewrite the top-traffic articles into self-contained Q&A pages.

For e-commerce use cases, Fin for Ecommerce requires a Shopify integration — WISMO, returns, and order-status automation get better only after both the knowledge base and Shopify data layer are ready.

Fin AI configuration post-migration

After articles are imported and reviewed, configure Fin systematically. This is not a "turn it on and walk away" step:

1. Set Fin's persona and tone. Intercom allows you to define Fin's name, tone (professional, friendly, etc.), and length preference for responses.

2. Configure custom answers. For questions where your articles don't cover the exact answer, create custom Fin answers — these are explicit question-answer pairs that override article-based responses. Prioritize your top 20 ticket topics from Gorgias analytics.

3. Set confidence thresholds. Fin can be configured to only auto-resolve when confidence is high. Start conservative — set to "only when very confident" for the first 2 weeks, then relax as you review Fin's performance.

4. Define excluded topics. Identify categories where Fin should never auto-resolve and always hand off to a human: billing disputes, legal questions, safety issues, VIP customers, or complex multi-order returns.

5. Configure handoff rules. Define what happens when Fin can't resolve: assign to a specific team, add a tag, set priority, or route based on conversation attributes.

6. Channel-specific behavior. Fin can behave differently on Messenger (chat) vs. email. On chat, Fin responds in real-time. On email, Fin can draft responses for agent review instead of auto-sending. Configure per channel based on your risk tolerance.

7. Enable Fin Attributes. Fin can auto-classify conversations for issue type, sentiment, and urgency — these replace Gorgias's auto-generated intent/sentiment tags with Intercom-native equivalents.

8. Monitor and iterate. Track Fin's resolution rate, handoff rate, and customer satisfaction weekly for the first month. Target: 20–30% autonomous resolution in month 1, 30–45% by month 3 with article improvements.

This is the single highest-ROI activity in the entire migration for teams moving to Intercom for AI capabilities.

Multi-Brand and Multi-Language Considerations

E-commerce teams on Gorgias frequently run multiple Shopify stores or support multiple languages. These scenarios require explicit planning:

Multi-brand / multi-store

• Gorgias model: Multiple integrations within a single account, with views and rules filtered by integration/store.
• Intercom model: Each Intercom workspace is a single brand. Multi-brand support requires either (a) a single workspace with tags/attributes to distinguish brands and team-based routing, or (b) separate workspaces per brand (available on Expert tier with multi-workspace management).
• Recommendation: For 2–3 stores with shared agents, use a single workspace with brand-specific tags, custom attributes, and inbox views. For 4+ stores with distinct agent teams, evaluate separate workspaces. Intercom's Shopify app supports multi-store connections within a single workspace.

Multi-language

• Gorgias model: Language detection with auto-routing rules. Macros and articles are typically maintained in separate languages manually.
• Intercom model: Intercom Articles support multi-language versions natively — each article can have translated variants. Fin AI can respond in 45+ languages using your articles as a source. Messenger language auto-detection routes customers to the correct language version.
• Migration step: For each Gorgias FAQ article that exists in multiple languages, create the primary article in Intercom, then add translated versions. Fin AI will serve the correct language automatically.

How Long Does a Gorgias to Intercom Migration Take?

Realistic timeline for a mid-market team (20 agents, 100K tickets, 50 macros, 20 rules):

• Discovery & planning (1–2 weeks): Audit Gorgias data, classify macros, test Intercom API timestamp behavior, make the history-import vs. clean-break decision, define custom attribute mapping, evaluate Intercom Shopify app, select Intercom plan tier
• Intercom workspace setup (1–2 weeks, parallel): Custom attributes, teams, channels, Shopify app, Inbox views
• Email channel DNS cutover prep (parallel): SPF/DKIM records, forwarding configuration, verification
• Macro rewrite + Rule → Workflow build (1–2 weeks, parallel)
• Contact/company migration (1–3 days)
• Conversation history import (5–15 days): The longest phase, bottlenecked by Gorgias rate limits
• FAQ → Articles migration + Fin AI configuration (1–2 weeks, parallel)
• Agent training (3–5 days, parallel): See change management section below
• Validation & UAT (1 week)
• Go-live & monitoring (1–2 weeks)

Total: 4–8 weeks. Clean-break migrations compress this to 2–4 weeks by eliminating the history import phase.

Risk register

Rollback plan

If the migration fails mid-stream or agent adoption craters post-go-live:

1. Keep Gorgias active in read-only mode for 8–12 weeks minimum. Do not close the account at go-live.
2. Email rollback: If email deliverability fails, revert DNS forwarding rules to Gorgias within 24–48 hours (DNS propagation delay applies).
3. Chat rollback: Swap the Intercom Messenger snippet back to the Gorgias chat widget in your storefront code. This takes minutes.
4. Data rollback: Intercom conversations created during the failed migration can be bulk-archived or deleted. Contacts persist but don't cause harm.
5. Decision point: If Fin AI resolution rate is unacceptable after 30 days, the issue is almost always article quality, not the migration. Invest in content before rolling back.
6. Full rollback timeline: A complete reversion to Gorgias can be executed in 1–3 days if Gorgias remains active.

Agent Training and Change Management

A Gorgias-to-Intercom migration is not just a data move — it's a fundamental interface and workflow change. Agents accustomed to Gorgias's ticket-centric, e-commerce-native interface will encounter a messenger-first paradigm with different navigation, different keyboard shortcuts, and a different mental model for customer interactions.

Structured training plan

1. Week -1 (before go-live): 2-hour group session covering Intercom Inbox layout, conversation vs. ticket model, macro usage, Shopify sidebar, and Fin AI behavior. Record the session for reference.
2. Day 1–2: Pair each agent with a buddy who's completed the training. Shadow sessions where agents handle real conversations with backup.
3. Day 3–5: Independent usage with a dedicated Slack channel or Teams chat for real-time questions.
4. Week 2: 30-minute group retrospective. Identify friction points, missing macros, Shopify workflow gaps.
5. Ongoing: Appoint 2–3 "Intercom champions" from the agent team who become internal experts and first-line troubleshooters.

Key differences agents must internalize

What Happens to Customers During Migration?

If channels cut over at go-live, email customers see minimal change (assuming DNS is configured correctly — verify SPF/DKIM alignment to avoid spam folder issues). Chat customers will see the Intercom Messenger replace the Gorgias widget — the Messenger is highly visible, offering rich message types and persistent conversation history.

If Fin AI is enabled at launch, customers interact with an AI agent before reaching a human. Start Fin in suggest mode initially — let it recommend articles without auto-resolving until you've confirmed article quality supports full autonomy. Customers notice the Messenger change first, not the database move.

Reporting Parity: What Changes

Gorgias and Intercom measure support performance differently. Plan for reporting gaps:

Action item: Before migration, screenshot or export every Gorgias dashboard and report your team actively uses. Identify which metrics are available natively in Intercom, which require custom reports, and which require an external BI tool (e.g., Looker, Metabase connected via Intercom's data export or API).

Edge Cases and Known Challenges

• Duplicate customers: Gorgias allows duplicate customers by email across different channels. Intercom contacts are unique by external_id or email. Deduplicate before import.
• Conversation part limit: Intercom caps at 500 parts per conversation. Gorgias tickets with extremely long message threads must be truncated or split.
• Gorgias system messages ("Rule X applied," "Ticket merged"): Decide per type — import as internal note parts (preserving audit trails but adding noise) or discard.
• Attachment expiry: Gorgias-hosted attachment URLs may become inaccessible after account closure. Download all attachments during extraction and re-upload to Intercom.
• Contact role assignment: All Gorgias customers who have placed orders should be imported as Intercom contacts with role = "user", not "lead". This affects segmentation and targeting.
• Account-wide rate limit sharing: Gorgias rate limits are per-account, not per-key. Your migration script shares the budget with every other live integration on the same account. Consider temporarily disabling non-critical integrations during the extraction window.
• Social conversation history: Facebook/Instagram tickets migrated from Gorgias appear as standard Intercom conversations — they won't reconnect to original social threads.
• Deprecated endpoints: Gorgias's per-ticket messages endpoint has been marked deprecated in their docs. Verify the current message-listing flow before building extraction logic. (developers.gorgias.com)
• Attachment limits per call: If a single message has more than 10 attachments, split across API calls — both conversation creation and reply APIs cap attachment payloads per request.
• Company CSV limitation: Intercom's CSV import does not support company data. Any hybrid migration plan must use the API for companies. (intercom.com)

What Can't Be Migrated from Gorgias to Intercom

Be prepared to lose or replace:

• Revenue statistics — No native Intercom equivalent. Must be replaced with custom event-based attribution via Intercom's Events API or external BI.
• Macro e-commerce variables — Intercom macros can't pull Shopify data natively. Requires Workflow custom actions or manual agent steps.
• Gorgias Convert (in-chat sales campaigns) — No Intercom equivalent. Intercom's outbound messaging serves a different purpose (engagement, not transactional selling).
• Intent/sentiment detection model — Gorgias's AI model doesn't transfer. Fin AI uses its own understanding; Fin Attributes can auto-classify conversations for issue type, sentiment, and urgency.
• E-commerce stack configs (Recharge, Loop Returns, Klaviyo, Yotpo) — Must be reconfigured. See the third-party integration table above.
• Analytics dashboards — Must be rebuilt in Intercom Reports. See reporting parity section.
• Historical CSAT scores — Can be stored as custom attributes but won't appear in native reporting.
• Proactive chat campaigns with cart/checkout triggers — Must be rebuilt using Intercom custom events driven by Shopify webhooks.
• Lite Agent permissions model — No direct equivalent in Intercom's seat-based model.

Validation & Testing After Migration

Run strict QA before fully cutting over:

1. Record reconciliation: Compare Gorgias export counts against Intercom API totals for contacts, companies, conversations, messages, and attachments. Document discrepancies and root causes.
2. Timestamp verification: Confirm imported conversations display original Gorgias dates, not import dates. Spot-check at least 20 conversations across different date ranges.
3. Author attribution: Verify customer messages map to contacts and agent replies map to admins. Check at least 5 conversations per agent.
4. First-message rendering: Spot-check that the opening message of imported conversations renders correctly after HTML stripping.
5. Shopify app validation: Confirm agents can view order data in the sidebar for migrated contacts. Test with 3–5 real customer profiles.
6. Email deliverability: Send test emails from external accounts to every support address. Verify they arrive in Intercom Inbox, not spam. Check SPF/DKIM alignment with email header analysis.
7. Macro testing: Verify rebuilt macros work against real Shopify scenarios. Test all Type B rewrites specifically.
8. Fin AI testing: Submit the 10 most common WISMO, refund, and product queries to verify Fin's resolution accuracy against migrated articles. Document resolution rate vs. handoff rate.
9. Workflow testing: Trigger each rebuilt Workflow with a test conversation. Verify assignment, tagging, SLA, and Fin AI handoff behavior.
10. Agent UAT: Have 2–3 agents work in Intercom Inbox for 1–2 days before full cutover. Collect structured feedback on missing macros, Shopify workflow gaps, and interface friction.

Keep Gorgias in read-only mode for 8–12 weeks as a fallback reference.

Should You Migrate In-House or Use a Service?

In-house works when: small volume (<10K tickets), simple macros, few rules, the team is comfortable with a clean-break approach, and the primary goal is Messenger + Fin AI adoption.

In-house struggles when: large history must be preserved, macros depend on e-commerce variables, there's heavy reliance on Gorgias's native Shopify actions, autoresponders use order-data-dependent replies, the timeline is tight, or email channel cutover requires coordination across multiple domains. The compound complexity — Shopify gap + Tickets-vs-Conversations routing + macro rewrite + rate limit engineering + DNS cutover — makes this one of the harder helpdesk migration paths.

Hidden costs of DIY: The timestamp test alone can consume 1–2 weeks of engineering time. Building a production-grade token-bucket rate limiter for Gorgias's leaky bucket API takes additional effort. Discovering that the Shopify integration gap creates agent adoption resistance after go-live is the most expensive failure mode. Email deliverability issues post-cutover can impact customer experience for days if DNS is misconfigured.

ClonePartner has completed 1,500+ data migrations across helpdesk, CRM, HRIS, and ATS platforms. For Gorgias-to-Intercom, the service handles conversation history import (including timestamp preservation testing and Tickets-vs-Conversations routing), customer and tag migration with deduplication, custom attribute creation with type matching, knowledge base migration to Intercom Articles, and advisory on the Shopify integration gap and Fin AI setup strategy.