How to Migrate from Intercom (2026): A Practical Guide

This is a neutral, vendor-agnostic playbook for teams who've decided to migrate from Intercom — whether you're heading to Zendesk, Freshdesk, Help Scout, Gorgias, or anywhere else. We cover why teams are leaving (including the elephant in the room: the Salesforce acquisition), exactly what to carry over, how to export your Intercom data (the built-in export and the REST API, with their real limits), how to choose a destination, the three migration methods, a step-by-step plan, the pitfalls, and a pre/post checklist. Every Intercom capability below was verified via web research in June 2026 and cited; UIs and limits change, so confirm in your own workspace before you rely on them.

Why teams leave Intercom

Intercom is a genuinely strong product — best-in-class messenger, a mature inbox, and an AI agent (Fin) that many teams rate highly. But a few fair, recurring reasons push teams to move:

• Pricing that scales unpredictably. Intercom's blend of per-seat fees and usage-based AI resolution charges means the bill can climb in ways that are hard to forecast — especially once Fin is resolving at volume. For many teams, cost is the single biggest driver.
• The Salesforce acquisition. On June 15, 2026, Salesforce signed a definitive agreement to acquire Fin (the company formerly known as Intercom) for roughly $3.6 billion, with the product set to fold into Salesforce's Agentforce platform; the deal is expected to close in Q4 of Salesforce's fiscal 2027 (Salesforce press release, CNBC, TechCrunch). Acquisitions don't break a product overnight, but they do create real uncertainty about roadmap, pricing, and packaging — and that uncertainty is, for a lot of teams, a legitimate reason to evaluate alternatives now rather than later.
• A model mismatch for ticket-heavy support. Intercom is conversation-first. Teams that have grown into formal ticketing, SLAs, and queue-based workflows sometimes find a dedicated helpdesk a more natural fit.
• Channel or stack alignment. Ecommerce teams want order context in the ticket; teams standardizing on another ecosystem want their support tool to live there.

Pin down your real reason — it determines both your destination and whether a migration is even the right fix. If you're still shortlisting, our roundup of the best Intercom alternatives compares the main destinations with honest pricing and ratings.

What to migrate (your data inventory)

Before touching a tool, inventory what you're carrying. A migration is really three jobs wearing one name — records (data that can move), configuration (logic you rebuild), and the cutover (the operational switch). Most of the pain lives in the second and third.

Here's what to account for in Intercom specifically:

• Conversations and tickets — the full message thread (customer and teammate replies), notes, status, assignee, and the tags attached to each. Intercom's conversation transcript is the crown jewel here, and also the part the standard export handles least well (more below).
• Contacts (users and leads) and companies — your people and the organizations they belong to, including the custom attributes you've defined on each.
• Custom attributes — Intercom leans heavily on custom data attributes for both contacts and conversations. Catalog every one, its type, and where it's used; these have to be recreated as custom fields in the destination before you import.
• Help center articles — collections, articles, authors, and any translations / multilingual content.
• Tags — used for routing and reporting; map them deliberately rather than dragging across hundreds of stale ones.
• Teammates — who needs a seat in the destination and which teams/inboxes conversations route to. On most destinations, teammates and groups must exist before conversations import so assignments land correctly.
• Macros / saved replies, workflows, and SLAs — treat these as a rebuild spec, not as data that transfers.

A migration is the cheapest moment you'll ever get to prune. Leave behind dead attributes, unused saved replies, and ancient closed conversations you don't legally need. Don't faithfully reproduce a mess.

How to export your data from Intercom

Whether you feed a file into a native importer or let a service pull via API, you need to know how Intercom lets data out. There are two routes — and a crucial caveat that catches almost everyone.

Route A — The built-in data export (no code)

Intercom's exports live under Settings → Data → Imports & exports → Export data. The main paths:

• Conversations export to an AWS S3 or Google Cloud Storage bucket. You choose the Data API version and output format, run either a Historical export (up to roughly two years of data) or a Periodic export (hourly/daily for new and updated conversations), and toggle whether to include attachments (Intercom: export conversations data, export to cloud storage).
• Tickets have their own export flow (Intercom: export tickets data).
• Contacts (users/leads) and companies export to CSV — select the records, then More → Export, choosing displayed columns or all columns (Intercom: export users, leads, or company data).
• Reports → Dataset export produces CSVs of Conversations/Tickets datasets with a date range and column selection.

