How to Migrate from Intercom: 7-Step Procedure (2026)

To migrate from Intercom, you (1) inventory and map what you have; (2) export what your destination won't import, such as CSAT scores, survey responses and custom fields; (3) set up the new platform in parallel on test channels; (4) pilot a low-risk slice of traffic for one to two weeks; (5) import your history; (6) cut over, either hard on one date or gradually over two to four weeks; and (7) verify everything, then freeze Intercom to read-only. The import is usually the easy part. Most of the risk sits in your own setup, so migrate less than you have, export before you leave, and pick the cutover your volume can absorb. Plain is the agentic infrastructure for customer work. It's a B2B customer support platform (help desk) with a built-in Intercom importer, and this guide uses it as the destination while flagging the Intercom-side steps that apply whichever tool you move to.

How long does an Intercom migration take, and what are the steps?

Plan on two to six weeks of calendar time after setup: a one-to-two-week pilot, then a hard cutover in one week or a gradual one over two to four weeks. Here is the procedure, with a check for each step so you know when to move on.

1. Inventory and map. Done when every object in Intercom has a named destination or a decision to drop it.

2. Export what won't import. Done when CSAT, survey data and custom fields are archived outside Intercom.

3. Set up in parallel. Done when channels, Tiers, SLAs, labels and snippets exist on test traffic and a pilot crew is invited.

4. Pilot. Done when one Tier, channel or segment has run on the new platform for one to two weeks and the checklist in Step 4 passes.

5. Import history. Done when the importer has finished and spot-checks match what you see in Intercom.

6. Cut over. Done when all production traffic lands in the new platform, either on one date or over two to four weeks.

7. Verify and decommission. Done when Intercom is read-only, zaps are repointed, and the Messenger is gone.

Only some steps have fixed durations. The pilot and cutover windows come from Plain's guide to migrating from another support tool. A hard cutover suits teams whose volume can absorb a learning curve in one week. A large history takes time to import, so start the import well before your cutover date rather than on it.

Don't benchmark against the fastest story you can find. Tinybird moved to Plain in 2 days and cut enterprise resolution time from 6 days to 2 hours, with SLA visibility across Slack Connect, community Slack and email (Tinybird case study). That move was from JIRA, not from Intercom, so treat two days as a best case, not as what leaving Intercom typically takes.

The questions buyers bring about migrating are consistent across the B2B support teams we speak with: history, importers, knowledge base, downtime and training. Step 5 covers history and importers, Step 3 covers the knowledge base and training, and Step 6 covers downtime.

One timing check before you start: find your Intercom contract end date and work backwards from it. Put the cutover at least a gradual-cutover window before the end date, the pilot before that, and the inventory first.

Step 1: What should you inventory and map before you leave Intercom?

Inventory every category below, give each item a destination or a decision to drop it, and expect to drop a lot. Most migration risk is about your setup, not the tool you're leaving.

Walk through Intercom and write down what you find in each category:

• Statuses and tags. Count them. Mark which ones you've used in the last quarter.

• Custom fields. List each one and what decision it drives. These do not import, so you need to know what they meant.

• CSAT and survey data. Note how far back you need it. It does not import.

• Help center articles. Count them and note which are out of date. They move through a separate help center migration.

• Workflows and automations. List every rule and what triggers it.

• Third-party zaps and integrations. Anything that reads from or writes to Intercom will break at cutover.

• Companies. Plain's importer docs list contacts, admins and conversations, not Intercom companies, so decide how each company maps onto Plain's Tenant object and confirm the approach with Plain before you import.

• Teams and groups. Note what each group routes.

• Macros. Mark which ones were used this year.

• SLAs and business hours. Record the targets per customer segment.

• Teammate accounts. List who needs to reply to customers and who only needs to read.

• Fin. Note whether you run Intercom's Fin agent. You'll rebuild its knowledge as a knowledge source for the Customer Agent (formerly Ari) rather than import it.

