Chatbot Migration Checklist: A Go or No-Go Playbook

canonical: https://assistloop.ai/blog/chatbot-migration-checklist
category: Insights
tags: [Chatbot, Customer Support, Migration, AI]
author: Yared
published_time: 2026-07-29T00:00:00Z
meta-description: Use this chatbot migration checklist to export data, rebuild knowledge sources, test actions and handoff, then cut over with evidence and rollback ready.
og:title: Chatbot Migration Checklist: A Go or No-Go Playbook
og:description: Use this chatbot migration checklist to export data, rebuild knowledge sources, test actions and handoff, then cut over with evidence and rollback ready.
og:image: null
og:image:alt: A support lead reviewing chatbot migration checks before a production cutover
og:type: article
twitter:card: summary_large_image
twitter:site: @assistloop
robots: index, follow
schema: Article + FAQPage
read_time: 9 min read
last_verified: July 2026

Stop the cutover if your team cannot prove that customers will get the right answer, reach a person, and recover when an integration fails. This chatbot migration checklist gives a support or CX lead the evidence needed to make that call.

The working document is simple: one owner, one result for every check, and one link to the evidence. A green status without a screenshot, test record, export, or reviewer decision is not a pass.

Set the migration owner and go/no-go rules

Name three people before testing starts:

• The support or CX lead who owns the migration.
• The person who approves production launch.
• The person who can trigger rollback without waiting for a committee.

Create one migration sheet. Give every check these columns:

Check	Owner	Status	Evidence	Result	Retest date
Conversation export	Support operations	In progress	Restricted export location	Pending	2026-07-29
Refund answer	CX lead	Not started	Test transcript	Pending	2026-07-29
Order lookup action	Engineering	Not started	Test record and response	Pending	2026-07-29
Human handoff	Support manager	Not started	Shared inbox thread	Pending	2026-07-29
Rollback	Launch owner	Not started	Runbook and screenshot	Pending	2026-07-29

Set the launch gate before anyone runs a test. Do not cut over when knowledge sources, integrations, widget behavior, human handoff, or rollback evidence is incomplete.

Separate what can travel from what must be rebuilt. Conversation exports, written policies, FAQs, brand copy, and API documentation are portable assets. Routing rules, visual settings, triggers, authentication, and action mappings depend on the destination platform and need their own review.

That distinction prevents a common failure: a team imports a file, sees a successful upload, and assumes the new agent understands the business rules. A file transfer proves only that the file arrived.

Export the assets that can travel

Start with the source system, not the destination agent. Export conversation history, unresolved questions, saved replies, FAQs, agent instructions, escalation rules, and the analytics needed for a before-and-after comparison.

Preserve the fields the source system makes available:

• Timestamps
• Conversation IDs
• Tags
• Language
• Resolution status
• Assigned team or owner

Store the export in a restricted location. Record who accessed it and when. If the export contains personal data, apply the access and retention rules your company uses for customer records. The European Commission’s data protection guidance is a useful reference for the responsibilities that apply when personal data moves between systems.

Build an inventory that gives each asset one status:

Asset	Treatment	Review question
FAQ article	Imported or rewritten	Does the destination agent retrieve the right answer?
Saved reply	Rewritten	Is the wording still accurate outside the old workflow?
Escalation rule	Rebuilt	Does the conversation reach the right person?
API documentation	Imported and reviewed	Does it describe the endpoint and required fields?
Obsolete campaign flow	Retired	Could this create an outdated answer after launch?

Select the test set from real conversations. Include common questions, ambiguous questions, policy-sensitive requests, lead requests, and conversations that required a human. Keep the original transcript beside the new result so the reviewer can judge more than whether the answer sounds fluent.

A useful test record includes the question, the expected answer, the new answer, the source used, the reviewer decision, and the reason for any failure. This becomes your baseline for the first week after launch.

Rebuild the knowledge base and agent behavior

Turn approved material into destination training sources. AssistLoop supports website pages, uploaded PDF, DOCX, and TXT files, pasted text, and exact Q&A pairs through its training on your own data tools. The four source types give you different levels of control.

Use website pages and uploaded documents for material that changes across a set of published content. Use pasted text when the approved source is shorter or does not exist as a file. Use exact Q&A pairs for refund terms, eligibility rules, account policies, and wording where a small change could create a support or compliance problem.

Do not test only the happy path. Run the same questions from your selected test set against the rebuilt agent and record:

Test result	What to record
Correct answer	Answer, source, reviewer, and timestamp
Incomplete answer	Missing detail and approved replacement
Refusal needed	Question and the safe handoff response
More information needed	Detail the agent should request
Human handoff needed	Trigger, destination, and transcript

Write down what the agent must refuse to answer. Do the same for questions that require more information and questions that must go to a person. A policy-sensitive answer can be factually close and still be wrong for your business.

If content changes after training, rerun the affected test questions. AssistLoop’s training page states that the agent retrains automatically when training content changes. Record the changed source and the retest result in the migration sheet.

Set a go decision only when the reviewer can connect each important answer to an approved source. A confident answer with no acceptable source is a failed test, even if the wording looks good.

Recreate integrations and actions one by one

List every workflow the old chatbot could trigger. Include lead capture, meeting booking, account lookups, order status requests, and API calls. Do not rely on a flow diagram that omits the fields passed between systems.

For each integration, record:

Field	Example of what to document
Connected service	CRM, calendar, order system, or internal API
Endpoint or connection	URL, OAuth connection, or named integration
Authentication	Token, OAuth, signed request, or other method
Required fields	Email, order number, meeting type, or account ID
Expected response	Success data the agent can state to the customer
Failure message	What the customer sees when the service rejects the request
Owner	Person who fixes the connection after launch