The caveat that matters most: the CSV Dataset export returns metadata only — IDs, timestamps, assignees, tags, SLA data, custom attributes — not the message bodies, transcripts, inline images, or attachments. And the S3/cloud conversation export, depending on configuration, may also omit the full transcript. In other words, the easy export gives you the shape of your conversations but not their content. To get true transcripts you either export individual conversations as text/PDF from the three-dot menu (full chronology with timestamps — fine for a handful, hopeless for thousands) or pull them via the REST API. Also note: browser conversation-data downloads are capped at 10,000 rows; larger exports are emailed to you and can take up to an hour.

Route B — The Intercom REST API (for bulk and transcripts)

For a programmatic pull — or to get the transcripts the CSV export leaves out — the Intercom REST API is the other route. A few real limits to plan around:

• Cursor-based pagination. Intercom uses starting_after cursors, not page numbers, with a default of 20 objects per page and a maximum of 150 via per_page (Tray.ai: Intercom API). For incremental/delta pulls, the Search endpoint lets you filter on updated_at so you fetch only recently changed conversations.
• The transcript / N+1 problem. Listing conversations returns summaries; fetching the full message parts (the actual transcript) often means a follow-up call per conversation. At scale that's a lot of requests and careful "stitching" of parts back into threads — a common place migrations slow down or drop data.
• Rate limits. Intercom slices each per-minute allowance into 10-second windows rather than letting you spend it all in one burst. The default limit is 1,000 calls/min — about 166 calls per 10-second window — while private and public apps are raised to 10,000 calls/min per app (~1,666 per 10s) and 25,000/min per workspace. Either way, a naive burst gets a 429 even under the per-minute ceiling (Intercom: rate limiting). Build in backoff.

For most teams, the API is something the migration service handles for you — which is the point of Route 3 below.

Choosing a destination

Where you land should follow your reason for leaving, not the other way around. The common Intercom destinations:

• Zendesk — the heavyweight ticketing platform: deep reporting, a huge app marketplace, mature SLAs and routing. Pricier, and its AI is billed separately. Best for teams that have outgrown Intercom's conversation-first model and want formal ticketing. We have a dedicated walkthrough for this path: how to migrate to Zendesk from Intercom.
• Freshdesk — strong value, solid ticketing, good for teams who want Zendesk-style structure at a lower entry price.
• Help Scout — simpler and more human-first; a natural fit for small/mid teams who liked Intercom's tone but not its bill.
• Gorgias — the ecommerce specialist; best if your support is mostly Shopify/DTC order questions.
• Zoho Desk, HubSpot Service Hub, Front and others fit narrower profiles (suite-unified, CRM-native, collaborative inbox).

Model the total cost at your real volume — base seats plus AI plus any channel fees — not the sticker price. Intercom's own pricing taught everyone that the headline number is rarely the final bill, and the same is true of every destination. For a side-by-side with ratings and honest watch-outs, see the best Intercom alternatives.

The three migration methods

However you export, the data gets into your destination one of three ways:

1. Native importers (CSV). Most destinations offer a free importer for contacts, companies, and sometimes help center content. Great for seeding people and accounts — but most native importers don't move full conversation history with transcripts. Good for part of the job, rarely the whole job.
2. The API. Destinations like Zendesk have a dedicated import API that preserves historical timestamps and won't fire automations on import. Paired with Intercom's REST API on the export side, it moves everything — but it's real engineering effort (cursor pagination, the transcript N+1 pattern, rate-limit backoff, thread stitching), and imported conversations often won't carry valid SLA/metric data. Worth it only with developer time and unusual requirements.
3. A third-party migration service. Tools like Help Desk Migration (Relokia) connect to Intercom and your destination via API and move the heavy stuff for you. Their Intercom support covers conversations/tickets, contacts, companies, help center articles (with inline images, links, and translations), tags, custom fields, and agent data, with a free demo run. The honest caveats: it's paid (priced by record volume), translation migration is only automated for some destinations (Zendesk, Freshdesk, Salesforce), and the business logic (workflows, SLAs, routing) still rebuilds by hand.

The short version: native tools move your people and KB; a service (or the API) moves your conversations with their transcripts. Almost every real migration combines them, with the heavy lifting on method 3.

A step-by-step migration plan