Many teams arrive with more than 20 statuses and more than 50 tags. Plain has seven statuses on purpose. Tiers, Threads and Tenants don't map like for like with other platforms, so don't replicate your old setup one to one; use the migration to delete what you no longer need. Tinybird's approach is the model here: the team migrated only what was still active, keeping their setup lean (Tinybird case study).

Two checks belong in this step. First, compliance: list Plain as a new sub-processor and send whatever GDPR or customer notifications your contracts require, before any customer data moves. Second, data residency: Intercom's Data Export API reference lists separate EU (api.eu.intercom.io) and Australian (api.au.intercom.io) API servers alongside the production server. If you're on regional hosting, confirm which server your exports and scripts call before you run anything.

Step 2: How do you export data from Intercom before you switch?

Export the things that won't import, and keep an archive of the rest. With Plain, the importer connects to Intercom directly, so you don't need export files to move conversations. You still need exports for CSAT scores, survey responses and comments, and custom fields, because none of those carry over.

Intercom documents several export paths, each with a different scope and limit. Every row below is sourced to Intercom's own help and developer pages as of October 2026.

Watch the last row. The endpoint is named "Data Export," but it doesn't export conversations. Don't rely on it for history. Intercom's export article also says the "Export API allows exports for a maximum 90-day timeframe per request"; in Intercom's API reference, that 90-day range belongs to the Data Export endpoint, not to the Conversations API.

Which method for what:

• Full conversation content: the Conversations API. Intercom's cloud-storage article says each exported JSON object holds the entire conversation with all its parts, but its export article says S3 exports "will not contain a transcript," so open a sample file before you rely on it for history.

• Reporting history: the Dataset CSV.

• Contact list: the Contacts CSV.

• A single record: the individual export.

• Download immediately. The Contacts CSV link expires after one hour, so run it when someone is at a keyboard.

Step 3: How do you set up the new platform in parallel?

Connect test channels, define Tiers and SLAs, and invite a small pilot crew before any production traffic moves. This is Phase 1 of Plain's migration guide. Use a test email address or a non-customer Slack channel, not production traffic. Email, Slack and chat flow into one place; Microsoft Teams needs Horizon or Frontier. Then define Tiers, business hours and SLAs, create your first labels and snippets, and invite the pilot crew.

Rebuild rather than import these:

1. Workflows and automations. They rarely translate cleanly, and Plain workflows are usually simpler. Rebuild the rules you still need and delete the rest.

2. Macros. Rebuild as snippets, starting with the ones used this year.

3. SLAs and business hours. Set per Tier.

4. Teams and groups. Map onto labels, Tiers and workflows rather than a team hierarchy.

5. Teammate accounts. Invite teammates fresh and assign Plain's roles.

6. Custom fields. Carry their meaning through labels or Tiers.

7. Help center articles. Plain's help center migration takes Markdown or HTML, either through the upsertHelpCenterArticle GraphQL mutation or a ready-made import script you can request from Plain's support team.

8. Zaps and integrations that point at Intercom. Rebuild or repoint each one now, before cutover, so nothing writes to an empty workspace later.

If you're replacing an AI agent, the knowledge it answered from is the thing to rebuild. Load your knowledge base as a knowledge source for the Customer Agent. It answers from your knowledge sources and past threads, and hands off to your team when it is unsure. Run it in test mode on pilot threads, where it works without permission to send to customers, then switch its workflows from Test to Live one at a time (Customer Agent docs).

A few plan facts bear on setup. Business hours and SLAs are Horizon features; Horizon is $99 per user per month billed annually, with a minimum of 3 and up to 10 seats, so it starts at $297 a month. Foundation is $45 per user per month billed annually, for up to 5 seats. Viewer seats are free and unlimited on every plan, which matters during training when stakeholders need read-only access. The Customer Agent is charged per resolution: each thread it resolves uses 100 credits from the plan's monthly allowance, which is 1,000 credits on Foundation and 2,500 on Horizon with annual billing.

Define SLAs per Tier before the pilot, or the pilot can't tell you whether you're meeting them. Buildkite is an example of tiered targets: its premium customers expect sub-10-minute response times, and Plain lets the team measure against a 5-minute internal response goal for them (Buildkite case study).