Rebuild each action with test records first. AssistLoop Agent Actions can call REST endpoints using GET, POST, PUT, PATCH, and DELETE methods. Confirm that the destination agent sends the right fields, handles an error response, and does not claim success when the action failed.

Run these failure tests before production:

• The customer submits the same request twice.
• A required customer detail is missing.
• The session expires before the action completes.
• The API responds slowly.
• The request is unauthorized.

For an order status action, a pass means the test order returns the expected status and the transcript shows that status. A failed API call must produce a clear next step or human handoff. It must not produce a success message based on the action request alone.

Test the widget, handoff, and customer journey

Test the widget on the pages where customers use it. Check desktop and mobile layouts, opening behavior, colors, greeting, avatar, suggested replies, and dark mode when enabled.

Then test the page around the widget. It must not cover checkout controls, account navigation, cookie notices, or another action the customer needs. Check keyboard navigation and readable contrast against the site design. The W3C Web Content Accessibility Guidelines provide the reference criteria for this review.

Use widget customization to check the visual settings that are part of the customer path. A widget that looks correct on the homepage can still block a form or become unreadable on a darker product page.

Start a human handoff from a real customer path. Confirm that the team receives the full thread and the available visitor context. Reply from the shared inbox or mobile app, then confirm that the customer sees the reply in the same conversation. The human handoff feature is the relevant destination for this check.

Test handoff when the visitor:

• Requests a refund.
• Disputes a charge.
• Reports a broken account action.
• Repeats the same question after an incorrect answer.

Use a pass or fail table for each scenario:

Scenario	Pass condition	Evidence	Result
Mobile FAQ	Answer is readable and the page remains usable	Mobile screenshot and transcript	Pass or fail
Refund request	Policy response is correct or the thread reaches a person	Transcript and inbox thread	Pass or fail
Broken account action	Agent does not repeat a failed action and offers handoff	Error response and transcript	Pass or fail
Lead capture	Required details are collected once and stored correctly	Test lead record	Pass or fail
Handoff	Team receives the thread and available visitor context	Shared inbox or app screenshot	Pass or fail

The widget appearing on the page is not a launch result. The customer must complete the intended path and reach a person when that path breaks.

Cut over with a rollback plan you can execute

Run the old and new experiences in parallel for a defined test window. Keep the old configuration available and documented while the new agent handles the selected test set.

Choose the cutover trigger before launch. Examples include a completed set of passing tests, a reviewer approval, and a scheduled deployment time. Name the person authorized to roll back and write the exact action that restores the previous widget or routing configuration.

Save these items before cutover:

• Old widget settings
• Agent configuration
• Integration values
• Knowledge sources
• Deployment timestamp
• Rollback instructions

Store the instructions where the on-call owner can reach them. A rollback plan that exists only in a meeting note is not executable.

During cutover, test one known FAQ, one policy-sensitive question, one action, one lead capture flow, and one handoff before announcing completion. Record each result with a timestamp and screenshot.

If any critical path fails, roll back. Do not ask customers to work around a broken action or tell support to monitor a handoff that has not been proven. The launch decision belongs to the evidence in the migration sheet.

Review the first week before closing the migration

Compare the selected test set with live conversations from the first week. Look for unanswered questions, incorrect policy wording, failed actions, repeated handoffs, and customers abandoning the chat.

Review conversation logs for two types of follow-up:

1. Content that belongs in the knowledge base.
2. Questions that should become exact Q&A pairs.

Keep the migration sheet open until every failed test has an owner, a fix, and a retest result. Do not close the project because the widget stayed online. Close it when the failed paths have evidence showing that they now pass or have been intentionally retired.

Check message-credit usage against the expected traffic pattern. AssistLoop counts each user message and each AI response as one message credit, and credits do not roll over. Record the starting balance and usage when the migration begins, then compare that record with the first week’s conversations. Review AssistLoop pricing and message credits before setting the expected usage threshold.

Last verified: July 2026

If your team needs multi-channel support for WhatsApp, Telegram, Instagram, or Messenger today, AssistLoop is not the right fit for that requirement. Those channels are listed as coming soon, so keep the migration scoped to the supported site and workflow experience.

What to do instead

Use the migration sheet as the launch runbook:

1. Assign the migration owner, launch approver, and rollback owner.
2. Export the source assets and mark each one imported, rewritten, replaced, or retired.
3. Rebuild training sources, integrations, widget settings, and human handoff.
4. Attach a test result and evidence link to every critical path.
5. Cut over only after the launch approver confirms that rollback can be executed.
6. Review production conversations for the first week and retest every failed path.

Once the checklist passes, create an AI agent and use the same evidence-based cutover process for future site or workflow changes.

FAQ

How long should the old chatbot remain available after migration?

Keep the old configuration available through the first production checks and the agreed review window. It gives you a known recovery path if a customer journey fails after launch.

Should migration testing use real conversations or synthetic questions?

Use both. A scripted test set proves that known paths still work, while live conversations reveal questions and wording problems that the team did not include in testing. Review both before closing the migration.

Who should approve a chatbot migration?

The migration owner should make the recommendation, but the named launch approver should make the final go decision. The person who can roll back must have authority to act without waiting for the next meeting.

How should customer data be handled during a chatbot migration?

Keep the export restricted, record access, and apply your company’s retention rules to customer records. Remove data that the destination agent does not need instead of moving every historical transcript by default.