1. Audit and prune (in Intercom). Build the inventory above. Count conversations (open vs. closed), list every custom attribute and its type, catalog tags, and note your workflows/SLAs/saved replies as a rebuild spec. Drop anything dead.
2. Pick your destination and method. Match the destination to your real reason for leaving, then choose native importer + API, or a third-party service. For most teams it's a service for conversations plus a native importer for contacts/companies.
3. Set up the destination's foundations. Create teammates and groups, recreate your custom attributes as custom fields (with their types and dropdown values), and stand up ticket forms — before you import records that reference them.
4. Export and prep from Intercom. Run the conversation export (or let the service pull via API), export contacts/companies to CSV, and export the help center. Keep a copy as your reference of truth to verify against later — and confirm your conversation export actually contains transcripts, not just metadata.
5. Map your fields and structure. Account for vocabulary and structure differences — Intercom companies often become organizations, and Intercom's Collection → Article help-center hierarchy (where an article can live with no section) may need restructuring to fit a destination that expects three levels (e.g. Category → Section → Article). Build the mapping in a spreadsheet by hand, or use the service's guided wizard.
6. Run a demo/sample migration first. Move a small batch (~20 conversations) and inspect them in the destination: requester/assignee correct? Full transcript including teammate notes? Attachments and inline images present? Status and tags mapped right? Custom attribute values populated? Timestamps preserved? Fix mapping and re-run until the sample is clean.
7. Freeze, then run the full migration. Set a data-freeze timestamp in Intercom, communicate it to teammates, then launch the full run (hours to days by volume). Afterward, run a delta migration — Intercom's Search endpoint filtering on updated_at is built for exactly this — to catch anything created or changed since the freeze.
8. Rebuild what doesn't transfer. Recreate workflows, SLA policies, saved replies/macros, business hours, routing rules, and apps natively. This is the most-underestimated step — block real time for it, and treat it as a chance to improve, not just copy.
9. Redirect channels and retrain. Point email forwarding/MX, the messenger/web widget, and any chat/social channels at the new tool; send a real test message and confirm it creates a ticket. Give teammates a short orientation and a one-page cheat sheet.
10. Verify, then keep Intercom read-only. Spot-check conversation counts (your Intercom export total vs. destination), watch the first day of live tickets closely, and keep Intercom accessible read-only for a few weeks as a safety net before you decommission.

Common pitfalls

• The "empty transcript" trap. The single most common Intercom mistake: trusting the CSV/dataset export and discovering it has no message bodies. Verify transcripts in your sample before you commit.
• ID mapping. Conversation IDs won't match — the destination assigns its own, so external references to old Intercom IDs break. Store the original Intercom ID in a custom field during migration and keep your export as a lookup.
• Custom attributes. Intercom-heavy workspaces lean on custom attributes; if you don't recreate the field definitions first, those values land nowhere. Catalog them before you start.
• Help center hierarchy. Intercom's flatter Collection → Article model can collapse or mis-nest when forced into a three-level structure. Plan the mapping deliberately.
• Downtime and the freeze. Teammates quietly working conversations in Intercom after cutover strand those updates. Enforce the freeze and rely on the delta pass.
• Assuming logic transfers. Workflows, SLAs, saved replies, and business hours do not migrate on any method. Budget to rebuild them.

Where an AI layer fits (an honest aside)

A quick disclosure, because we make this: if your only reason to migrate was Fin's AI cost or behavior, switching helpdesks is a lot of pain to solve one line item — so it's worth naming what an AI layer can and can't do here.

Macha isn't an Intercom alternative and isn't a helpdesk — it's an AI agent layer that runs on top of a helpdesk. The honest, relevant caveat for this guide: Macha connects to Zendesk and Freshdesk only — it does not run on Intercom. So it isn't an option while you're on Intercom; it becomes relevant only if your destination is Zendesk or Freshdesk, where it can be the AI layer that rides on top after you land. It reads the customer's actual question, pulls from your connected data and help center, resolves routine tickets in-thread, and hands off to a human with context when it's not confident.

The honest watch-out: it's one more integration to configure, and it's only as good as the knowledge you point it at — one more reason to get the help-center step of your migration right. It bills per AI action (each step the agent takes — drafting, looking up an order, tagging, routing), not per resolution, because most of the work is the steps along the way and outcomes vary with your data quality. You can see how the layer works on a helpdesk, or 7-day free trial, no credit card required.

