Skip to content
Chatbotscape
Editorial flat-vector illustration for Migrating Chatbot Vendors — The 14-Day Playbook (2026)
10 min read

Migrating Chatbot Vendors — The 14-Day Playbook (2026)

Quick answer: Switching chatbot platforms fails most often not because the new tool is worse, but because the migration is run as a flip of a switch instead of a two-week project. The three things that actually break a move are channel re-connection (especially a WhatsApp number tied to a Business Solution Provider), lost conversation history and contact data, and a flow rebuild that quietly drops edge cases the old bot handled. This playbook spreads the work across fourteen days — audit and baseline first, rebuild and re-wire in the middle, run both platforms in parallel before you cut over, and decommission last — so the new bot is provably at least as good as the old one before any customer touches it. Baseline your first response time, containment rate, and CSAT on day one, because those numbers are how you will know whether the switch actually worked.

A vendor switch is one of the few chatbot projects where the failure mode stays invisible until a customer hits it. A flow you forgot to rebuild does not error; it just falls back, and the user leaves. A WhatsApp number that did not migrate cleanly does not warn you; it silently stops delivering. The defence is sequencing: do nothing irreversible until you have proof the replacement works, and keep the old platform alive until you do. The fourteen days below are a template, not a law. Compress them for a simple FAQ bot, stretch them for a multi-channel deployment with deep integrations. What does not change is the order.

Before you start — decide whether to migrate at all

A migration costs real hours, and "the new tool looks nicer" rarely justifies it. The cases that do: you are hitting a hard ceiling (a channel the current vendor cannot serve, a WhatsApp Business API tier you cannot reach, a pricing model that punishes your growth), support quality has degraded, or the platform's roadmap has stalled while your needs grew. If the reason is cost alone, price the destination honestly first — our pricing models guide shows how a plan that looks cheaper at the demo can cost more at your real volume. Migrate to escape a structural limit, not to chase a feature you would use once.

Days 1-3 — Audit and baseline

You cannot prove a migration succeeded without a before picture, so the first three days are pure inventory. List every flow, every integration, every channel, and every automated message the current bot sends. Export everything you can: contact lists, conversation transcripts, tags and custom fields, and any saved-reply or knowledge-base content. Treat the export as the deliverable of this phase — if the old vendor makes export hard, that friction is itself useful information about how locked-in you have been.

Then baseline the numbers. Record the current containment rate, CSAT, escalation rate, and human first response time over a representative two-week window. These are your acceptance criteria. The new platform does not have to beat them on day one, but it must not quietly fall below them, and without the baseline you will be arguing from feel instead of data.

Days 4-6 — Rebuild flows and knowledge

Now rebuild on the new platform, working from the audit list so nothing is rebuilt from memory. Start with the highest-traffic flows — the handful of intents that carry most of your volume — and get those genuinely working before you touch the long tail. Resist the temptation to copy the old bot one-to-one; a migration is the rare moment you can fix the conversation design debt that accumulated, prune dead branches, and consolidate near-duplicate flows. But fix deliberately, and keep a checklist of every old behaviour so an "improvement" never silently drops a path customers actually used.

Rebuild the knowledge layer with the same discipline. If the new bot is LLM-backed, point it at your cleaned content and check that its answers match the old bot's on a fixed set of test questions. The QA testing protocol gives a structured way to run this — a scripted pass over your top intents that catches the regressions a click-through demo misses.

Days 7-9 — Re-wire channels and integrations

This is the phase that breaks migrations, and the WhatsApp channel is the single most common casualty. A WhatsApp number is tied to a Business Solution Provider, and moving it to a new platform means migrating the number between BSPs. That process carries its own approval steps, a brief verification window, and the real risk of message-template re-approval. Start it early in this window, never on cutover day, and read your new vendor's exact migration steps before you touch anything. The same caution applies to any deep integration: CRM syncs, payment links, and webhook endpoints all need re-pointing and re-testing, and each one is a place a "finished" migration silently isn't.

Re-test every integration end to end on the new platform, not in isolation. A CRM field that maps correctly in a settings screen can still fail to populate when a real conversation fires it, and a human handoff that routes perfectly in a test can break when it meets your actual agent rota. The acceptance bar for this phase is a real conversation, start to finish, through every channel and every integration.

Days 10-11 — Run both platforms in parallel

Do not cut over from a test environment. Run the new bot live alongside the old one on a slice of traffic — a single channel, a single flow, or an off-peak window — and watch the baselined metrics. This shadow period is where you catch the regressions no internal test surfaces: the intent that works for you but not for real phrasing, the integration that holds for ten conversations and fails on the eleventh, the handoff that queues longer than the old platform did because routing changed.

