Changing CCaaS Platforms? Decide When Voice AI Joins the Migration

Your contact-centre platform contract is ending, the replacement is chosen or nearly chosen, and someone has asked the obvious question: should we add voice AI now, as part of the move, or once the new platform has settled? Each answer has a cost. Add it too early and you build an integration you will tear out. Add it during cutover and you change two things at once. Wait too long and you rebuild the IVR twice. Six dependencies decide the order. Most teams already know them, but they rarely line them up against each other. This guide does that, works through a fictional example, and ends with a one-page memo you can take to IT and procurement.

One distinction makes the decision much easier. Part of the voice AI work is platform-independent: choosing which calls to automate, writing the knowledge, defining handoff rules and agreeing acceptance criteria. That work can start now, whatever you decide. The platform-dependent part is where the AI leg attaches, how numbers route to it, and where recordings and reports land. That is the part you have to sequence.

Three sequencing options and what each one risks

Before the migration. Integrate voice AI with the platform you are leaving, run it, then move it across with everything else.

• Gains: earlier learning on real calls; evidence for the business case before the new contract is signed.
• Risks: the integration, routing and reporting work is redone on the new platform. Live AI traffic also changes your call mix and handle times just as you need a clean baseline to judge the migration.

During the migration. Design the AI entry point into the new platform's routing and IVR from the start, and build the integration in the same project, but switch on AI traffic only after cutover has stabilised.

• Gains: numbers, routing, IVR, recording and reporting are designed once. Trunk capacity and licences for the AI leg go into the new contract.
• Risks: the migration team takes on more scope. If AI design decisions slip, they can hold up the cutover plan unless they are kept on a separate track.

After the migration. Finish the move, let operations settle, then add voice AI as a separate project.

• Gains: one change at a time; the cleanest attribution of results.
• Risks: the IVR and routing just rebuilt are opened up again, and contract terms for AI-related capacity are negotiated after you have lost leverage. Months of automatable volume keep going to agents.

None of these is right by default. The dependencies below decide it.

Six dependencies that decide the order

1. Number routing. Where do your numbers terminate today, and will they move to new carriers or trunks in waves? If they are being ported or re-pointed, put the AI entry point into the new routing plan. Don't route numbers to an AI on the old platform only to move them again weeks later. Usually favours: during (design).

2. SIP and carrier. The AI leg has to attach somewhere, typically as a SIP destination that the platform routes calls to and receives them back from. Concurrent AI calls take trunk capacity, so the new contract should cover that capacity, plus test numbers and the route back to agent queues. Usually favours: during.

3. Recording and QA. Decide where recordings and transcripts of AI-handled calls are stored, who reviews them, and how the QA form scores a call that started with the AI and ended with an agent. Keep the recording notice your compliance owner has approved, and agree any change explicitly rather than as a side effect of the migration. Usually favours: during.

4. Reporting baseline. Migrations change metric definitions: when a call counts as abandoned, how transfers are counted, where handle time starts. If you want to judge voice AI later, capture several weeks of baseline on the old platform now, by call reason. Then map each metric to its definition on the new platform. Favours: before (data only, no AI traffic).

5. IVR rebuild. Most migrations rebuild menus and routing logic anyway. That is the cheapest moment to decide which menu option, or which call reason, goes to the AI first. Doing it after cutover means a second IVR project. Favours: during.

6. Contract dates. How long until the old contract ends, and how much overlap is there between platforms? With a long runway, a limited trial on the old platform can be justified if the integration is light, for example a single routed leg. With a short runway, anything built on the old platform is rework. Can favour before or after; it decides how much the other five matter.

Worked example: a contract that ends in 14 months

The following is a fictional contact centre, used only to show the method.

• 14 months until the current platform contract ends; the new platform is chosen in month 4.
• Build from month 5 to month 10; numbers move in two waves in months 9 and 10; full cutover at the end of month 10; old platform kept read-only until month 14.
• Call-reason sample: order status and delivery-date questions make up the largest routine share, and the team wants those handled by the AI first.

Applying the six dependencies:

