What chatbot migration actually involves in 2026
Most chatbot-switch tutorials in 2026 treat migration as a one-step problem: "re-upload your content into the new tool." That framing is incomplete and quietly causes the most painful surprises after the switch. A working chatbot is not just an index of your content. It is a configured product that holds training content, conversation history, a hand-tuned system prompt, a custom theme, an embed script on every page of your site, and a body of analytics that your team relies on for decisions. Switching tools means deciding what to do about each of those six things, in order, with a known order of operations.
The good news is that the underlying architecture has not changed. Every mainstream chatbot product in 2026 is built on retrieval-augmented generation: a frozen LLM plus your content indexed in a private vector store. Because nothing is baked into the model weights, the content side of migration is mechanical. You export from the old tool (or re-export from your own source of truth), ingest into the new tool, and the new bot starts answering as if it had been there all along. The conversation, prompt, theme, and embed-script sides are also mechanical but require more manual translation.
The reason migrations go badly is almost never a technical limitation. It is that operators try to migrate everything at once, on the day they cancel the old contract, with no overlap period to compare answers and catch regressions. The playbook in this guide is built around a 7 to 14 day dual-run, which is the single biggest predictor of a calm migration.
The 6 things to move (conversations, training, prompt, theme, embed, analytics history)
There are exactly six categories you have to make a deliberate decision about. In order of difficulty:
1. Training content (URLs, files, PDFs). This is the easiest category because you do not actually need to export it from the old tool. The original source is your website, your PDFs, and your sitemap. You point the new tool's Sources tab at the same starting URLs and the same uploaded files, and you are done. The only reason to bother with the old tool's export is if you uploaded raw pasted text that does not live anywhere else.
2. Conversation history. This is where GDPR Article 20 (the right to data portability) actually matters. Every vendor operating in the EU is legally required to give you your conversation data in a structured, machine-readable format on request, without undue delay and within one month. In practice the major vendors offer self-serve exports to JSON or CSV. The catch is that almost no vendor offers a clean import path into a competitor's product, so the export usually becomes a static archive you store yourself.
3. Custom system prompt. Manual translation. You copy the prompt text out of the old tool's admin and paste it into the new tool's prompt field. Most prompts are 200 to 2000 words and translate cleanly. Edge cases: tool-calling syntax sometimes differs, and platform-specific placeholders (visitor name tokens, page-URL injection) almost always have different syntax in the new tool.
4. Custom theme and branding. Manual translation. Color, avatar image, welcome message, suggested questions, position on the page. Take screenshots of the old widget at every breakpoint before you start so you have a reference while configuring the new one.
5. Embed script. Mechanical swap. Remove the old vendor's script tag from your site and add the new one. On most stacks this is a single file change. On WordPress, Shopify, and similar platforms it is a setting change in the chatbot plugin. The non-obvious gotcha is DNS and CDN caching; old script URLs can be cached at the edge for hours, so a small percentage of visitors will load both widgets at the same time for a brief overlap window.
6. Analytics history. Honest answer: this almost never ports. Each vendor's analytics dashboard is computed from their own database, on top of their own session model, and there is no industry-standard export format. You will keep the conversation transcripts but lose the dashboards (volume by week, deflection rate trends, top intents, satisfaction scores). Plan for an analytics gap. Snapshot the dashboards you care about as PDFs before you cancel, and accept that the new tool's analytics history will start from day one.
That six-category framework is the entire migration. Everything in the rest of this guide is detail on how to execute each step.
Step 1: export training content from the old tool
For most operators, this step is unnecessary because the source of truth is your website. But there are three cases where the old tool's training-content export is worth pulling.
The first is pasted-text snippets that do not live on any page. If you used the old tool's "paste raw text" feature to add policy text, internal FAQ entries, or one-off answers, that text lives only inside the vendor's database. Export it before you cancel. Most tools expose a JSON export of all training sources in the admin.
The second is uploaded PDFs that you no longer have the originals of. Some tools keep the uploaded file. Some keep only the parsed text. Either way, retrieving them now is easier than reconstructing them later.
The third is structured Q&A pairs you wrote by hand in the old tool. Almost every vendor's admin lets you author canonical answer pairs that override retrieval. Those are not on your website. Export them as JSON or CSV.
For everything else (URL crawls, sitemap-ingested pages, indexed blog posts), skip the old tool's export entirely and just point the new tool at the same sitemap. The new ingestion run will be cleaner and more current than whatever the old tool indexed three months ago.
Step 2: export conversation history (GDPR Article 20)
GDPR Article 20 gives any data subject the right to receive personal data concerning them in a structured, commonly used, machine-readable format, and to transmit that data to another controller. For your business as a customer of a chatbot vendor, that translates into a contractual right to export conversation data on demand. The major vendors in 2026 have built that right into self-serve admin exports.
Practical mechanics for the common vendors:
Chatbase exports conversations as JSON from the admin. The format is one record per conversation with nested messages. Public reviews note that the JSON-only format is less user-friendly than CSV would be, but it is structured and machine-readable, which is what GDPR Article 20 requires.
Intercom exports conversations as JSON or CSV. There are two paths: a self-serve export from the Reports UI, or a programmatic export via the Conversations API. The important constraint is that Intercom's event history export is limited to the last 90 days. If you need a longer window of session events, request the full export through Intercom's GDPR portal and reference Article 20 explicitly.
Tidio exports conversation transcripts as CSV from the admin. Standard self-serve flow.
Drift is the special case in 2026. Clari plus Salesloft announced the gradual sunset of Drift on March 6, 2026 and named 1mind as the exclusive AI successor for the conversational marketing use case. No hard end-of-life date was published with the announcement, but active product investment has ended. Whatever migration path you choose, get your Drift conversation data out before the support window closes. Book the discovery call with your Clari plus Salesloft account team specifically to nail down the data export deadline in writing.
For any vendor not on this list, the rule is the same: the GDPR Article 20 obligation applies, and the standard formats are JSON or CSV. If self-serve export is not in the admin, raise a formal portability request in writing and the vendor must respond within one month.
A subtle point on what conversation history is useful for. Most migrating teams imagine they will import their old conversations into the new tool. That is almost never possible because the data schemas are vendor-specific. What you actually use the export for is: archival compliance, sample analysis to build a test set, and feeding a small batch of real questions back into the new tool to verify the answers are at least as good as before.
Step 3: rebuild the custom prompt
The custom system prompt is usually the most valuable artifact you carry across the migration. A well-tuned prompt represents months of iteration on rules, tone, refusal policies, escalation triggers, and brand voice. It is also small (text, kilobytes at most), so the migration step is mechanical.
The translation work is real, though. Three things commonly break:
Placeholder syntax. If your old prompt referenced things like {{visitor.name}}, {{page.url}}, or vendor-specific tags for the current product, the new tool will use a different syntax. Translate each placeholder by hand.
Tool calling. If your prompt invoked vendor-specific function calls (for example, "use the schedule_meeting tool when the visitor asks for a demo"), those tool names are platform-specific. Map them to the equivalent capability in the new tool, or remove the tool block entirely if the new tool exposes the capability through configuration rather than prompt.
Refusal and escalation rules. Most well-built prompts contain rules like "if the visitor asks about pricing for plans above Pro, escalate to live chat." The intent ports; the mechanics of triggering escalation may differ.
After translation, paste the new prompt into the new tool, run the 20-question test set described below, and compare the answers side-by-side against the old tool for tone and brand voice consistency.
Step 4: rebuild custom theme and branding
Theme is the most visually obvious but technically simple step. Re-create the color, avatar image, welcome message, position, and suggested questions inside the new tool's appearance settings. Before you start, take screenshots of the old widget on desktop and mobile, and pull the hex codes of the primary color and any accents into a small reference file.
Three details that get missed:
Welcome message wording. Visitors are accustomed to a specific opening line. Carry it across word for word unless you have a reason to change it.
Suggested question chips. If the old widget displayed three or four canned question chips on first open, port the same chips. They often double as your best-performing entry points.
Loaded-on-which-pages rules. Some teams hide the widget on specific URLs (checkout pages, legal pages). Mirror those rules in the new tool's configuration.
Step 5: swap the embed script
Embed-script swap is mechanical and usually takes minutes. The structure is the same on every modern chatbot platform: a single script tag that you place once in your site template.
The order of operations matters more than the swap itself.
First, install the new tool's script alongside the old one for the dual-run period (more on this below). For seven to fourteen days, both widgets load. You can configure one to be hidden visually while it indexes traffic and warms up; the other stays visible to visitors. This is the most common pattern.
Second, when you cut over, you do it at the template level. On a static site or a Next.js site, this is one edit to the root layout. On WordPress, Shopify, Webflow, or other CMS platforms, it is a setting change inside the chatbot plugin or in the theme's custom code block.
Third, plan for DNS and CDN caching. Visitor browsers and edge caches can hold the old script URL for hours after you publish the change. During this overlap window, a small percentage of visitors will see both widgets at once. The fix is to either set short cache TTLs on the script tag for the migration day, or accept the overlap and move on.
Fourth, verify the swap on at least five real pages: home, pricing, one product page, one blog post, and one with the widget hidden. Use a clean browser session (incognito or a fresh device) so cached resources do not mask a misconfiguration.
Step 6: monitor for regressions in the first 14 days
The single most important thing you can do is overlap the two tools. Run both for 7 to 14 days. The new tool indexes traffic and you compare answers. You catch regressions before they cost you support tickets.
A practical dual-run protocol:
Day 0: install both scripts. Hide one widget visually (most platforms expose a no-show flag) so visitors do not see two bubbles. Both bots receive your test traffic.
Days 1 to 7: run your 20-question regression test daily on the new tool. Mix in five questions drawn from the old tool's conversation history (real questions real visitors asked last month). Grade each answer on accuracy and citation quality. The new tool should match the old tool's score within two points by day 5.
Day 7: switch the visibility. Hide the old widget, show the new one. Keep both scripts loaded so you can flip back instantly if something breaks.
Days 8 to 14: monitor live conversation logs in the new tool. Look for three regression signals: unanswered rate climbing above 10 percent (indexing gaps), citation rate dropping (retrieval misses), or tone drift (the prompt translation lost something).
Day 14: remove the old script tag, cancel the old contract.
Common gotchas: dual-running, embed-script DNS caching, analytics gap
The three most common painful surprises:
Skipping the dual-run. Operators who cut over in a single day spend the first week firefighting regressions that a 7-day overlap would have caught. Budget the overlap; it pays for itself in support tickets you do not have to answer.
Embed-script DNS and CDN caching. Edge caches hold old script URLs longer than expected. Visitors on stale caches load both widgets for hours after you publish the change. Either tighten cache TTLs ahead of the cutover or accept the overlap.
Analytics gap. This is the one operators consistently underestimate. Your new tool's analytics start at day one. Trend lines, satisfaction history, deflection rates, top-intent reports: all reset. If your team depends on those for monthly reviews, pull PDF snapshots of the old dashboards before you cancel, and brief stakeholders that the next two quarters will have a partial baseline.
Vendor-specific notes (Drift sunset, Chatbase export, Intercom)
Drift (sunsetting in 2026). The March 6, 2026 announcement from Clari plus Salesloft made 1mind the named successor for the Drift conversational marketing use case. There is no published hard end-of-life date, but active product investment has ended. Priorities for any team still on Drift: get a written data export deadline from your account team, export your conversation history and any structured playbooks before that deadline, decide whether 1mind fits your stack or whether a different alternative is a better fit, and plan the embed swap for a period when traffic is light. The migration of contracts and prepaid balances is handled case by case through the account team.
Chatbase. Self-serve export is JSON-only as of mid-2026. The format is structured and machine-readable, which satisfies GDPR Article 20, but it is not the most readable format for humans. If you need CSV, run the JSON through a simple flattener. Chatbase data sources support sitemap submission, document upload, structured Q&A pairs, Notion sync, and ticket import from Salesforce and Zendesk (added January 2026). All of those are easy to re-create on the destination side from the original sources.
Intercom. Strongest self-serve export of the major vendors. Conversations export as JSON or CSV from the Reports UI, and a richer programmatic export is available through the Conversations API. The 90-day event-history cap is the only material limitation; request a full Article 20 export in writing if you need longer. Note Intercom does not provide an import path for conversation history into a competitor's workspace, so the export is archival.
Tidio. CSV export from the admin, no special steps required.
ChatRaj's Sources page accepts URLs, sitemaps, and file uploads, so migrating training content from another vendor is usually a one-afternoon job. Point the Sources tab at your sitemap.xml, upload any PDFs you exported from the old tool, paste any structured Q&A pairs, and let indexing finish. The 20-question test set from your old tool becomes your regression baseline on day one.