Training follows the same shape as traffic. Run it on the pilot crew first, let them find the gaps, then widen it to the full team once the setup has settled.

You can do all of Step 3 on test channels before paying anything: start a 7-day free trial, no credit card required.

Step 4: How do you run a pilot without moving production traffic?

Route a low-risk slice of traffic to Plain for one to two weeks while everyone else stays in Intercom. One Tier, one channel or one customer segment is enough.

Check these before you call the pilot done:

• Workflows behave as expected on live threads, not just test ones.

• Auto-triage labels and routing are tuned so the pilot crew isn't reassigning by hand.

• Day-one integrations are decided. Know which ones you need at cutover and which can wait until week four.

• The pilot crew can work the queue with seven statuses, without asking for the old ones back.

Write your exit criteria before the pilot starts, and decide in advance whether a clean pilot earns a hard cutover or a gradual one in Step 6.

Step 5: How do you import your Intercom history into Plain?

Run the importer from inside Plain, then let its hourly sync carry new records until cutover. Go to Settings → Integrations → Intercom (see Plain's Intercom importer docs), follow the prompts to connect your Intercom account, then start the import.

What comes across:

• Contacts become Customers. If a customer already exists in Plain, imported threads attach to them, so you don't get duplicates.

• Admins become Users.

• Conversations become Threads. All historical chat and email, with Intercom shown as the source channel and a direct link to the original conversation.

• Attachments come over with their messages.

• The Intercom assignee becomes the thread assignee, so queues arrive already owned.

• Priority conversations arrive as Urgent; everything else arrives as Normal.

• Original timestamps are kept on every thread and message.

• Snoozed conversations arrive as Todo, so look for them there rather than in Snoozed.

• Open conversations keep their response state: waiting on your first reply, waiting on your next reply, or Investigating where your team replied last.

Imports are non-destructive, so Intercom keeps its data. Importing does not trigger SLAs, auto-responses or workflows. Nothing goes out to customers, and no SLA clocks start on old tickets. Plain stores imported threads alongside live ones, attributed to the correct Customer and Tenant.

After the first import, new contacts, admins and conversations sync from Intercom into Plain every hour, per the importer docs (the sync shipped in the Intercom importer changelog, 2025-04-02). That covers what migration services sell as a delta migration. One limit matters for Step 6: changes to conversations that already came across, such as a new status or assignee, do not sync after the initial import.

Keeping history is not only for reference. Plain AI uses imported threads as context for suggested responses (a Horizon feature) and similar threads, so the answers your team gave in Intercom inform what it sees in Plain.

Expect a large history to take time, and start the import before cutover so it's in place when the first live thread lands. Sourcegraph's scale is a reference point for what a full move can involve: the team migrated 26,000 tickets from their ticketing tool, brought roughly 100 Slack channels into Plain, and had email and Slack running within days (Sourcegraph case study). The page doesn't name the tool they left, and your import time depends on your own history, so use it for scope rather than as a benchmark.

What if the importer doesn't cover something you need?

Send it through the API. Plain is API-first, so anything the importer doesn't carry can go in through the API. That covers data from a custom export, a second tool you're consolidating, or records you pulled through Intercom's Conversations API or cloud-storage export in Step 2. You can import threads through Plain's GraphQL API with your own script, mapping the fields you care about.

This is an option, not a promise. How much of your custom data maps onto Plain's objects depends on what you exported and how you shape it, so run a small batch first the way you'd test any import. The developer platform includes the API, webhooks, events and MCP, plus custom channels on Frontier, and anything you can do by hand in Plain, a script or an AI agent can do too.

Fly.io moved from Help Scout to Plain and built a custom support portal on Plain's API, which serves its nine-engineer support team and a rotating on-call engineer (Fly.io case study). That was a Help Scout migration, not an Intercom one.

If you'd like help scoping a custom import or planning the cutover, email help@plain.com.

Step 6: How do you cut over from Intercom without downtime?

Pick one of two cutovers, by volume, and decide up front what happens to conversations still open in Intercom:

• Hard cutover. Pick a date, point all production traffic at Plain, and freeze Intercom to read-only. Best when volume is low enough to absorb a learning curve in one week.

• Gradual cutover. Move one channel or Tier at a time over two to four weeks. Best for high volume, or when you can't afford a noisy week.

• Conversations still open in Intercom. The hourly sync brings new conversations across but not later changes to ones already imported, so a status or assignee change made in Intercom after the first import won't appear in Plain. For each open conversation, either finish it in Intercom (Intercom's own guide calls this "drain and fill") or pick it up in Plain and stop replying in Intercom. Don't work the same conversation in both.