Keep both platforms paid and active through this phase. The overlap costs you a few days of double subscription, which is trivial against the cost of a botched cutover, and it is the entire reason the new bot can fail safely. Promote more traffic to the new platform only as each metric holds at or above the baseline.

Days 12-13 — Cut over

With the new platform proven on real traffic, move the remaining volume across. Update the website widget, repoint the channels you have not already moved, and switch your default routing to the new bot. Watch the live dashboard closely for the first few hours. First response time and escalation rate are the fastest signals that something routed wrong, because a misrouted handoff shows up there before it shows up in a complaint. Keep the old platform reachable but idle, not deleted: it is your rollback if the cutover surfaces a problem the shadow period missed.

Day 14 — Decommission and confirm

Only once the new platform has carried full live traffic cleanly for a day do you decommission the old one. Confirm your exports are complete and stored, download any final transcript or analytics you will want for the record, then cancel the old subscription. Re-run the baseline metrics over the first full live window and compare: the migration is "done" when containment, CSAT, and human first response time sit at or above where they started, not when the new bot merely answers. File the before-and-after numbers — they are the evidence the switch paid for itself, and the starting point for the next round of tuning.

From plan to platform

The playbook is platform-agnostic, but the destination decides how hard each phase is. Flow-first builders such as Manychat and SendPulse make the flow rebuild quick but put the channel and BSP re-wiring squarely on you; support-desk platforms such as Intercom and Tidio handle more of the integration plumbing but ask more of the knowledge-and-tone rebuild; developer-grade tools such as Botpress give you clean export and instrumentation at the cost of more setup. If you are still choosing the destination, our ranked best AI chatbot platforms list breaks down where each lands for an SMB, and the metrics guide covers the KPI baseline you will measure the move against.

Frequently asked questions

How long does a chatbot migration take?

For a single-channel FAQ bot, a focused team can compress this to three or four days; for a multi-channel deployment with WhatsApp, CRM, and payment integrations, two weeks is realistic and the parallel-run phase is non-negotiable. The variable that stretches the timeline most is channel re-connection — particularly a WhatsApp number moving between Business Solution Providers, which has approval steps outside your control. Plan around the slowest external dependency, not the fastest internal task.

Will I lose my conversation history when I switch platforms?

You will unless you export it first. Conversation transcripts rarely transfer between vendors automatically, and several platforms restrict export the moment a cancellation is queued. Treat the export — transcripts, contacts, tags, custom fields, and knowledge content — as the first deliverable of the migration, completed before you give any notice on the old plan. Store it independently of either vendor.

What is the riskiest part of migrating a chatbot?

Re-connecting the WhatsApp channel. A WhatsApp number is bound to a Business Solution Provider, and moving it to a new platform means migrating between BSPs, with a verification window and possible message-template re-approval. Start it early, never on cutover day, and never tear down the old connection until the number is confirmed live on the new one. Deep integrations — CRM, payments, handoff routing — are the next-riskiest and need end-to-end re-testing on a real conversation.

Should I rebuild my flows exactly or improve them during migration?

Improve, but deliberately. A migration is a good moment to prune dead branches and fix accumulated conversation design debt, but keep a checklist of every behaviour the old bot had so an "improvement" never silently drops a path customers used. The discipline is: change on purpose, never by omission, and verify against your top intents with the QA testing protocol before cutover.

How do I know the migration actually worked?

By the numbers you baselined on day one. Record containment rate, CSAT, escalation rate, and human first response time before you start, then re-run them over the first full live window on the new platform. The migration is done when those metrics sit at or above the baseline — not when the new bot merely replies. Without the before picture you are judging the switch on feel, which is how teams talk themselves into a worse deployment.

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This playbook is part of our SMB chatbot Academy and is a planning aid, not a vendor-specific runbook — the exact migration steps, especially for WhatsApp and Business Solution Provider changes, are set by your current and destination platforms, and you should follow their documentation for the irreversible steps. Verify channel and pricing details on the vendor's own pages before you act, per our integrity rules. To flag an issue or share your own migration experience, write to editorial@chatbotscape.com.

Methodology

The fourteen-day sequencing reflects the migration patterns observed across Chatbotscape's evaluation of the 2026 SMB chatbot platform catalog, cross-referenced with vendor documentation on data export, channel connection, and WhatsApp BSP migration (Manychat, SendPulse, Intercom, Tidio, Botpress). The phase order — audit and baseline, rebuild, re-wire, parallel run, cutover, decommission — is the consistent through-line; specific durations are illustrative and should be compressed or extended to fit the complexity of your deployment. Per our methodology we do not claim a measured migration time, because timelines depend on external approval windows outside any single operator's control.

Last updated

18 June 2026 — Initial publication aligned to methodology v3.12.1. Next scheduled refresh: 18 September 2026.