Pre- and post-migration checklist

Before you start

• [ ] Real reason for leaving named (and confirmed a migration is the right fix)
• [ ] Destination chosen and total cost modeled at real volume
• [ ] Full data inventory built; dead attributes/tags/conversations pruned
• [ ] Teammates, groups, and custom fields (from Intercom attributes) created in the destination
• [ ] Field + help-center hierarchy mapping documented (companies → organizations; Collection → Article → 3 levels)
• [ ] Workflows, SLAs, and saved replies documented as a rebuild spec
• [ ] Intercom export taken as a reference copy — transcripts confirmed present

After the migration

• [ ] Demo verified, then full run + delta completed
• [ ] Conversation counts reconciled (Intercom export vs. destination)
• [ ] Transcripts, teammate notes, attachments, timestamps, and custom values spot-checked
• [ ] Workflows, SLAs, saved replies, business hours, routing, and apps rebuilt and tested
• [ ] Channels (email/MX, messenger/widget, chat/social) redirected and tested live
• [ ] Teammates retrained; first day of live tickets monitored
• [ ] Intercom kept read-only for a grace period before decommissioning

Frequently asked questions

How do I export my data from Intercom? Use Settings → Data → Imports & exports → Export data. Conversations export to AWS S3 or Google Cloud Storage as Historical (~2 years) or Periodic jobs; contacts and companies export to CSV; the help center and tickets have their own flows. The big caveat: the CSV/Dataset export returns metadata only — no message bodies or transcripts — so for true transcripts you export individual conversations as text/PDF or pull them via the REST API (Intercom docs).

Can I migrate from Intercom for free? Partially. Native CSV importers on most destinations move contacts and companies for free, but they generally don't move full conversation history with transcripts. Full migration means either building against both APIs (engineering effort) or paying for a third-party service. For most teams the paid service is the realistic time-vs-money trade.

Should I migrate because of the Salesforce acquisition? Not automatically. Salesforce signed a definitive agreement to acquire Fin (formerly Intercom) for ~$3.6 billion on June 15, 2026, with the product folding into Agentforce and the deal expected to close in Q4 of Salesforce's FY2027 (Salesforce). That's a legitimate reason to evaluate alternatives — roadmap, pricing, and packaging can shift after an acquisition — but the product still works today. Decide on your own cost and fit, and use the uncertainty as a prompt to plan, not a reason to panic-migrate.

Will my Intercom transcripts and custom attributes come across? They can, but not via the easy CSV export — that's metadata only. Transcripts come from per-conversation text/PDF exports, the REST API, or a migration service that pulls them for you. Custom attributes must be recreated as custom fields in the destination before import, or their values land nowhere.

Will my workflows, SLAs, and saved replies transfer? Mostly no — plan to rebuild business logic natively in the destination. Some services migrate help-center content and basic structures, but workflows, SLA policies, business hours, routing, and apps rebuild manually on any method. Document everything in Intercom first so you have a spec.

Do I have to leave Intercom to get better AI? This one's different from most helpdesks: an external AI layer like Macha runs on Zendesk and Freshdesk, not on Intercom — so on Intercom your AI options are Fin or another Intercom-native add-on. If you do migrate to Zendesk or Freshdesk, Macha can be the AI layer on top there. If your problem is purely Intercom's pricing model, weigh that against the full cost of a migration before you move.

The bottom line

A clean Intercom migration comes down to sequence: audit and prune, choose a destination that fixes your real reason for leaving, export your data — remembering that Intercom's easy export gives you metadata, not transcripts, so plan the REST API or a service for the actual conversation content — pick a method (native importers for people/KB, a service or API for conversations), run a demo before the full run, freeze and delta-migrate, then rebuild the workflows, SLAs, and saved replies no tool transfers — and finish by redirecting channels, retraining teammates, and keeping Intercom read-only as a safety net. The Salesforce acquisition is a fair reason to evaluate now, but let cost and fit make the call. Still shortlisting? Start with the best Intercom alternatives, or if you've settled on Zendesk, the Intercom-to-Zendesk walkthrough.

Intercom export and API capabilities, third-party migration scopes, and the Salesforce/Fin acquisition were verified via web research, June 2026. Helpdesk capabilities, limits, pricing, and post-acquisition roadmaps in this category change fast — confirm current terms in your own Intercom workspace and on each vendor's site before you rely on them.