Dependency	Finding in the example	Decision
Number routing	Numbers move in waves in months 9–10	AI entry point goes in the new routing plan
SIP and carrier	New trunk contract still being negotiated	Add AI-leg capacity, test numbers and the return route to the contract
Recording and QA	New recording store chosen in build	Define AI-leg recording, transcript storage and a joint QA form now
Reporting baseline	Old reports define transfers differently	Export six weeks of baseline by call reason before month 5
IVR rebuild	Menus rebuilt in months 6–8	Design the order-status branch to route to the AI from day one; keep it switched to agents
Contract dates	14 months, little slack	No AI integration on the old platform

Why not "before"? With 14 months left and the build starting in month 5, an integration on the old platform would run for less than a year. It would then be rebuilt, and it would disturb the baseline the team needs to judge the migration. Why not "after"? The IVR is being rebuilt in months 6–8 anyway, and the trunk contract is open now. Waiting would mean a second IVR project and a contract change later, at the provider's price. "During" is the cheapest place for the design work. But switching on AI traffic in the same weeks as the number moves would make any problem in month 10 impossible to trace to one cause.

Decision: platform-independent work starts now (call reasons, knowledge, handoff rules, acceptance criteria). Platform-dependent work is designed during the build. AI traffic starts after cutover, once the agreed stability checks hold, and begins with order status only.

Here is the counterexample. If the same centre had 30 months left and the new platform had not been chosen, a capped trial on the old platform through a single routed leg could make sense. Its findings would feed the platform selection. Only that one leg would need rework.

What to test at each stage

Test each stage before the next one starts. Keep a short written expected result for each test, and record the actual result.

Stage	Test	Pass looks like
Design	Paper walk-through of one call per AI scenario	Every branch ends at the AI, an agent queue or a callback
Build, before cutover	Test call through the AI, then a transfer	The call reaches the agent queue with the caller's details and summary; the caller isn't asked to repeat them
Build, before cutover	AI destination made unavailable	Calls go to the agreed human queue; an alert reaches the named owner
Cutover	Each moved number dialled once	Routes to the planned destination (AI branch still switched to agents)
After cutover	AI branch enabled for a small share of one call reason	Recording, transcript, reporting tag and QA record present for each AI-handled and transferred call

Give each test an owner on both sides, the platform team and the AI provider, and run it in the build environment with test numbers before anything touches live traffic. Decide in advance what a failure means. A failed pass-through or fallback test stops the AI branch, not the migration: the branch stays switched to agents and the cutover goes ahead. That separation is what lets the migration team accept the AI work in their plan without taking on its risk.

Keep the evidence: the test call's time, the number dialled, where it landed and what the agent saw on screen. When results are argued about later, especially transfer quality, a recorded test with a timestamp settles the question faster than anyone's memory of it.

The pass-through test, where a call goes through the AI agent and returns to the human agent queue without changing your numbers or routing, is the core of this kind of integration. If that doesn't work in the build environment, don't put it on the cutover plan.

A decision memo for IT and procurement

Keep the memo to one page:

• Decision: before / during / after, and the date AI traffic may start.
• Platform-independent work starting now: call reasons in scope, knowledge owner, handoff rules, acceptance criteria.
• Six dependencies: one line each, giving the finding and what it decides.
• Contract items: AI-leg trunk capacity, test numbers, the return route to agent queues, and recording and transcript storage.
• Tests and owners: the table above, with a named owner for each row.
• Stop rule: what would move AI traffic to a later date, such as failed fallback tests or reporting tags missing after cutover.

If you are evaluating NextLevel for the AI layer, it connects to existing contact-centre platforms over SIP. The SIP Bridge page describes the deployment modes NextLevel offers, from a routed sidecar leg to overflow and full front-of-queue handling. Compatibility with your specific platform and carrier still needs confirming in your environment. For qualified prospects, a working prototype is typically ready in about 2 weeks, and NextLevel then tunes it to your environment; that time is typical, not guaranteed, and enterprise rollouts like a migration are scoped separately.

Bring your migration timeline, the platform you are moving to, your carrier and the call reasons you would automate first to a scoping call; you can book one from the SIP Bridge page. We'll map the dependencies with you.

FAQ