• Email. Forwarding rules and MX records can move without customer-visible downtime, but coordinate the DNS handover with whoever owns your domain so the change lands when you expect it.

• Tell customers. Anything that changes on their side, such as a new reply-from address, a new Help Center URL, or a chat widget replacing the Intercom Messenger, should be communicated to whichever customers it reaches, including any pilot slice from Step 4.

• Run book and roll-back plan. One recommendation from Intercom's own historical-migration guide applies in either direction: write a run book for each migration run and a roll-back plan beside it. That guide covers migrating into Intercom, so take only that advice from it.

• Training. The pilot crew has already worked the queue for a week or two, so have them field questions from the rest of the team in the first cutover week.

Step 7: What should you verify before you shut Intercom off?

Verify the import against what the importer promises:

• Thread counts look right against Intercom.

• Assignees match the Intercom admin on each conversation.

• Priority conversations show as Urgent.

• Formerly snoozed conversations are in Todo.

• Attachments open.

• Timestamps are in order on threads and messages.

• Each thread links back to its original Intercom conversation.

• Internal notes came across. Spot-check a sample, since the migration guide lists them as imported.

• Every live channel delivers. Send a test message through each email address, Slack channel and chat widget, and confirm it lands in Plain with the right Tier and labels.

Before you close the Intercom account, confirm the Step 2 exports are done and stored somewhere you control: CSAT scores, survey responses and survey comments, and custom fields. Confirm your help center articles have moved.

Then decommission:

1. Disable or repoint every zap and automation that still references Intercom.

2. Remove the Intercom Messenger from your product and site.

3. Stop the sync when you no longer need it: Settings → Integrations → Intercom → Disconnect.

4. Complete sub-processor notifications you started in Step 1.

Keep Intercom read-only until you're confident, and time the final shutdown to your contract end date rather than to the cutover. The read-only window is your roll-back plan.

Set up on test channels first with a 7-day free trial, and email help@plain.com if you need help scoping a custom import.

Frequently asked questions about migrating from Intercom

Can you migrate from Intercom without downtime?

Yes, if you sequence it. Email forwarding rules and MX records can move without customer-visible downtime when the DNS handover is coordinated. A gradual cutover moves one channel or Tier at a time over two to four weeks, and importing is non-destructive, so Intercom keeps its data until you freeze it.

Does Intercom conversation history keep its timestamps and attachments when you move to Plain?

Yes. Plain's Intercom importer keeps original timestamps on every thread and message. Attachments come over with their messages, and each thread shows Intercom as the source channel with a link to the original conversation.

What doesn't transfer from Intercom to Plain?

CSAT scores, survey responses and comments, and custom fields do not import, so export them first. Help center articles move separately. Workflows, macros (as snippets), SLAs and business hours, teams and teammate accounts are rebuilt in Plain.

Will importing old Intercom conversations email customers or start SLA clocks?

No. Per Plain's migration guide, importing does not trigger SLAs, auto-responses or workflows. Nothing goes out to customers, and no SLA clocks start on old tickets.

Does Intercom's Data Export API export conversations?

No. Per Intercom's API reference, that endpoint exports delivery and engagement data for outbound content, not raw message or conversation content, and each job covers at most 90 days. For conversations, use the Conversations API, or check a sample file from the S3 or Google Cloud Storage export before you rely on it.

What happens to new Intercom conversations after the first import?

New contacts, admins and conversations sync from Intercom into Plain every hour, per Plain's Intercom importer docs. Changes to conversations that were already imported, such as status or assignee, do not sync, and the sync sends no auto-responses.