Migrating from a legacy chatbot or IVR to an AI agent

To migrate from a legacy chatbot or IVR to an AI agent, inventory every flow and menu option, classify each one as a knowledge answer, a workflow with actions, a route to a human, or something to retire, and rebuild only what earns its place. Then run the AI agent in parallel without customer-facing replies, cut over one channel or customer segment at a time, and keep a tested rollback for every slice until the old system is switched off. This playbook works for any AI support agent and for both chat and phone. The biggest risk in these projects is not the new agent: it is losing something the old system did quietly, such as an authentication step, a routing rule or a tag a report depends on.

​

Why migrations go wrong

Scripted bots and phone menus encode years of decisions. Some are real policy (“callers about fraud go straight to the fraud team”), some are workarounds for the old system’s limits (“press 4 to repeat the menu”), and some nobody remembers the reason for. Teams that rebuild everything copy the workarounds into the new agent. Teams that rebuild nothing lose the policy. The work is telling them apart.

​

The phases

​

Phase 1: Inventory old flows and menus

Export or document every chatbot flow and every IVR menu path. For each one, record: Sort by volume. A small number of flows usually carries most of the traffic, and those deserve the most care. Do not skip flows that transfer immediately: an option that sends callers straight to a specialist team often encodes a policy decision.

​

Phase 2: Classify each flow

Every flow gets exactly one destination. Two notes on classification:

• Menus mostly disappear. A topic menu exists because the old system could not understand free text or speech. An AI agent can, so the menu itself is usually retired. What survives is whatever happens after the customer picks an option.
• Policy-driven routes stay explicit. “Fraud goes to the fraud team” should be a written rule in the new agent, not something you hope it infers.

​

Phase 3: Keep what works

A migration is not a rewrite of everything. Keep the parts of the old setup that are doing their job:

• Authentication. If callers already verify identity through a PIN, one-time code or account lookup, reuse the same check in the new workflows rather than designing a new one. Changing authentication and the support agent at the same time doubles the risk. Check your regulator’s and your security team’s requirements before changing any verification step.
• Routing to specialist teams. Queue names, skills and hours that work today should map one to one onto the new agent’s escalation rules.
• Tags and reporting fields. If dashboards or triggers depend on tags the old bot set, make the new agent set equivalent tags, or update the reports before cutover.
• Approved wording. Disclosures, legal notices and recorded-line announcements keep their approved text.

​

Phase 4: Data and integrations

List every system the old flows read from or write to, and decide how the new agent will reach each one. Write actions need the most care. Until cutover, point them at a sandbox or test account, or keep the workflows that use them switched off during the parallel run. A parallel run that issues real refunds is not a parallel run. Also plan for transcripts and history: where conversations from the old system are stored, how long you keep them, and whether the new agent or your team needs access to them. Check retention requirements for your industry.

​

Phase 5: Run in parallel

Before the AI agent answers a single customer, run it alongside the old system:

• The AI agent sees real conversations and drafts the reply it would have sent, visible only to your team (for example, as an internal note in your helpdesk).
• The old system, or your team, keeps serving customers as today.
• Reviewers compare the AI agent’s drafts with what actually happened, mark the wrong ones and fix the knowledge or workflow behind them.
• Good and bad examples become regression test cases that you rerun after every change.

For phone, the equivalent is testing calls end to end with internal callers and scripted scenarios before routing any real customer calls. Exit the parallel run when the drafts on your top flows are consistently correct and your regression cases pass, not when a date arrives.

​

Phase 6: Cut over in phases

Pick slices that are easy to switch and easy to watch:

• By channel: chat first, where feedback is fast, then email, then phone.
• By segment: one brand, region, product line or customer tier at a time.
• By hours: after-hours traffic first, when the alternative is often no service at all.

For each slice: turn off the old system there, turn on direct replies from the AI agent, send test conversations, and assign someone to watch the first days of real traffic. Only one system should answer on any slice. Two bots answering the same customer produces two answers and metrics nobody can trust.

​

Rollback plan

Write the rollback for each slice before you cut it over: Keep the old system available, but switched off, until every slice has been stable for a period you agree on in advance.

​

Communicating with the team

The support team will notice the change before customers do. Tell them:

• What the AI agent handles, what it routes to them, and what changes in their queues.
• How escalated conversations arrive, and what context comes with them.
• How to flag a wrong answer, and who fixes it.
• The cutover schedule and the rollback trigger, so nobody is surprised.

Involve team leads in reviewing parallel-run drafts. They know which old flows matter, and they will catch problems faster than anyone.

​

Common mistakes

• Rebuilding every menu option as a workflow instead of retiring what the AI agent no longer needs.
• Changing authentication at the same time as the support agent.
• Running write actions against production during the parallel run.
• Letting the old bot and the new agent reply on the same conversations.
• Forgetting reports, tags and triggers that depended on the old system.
• Switching off the old system before a rollback has been tested.

​

Doing this in Fini

In Fini (usefini.com), the migration phases above map to these features:

• Migrate from Zendesk bots to Fini walks through this process on one helpdesk end to end, including Bot Routing for cutting over brand by brand.
• Rebuild workflows with actions as behavior trees in Rulebook → Intent Rules, with Read, Form and Tool nodes. See Intent Rules.
• Run the parallel phase with an Internal Comment rule in Rulebook → Reply Rules, add a No Reply rule for human-owned conversations, and roll a slice back by returning it to Internal Comment. See Reply Rules.
• For phone, configure the agent from Voice in the agent sidebar, then click Start test to run a Voice test call in the browser before any real calls: follow the live transcript and call status, and click End call to finish and review the transcript before closing the dialog (closing it ends the call and clears the transcript). Coordinate phone numbers and call routing with your Fini contact. See Fini on voice.
• Review drafted replies and calls in Inbox, and use the flask icon to turn the conversations that matter into Test Suite test cases. Group them into a collection for the migration and run it after every change. Test Suite uses recorded or mock Action responses, so check rebuilt write Actions end to end in a sandbox before cutover.

​

Related