--- title: "Migrating Your AI Chatbot: From One Platform to Another Without Breaking Support (30–45 Day Plan) " date: 2026-08-27 author: "Rhett Freeman" featured_image: "https://desku.io/wp-content/uploads/2026/08/DSK-Blog-SJ-092-Thumbnail.webp" categories: - name: "Blogs" url: "/blogs.md" --- # Migrating Your AI Chatbot: From One Platform to Another Without Breaking Support (30–45 Day Plan)  Choosing a new chatbot platform is the easy part. Moving to it while a live support operation depends on the old one is where projects go wrong, usually not dramatically, but through a slow accumulation of small regressions nobody notices until CSAT drops. Migrations are also happening more often than teams planned for, because the market forced them. Four of the platforms covered in our chatbot comparison checklist changed hands or changed product direction in the eighteen months to August 2026, and Botpress changed its billing model. Several teams that had no intention of migrating are now evaluating one. This is a practical plan for doing it in 30 to 45 days without your customers noticing. ![DSK Blog SJ 092 Strip 1](https://desku.io/wp-content/uploads/2026/08/DSK-Blog-SJ-092-Strip-1.webp "- Desku")-### **KEY TAKEAWAYS** - Migrate only when the problem is clearly tied to cost, integration limits, reporting gaps, vendor risk, channel needs, or a platform ceiling that configuration can’t fix. - A safe migration starts with a full inventory, a clear baseline, a real regression test set, and an early decision on what happens to conversation history. - Keep the old platform live while you rebuild outcomes, connect knowledge sources, test failures, verify handoff quality, and train agents before cutover. - Move traffic in stages, monitor support quality against the baseline, keep the old platform available, and test rollback before you need it. - Post-cutover value comes from daily failure review, weekly knowledge-gap fixes, honest baseline comparison, billing checks, and a regular review cadence. - Choose the next platform with migration in mind, including export capability, pricing durability, integration fit, and how the vendor treats existing customers when terms change. ## **Migration triggers: check you’re solving the right problem** Before planning anything, be specific about the failure. Migration is expensive, and a good number of the reasons teams give turn out to be configuration problems rather than platform problems. **Cost structure no longer fits.** Common in 2026, because pricing models fragmented. A platform charging per resolution gets more expensive precisely as your AI improves, which is the explicit argument Ada makes against outcome pricing, and the reason vendors like [Dante AI](https://desku.io/blogs/dante-ai-alternatives/) and Crisp now market flat pricing as a differentiator. If your volume grew 3x and your bill grew 4x, the model is the problem, not the vendor. **Poor deflection.** Genuinely a platform problem *if* you have already improved your knowledge base, tuned escalation thresholds, and reviewed failed conversations. If you haven’t, migrating will reproduce the same result on new software. Bad answers usually trace to bad source content. **Integration ceiling.** The most legitimate trigger. If the platform can’t write to your CRM correctly, can’t execute actions mid-conversation, or gates webhooks behind a tier you won’t buy, no amount of tuning fixes it. **Reporting gaps.** You can’t see why conversations fail. Knowledge-gap detection and conversation-level failure analysis are increasingly table stakes, and their absence is a real constraint on improvement. **Vendor risk.** Acquisition, discontinuation, or a product direction that no longer includes your use case. **Channel requirements.** You need [WhatsApp](https://desku.io/blogs/whatsapp-business-api-chatbot-alternatives), voice, or a channel the incumbent doesn’t support natively. Write the trigger down in one sentence. If you can’t, you’re not ready to migrate. ## **Days 1–10: Audit and plan** ### **Inventory what you actually have** Teams routinely underestimate this. Catalog: - **Every intent or flow**, including the ones nobody remembers building. Sort by conversation volume, typically a small fraction of them carries the overwhelming majority of traffic. - **Every knowledge source** feeding the bot: help center articles, crawled URLs, uploaded documents, past tickets, custom answers. - **Every integration**, including the ones running through Zapier that nobody documented. - **Every escalation rule** and where each routes. - **Every automated message** the bot can send, including out-of-hours and fallback responses. - **Conversation history**, volume, retention period, and whether you can export it. ### **Decide what not to migrate** Spend an hour here. A migration is the only realistic opportunity you will get to delete things. Rank intents by volume and success rate. Migrate the high-volume, high-success ones first. For low-volume flows, ask whether they earn their maintenance cost. Flows built for a campaign that ended, or an integration that was retired, should not be rebuilt. ### **Establish your baseline** You cannot prove a migration succeeded without a before picture. Capture, from the incumbent: - Resolution or deflection rate **and its definition on that platform** because definitions differ enough that raw comparison is meaningless - Escalation rate and average time to escalate - CSAT on bot-handled conversations - Average handle time on escalated conversations - Volume by channel and by hour - Your top 20 questions by volume Export the raw data, not just the dashboard. You will want to re-cut it. ### **Build the regression test set** Pull 100 to 200 real conversations from the incumbent, deliberately including: your ten highest-volume questions, ten known edge cases, five conversations where the old bot failed, and five where a customer was frustrated. This set is what you will run against the new platform repeatedly. Its quality determines the quality of your migration. ### **Plan the conversation history question early** Chat transcripts rarely migrate cleanly between platforms. Data models differ and most vendors provide export but not import. The realistic options are: 1. **Export and archive.** Keep a read-only export for compliance and reference. Cheapest, and adequate for most teams. 2. **Import summaries only.** Some platforms accept contact-level notes; a conversation summary on the CRM record often preserves enough context. 3. **Run both in parallel** during transition, with the old platform read-only. Whichever you choose, check your retention obligations first and confirm the old vendor’s data deletion terms and timeline before you cancel. ![DSK Blog SJ 092 Strip 2](https://desku.io/wp-content/uploads/2026/08/DSK-Blog-SJ-092-Strip-2.webp "- Desku")-## **Days 11–25: Build and test in parallel** Do not decommission anything yet. The old platform stays live and handling production traffic throughout this phase. ### **Rebuild, don’t transplant** Resist recreating the old bot exactly. Platforms differ in how they retrieve and reason, and a flow structure that suited a rules-based builder often works badly on a retrieval-based system and vice versa. [Rebuild the outcome](https://desku.io/blogs/boost-efficiency-for-your-website-chatbot/), not the implementation. Start with knowledge sources, because on most modern platforms they do most of the work. Connect the help center, crawl the site, upload documents. Then check something teams routinely miss: **how the platform handles source updates.** Some auto-sync knowledge base articles; some require manual retraining after a URL’s content changes. Desku, for example, documents that its help center articles auto-sync while public URLs require manual retraining. Know which of your sources will go stale silently. Then rebuild flows in volume order. Highest-traffic first, so if you run out of time you have covered the traffic that matters. ### **Test properly** Run the full regression set. Score every response into four buckets: - **Correct:** Accurate and complete - **Partially correct:** Accurate but incomplete - **Correctly escalated: T**he bot recognized its limits and handed off - **Wrong** : And separately, **confidently wrong** Track confidently wrong as its own metric. It is the failure mode that destroys customer trust, and an aggregate accuracy percentage hides it completely. Then test the things regression sets don’t cover: **Escalation.** Force low-confidence conditions, sensitive topics, and explicit “talk to a human” requests. Verify each routes correctly and that the agent inherits context. Check rich message formats specifically, since these commonly degrade on handoff, our [CRM integration guide](https://desku.io/blogs/chatbot-crm-integration) documents the failure modes. **Integrations under failure.** Don’t just test the happy path. Disconnect the CRM mid-conversation. Send a malformed payload. Exceed a rate limit deliberately. What the platform does when things break matters more than what it does when they work. **Duplicate creation.** Push twenty test conversations through and count the CRM records created. This catches identity-matching problems while they are still cheap. **Load.** If you have seasonal peaks, test at peak volume, not average. ### **Train the team before cutover, not after** Agents need hands-on time with the new inbox, escalation view, and handoff experience. Document what changed for them specifically. An agent who can’t find the transcript on a handed-off conversation will ask the customer to repeat themselves, and the customer will blame the bot. ## **Days 26–35: Staged cutover** Never flip everything at once. **Stage 1: Internal.** Route employee traffic only. Two days. **Stage 2: Off-peak segment.** Route 10% of live traffic, ideally in a low-volume window with agents watching. Two to three days. Read every escalated conversation. **Stage 3: Single channel.** Move one full channel, usually web chat, since it’s the most forgiving. Three to four days. Watch escalation rate and CSAT daily against your baseline. **Stage 4: Full.** Move remaining channels. Keep the old platform available, configured and paid for, for at least two weeks after full cutover, which extends past day 45, so budget for the overlapping subscription. ### **Have a rollback plan you have actually tested** Write down the trigger conditions before you start, so the decision isn’t made under pressure. Reasonable triggers: escalation rate more than 50% above baseline for 24 hours; CSAT drop beyond a threshold you set in advance; any integration writing bad data; a critical flow failing. Test the rollback during Stage 1, when it costs nothing. A rollback plan that has never been executed is a hypothesis. ## **Days 36–45: Stabilize and optimize** The first two weeks post-cutover are where the value is won or lost, and where most teams disengage. (The phases above sum to 45 days. To reach 30, compress the build and cutover phases; realistic only for a single-channel deployment with few custom flows and one integration.) **Read failed conversations daily.** Not a sample, all of them, for the first week. Patterns emerge fast, and most are fixable with content rather than configuration. **Close knowledge gaps weekly.** Every question the bot couldn’t answer is a missing article. Platforms that detect knowledge gaps automatically make this substantially easier; if yours doesn’t, build the review into someone’s calendar. **Compare against baseline honestly, and normalize the definitions.** If your new platform counts partial automation as a resolution and your old one didn’t, the improvement in your dashboard is partly an accounting change. State that in your report to leadership. It protects your credibility when someone else notices. **Re-verify the bill.** Model versus actual, on the new pricing model, after 30 days of real traffic. This is the point at which per-resolution and per-conversation pricing surprises show up. **Set a review cadence.** Monthly for the first quarter, then quarterly. Chatbots degrade without attention. Products change, help center articles go stale, and the questions customers ask shift. ## **Choosing the platform you’re migrating to** Everything above assumes you have picked a destination. If you haven’t, run a structured evaluation rather than a demo tour, our [chatbot comparison checklist](https://desku.io/blogs/ai-chatbot-alternatives) covers the scoring matrix, integration requirements, and a 14-day shortlist process. Two migration-specific criteria worth adding to that framework: **Export capability at the new vendor.** Ask, before signing, how you would get your data out. A vendor that answers well is telling you something about how they intend to keep you. A vendor that can’t answer is telling you something too. **Pricing model durability.** You are [migrating partly because something changed](https://desku.io/blogs/zendesk-to-desku-migration-process/). Ask what the vendor’s pricing model was two years ago, and whether existing customers were grandfathered when it changed. Botpress, for instance, applied its May 2026 per-conversation model only to workspaces created after the change, leaving existing customers on the old terms. That is a meaningful signal about how a vendor treats its installed base. ![DSK Blog SJ 092 Strip 3](https://desku.io/wp-content/uploads/2026/08/DSK-Blog-SJ-092-Strip-3.webp "- Desku")-## **FAQs** ### **How long does a chatbot migration take?** Thirty to forty-five days is realistic for a mid-sized support operation with a handful of integrations, following the phases above. Simple single-channel deployments with few custom flows can be done in two weeks. Complex multi-channel operations with deep CRM integration and regulatory requirements should plan for 60 to 90 days. There is no independent benchmark data here, treat any confident industry average you read as unsourced. ### **Can we migrate conversation history?** Rarely in full. Most platforms offer export but not import, and data models differ. Plan to archive the export, carry summaries into your CRM, and check your retention obligations before deleting anything. ### **Should we run both platforms in parallel?** Yes, for the cutover period and roughly two weeks afterward. The overlapping subscription cost is small insurance against a rollback you can’t execute. ### **How do we avoid losing deflection rate during the switch?** Expect a temporary dip and plan staffing for it. Mitigate by rebuilding high-volume intents first, testing against real historical conversations rather than invented ones, and staging the cutover so problems surface at 10% of traffic instead of 100%. ### **What’s the most common migration mistake?** Recreating the old bot exactly, including the parts that weren’t working. The second most common is disengaging the week after cutover, when reading failed conversations would have the highest return of any activity in the project.