Migrate from Intercom to an AI Chatbot: 2026 Checklist

The 6 Migration Steps (Overview)

A structured Intercom-to-AI-chatbot migration follows six steps, roughly in this order: inventory what you have, export it before your data window narrows, rebuild the knowledge base for retrieval instead of self-service browsing, reconnect the tools that plugged into Intercom, run both systems in parallel during cutover, and close the loop on data retention once you cancel.

• 1. Inventory — list every workflow, integration, and help center article currently live in Intercom.
• 2. Export — pull conversations, contacts, and attachments before cancellation starts your retention clock.
• 3. Rebuild the knowledge base — convert help center articles into documents a RAG chatbot can retrieve from.
• 4. Re-wire integrations — reconnect CRM sync, webhooks, and any Custom Bot workflows to the new platform.
• 5. Cutover — run the new chatbot in parallel before fully switching the live widget, with a rollback plan ready.
• 6. GDPR close-out — request your full data export and confirm deletion once the Intercom contract ends.

The most common failure mode is skipping straight to step 4. Teams that migrate the chat widget first and treat data export as an afterthought routinely discover, weeks later, that they can no longer pull historical conversations — because Intercom's own retention and export windows have already started narrowing (see Step 5).

Step 2: Export Your Intercom Data (API Limits to Know)

Do this first — before you touch cancellation, integrations, or the widget.

Intercom's Data Export API and admin-panel exports work, but they were built for periodic backups, not for a one-time full migration. Three constraints matter most when you plan the export:

• CSV export row cap: manual CSV exports from the Intercom inbox are capped at roughly 10,000 rows per export. Larger conversation histories need multiple exports or the Data Export API in batches.
• Expiring download links: export download links generated by Intercom expire after a short window (around 2 days). Download and archive files immediately — do not queue exports and come back to them later.
• Message parts cap per conversation: individual conversation threads returned via the API are capped at roughly 500 message parts. Very long-running threads (multi-year support tickets) may be truncated and need to be paginated or fetched in segments.

There is no bulk export endpoint for the Intercom help center itself. Articles have to be pulled individually — either through the Articles API, one article at a time, or by scraping the public help center URLs if the API access tier does not include content export. Budget time for this: a help center with 150 articles is a different job than one with 15.

Source: Intercom's own developer documentation on the Data Export API confirms these mechanics — verify current limits against your account's API tier before you plan your export timeline, since Intercom periodically adjusts caps by plan.

Step 3: Rebuild the Knowledge Base (Help Center → RAG)

An Intercom help center is built for humans to browse by category. A RAG (Retrieval-Augmented Generation) knowledge base is built for a language model to retrieve the single most relevant passage for a specific question. The two structures are not interchangeable — porting your help center over as-is usually produces mediocre chatbot answers.

What changes between "help center" and "RAG-ready"

• One topic per document: a 40-article help center category exported as one giant file retrieves poorly. Split it back into individual, single-topic documents — ideally the same granularity as the original articles.
• Strip navigation and boilerplate: exported HTML often carries sidebar links, "Was this helpful?" widgets, and related-article blocks. These add noise to retrieval. Clean them out before upload.
• Preserve headings: RAG chunking uses document structure (H1/H2) to scope passages. If your export flattens formatting, re-add headings manually for your highest-traffic articles at minimum.
• Flag outdated articles: an Intercom help center accumulates stale content over years. A migration is the natural checkpoint to archive anything that no longer reflects your product or policies — do not carry dead weight into the new knowledge base.

Conversation history: mine it, do not just archive it

Your exported Intercom conversations are also a source of unwritten knowledge — the questions customers actually asked that never made it into a formal help center article. Before you finalize the knowledge base, scan a sample of historical conversations for recurring questions with no matching article, and write short documents to cover those gaps. This single step often improves post-migration chatbot accuracy more than the article migration itself.

For the mechanics of turning documents into a retrieval-ready index — chunking, embeddings, vector storage — see our guide on what RAG is and how it works.

Step 4: Re-Wire Integrations and Workflows

Intercom deployments accumulate integrations over time: CRM sync (Salesforce, HubSpot), Custom Bot workflows, Slack notifications, webhooks into internal tools, and sometimes Zapier or Make automations layered on top. None of these migrate automatically — each has to be inventoried and rebuilt on the new platform.

• CRM sync: identify which contact fields and conversation events sync to your CRM today. Confirm the new chatbot platform supports the same sync direction (contact creation, tagging, deal updates) before cutover.
• Custom Bot / workflow logic: Intercom's rule-based Custom Bots (branching decision trees, qualifying questions) do not translate directly to a RAG chatbot's system-prompt-driven behavior. Rebuild the underlying logic as instructions and escalation rules rather than trying to replicate the flow chart node-for-node.
• Webhooks and internal tools: list every webhook currently firing from Intercom (ticket creation in your internal system, alerting, analytics pipelines) and confirm an equivalent event exists on the new platform.
• Team notifications: Slack or email alerts for escalations, missed messages, or specific keywords need to be reconfigured — this is often the integration teams forget until the first missed handoff after cutover.

Do this inventory before cutover, not during. A missing webhook discovered on day one of the live switch is a support incident; the same gap found during planning is a checklist item.

Step 5: Cutover With No Downtime (+ Rollback Plan)

A clean cutover runs both systems in parallel before fully retiring Intercom, rather than switching the live widget in one step. This gives you a window to catch gaps in the knowledge base or missed integrations while the old system is still available as a safety net.

The parallel-run window

Deploy the new chatbot on a staging URL or a low-traffic page first. Run real questions through it — ideally the recurring questions you mined from Intercom conversation history in Step 3 — and compare answer quality against what Intercom (or a human agent) would have given. Two to five business days of parallel testing is typically enough to surface the obvious gaps for a small-to-mid-sized knowledge base.

The switch itself

Replace the Intercom Messenger script with your new chatbot's embed snippet on the live site. Keep the Intercom account active — do not cancel it yet — for a defined grace period (commonly one to two weeks) so you retain access to historical data and can fall back if the new deployment surfaces a critical gap.

Rollback plan

Before you switch, write down the specific conditions that would trigger a rollback: for example, escalation rate spiking above a defined threshold, or a pattern of factually wrong answers on a topic you thought was covered. If Intercom is still active and its script tag is not yet removed from your codebase, reverting is a same-day operation. This is the main reason not to cancel Intercom immediately after switching the widget.

Step 6: GDPR — Retention, Export, and Deletion

If you operate in or serve the EU, GDPR obligations do not end when you stop using Intercom — they govern what happens to the data Intercom already holds on your behalf. Two windows matter here, and both are documented on Intercom's own help site.

• GDPR data export window: Intercom's self-service GDPR data export is limited to roughly the last 90 days of data. If you need a complete historical export for compliance purposes, request it well before cancellation — do not assume the standard export tooling covers your full history.
• Post-cancellation retention: after a workspace is cancelled, Intercom retains data for approximately 13 months before deletion. This is useful as a safety net if you discover a gap after cutover, but it is not indefinite — track the date and confirm final deletion if required for your compliance posture.

Document the export and deletion dates in your migration record. If your company operates under EU data protection obligations, this closes the loop on your data processing agreement with Intercom and gives you a clean audit trail.

Source: Intercom's help center documentation on data export and retention — confirm current windows for your specific plan before relying on these figures, as retention policies can be updated by the vendor.

Migration Checklist (Copy This)

This is the same structure covered above, condensed into a working checklist you can copy into your own project tracker.

FAQ