Legacy IVR replacement: migrating off Nuance-era platforms to modern voice AI

Why lift-and-shift fails

Grammar-and-prompt IVR assets encode a different interaction model than a generative voice agent. Slot-filling grammars, recognition thresholds, and confirmation prompts assume a turn-based, recognition-first architecture. A generative voice agent expects to plan and converse. Porting the prompts produces a worse generative agent than starting from the intent specification.

The reusable artefacts are upstream of the IVR: the intent taxonomy, the call-driver analysis, the integration map, and the recorded call corpus. Those compound. The flow files themselves are largely throwaway.

The four-phase migration

A defensible enterprise migration runs in four phases. The aggressive timeline is nine months for a focused programme; eighteen is realistic for a regulated enterprise with multiple business units.

1. Discovery (weeks 1–6): Pull the legacy call-driver report, label the top 20 intents by volume and value, map each to the systems of record it touches, and rank by migration tractability.
2. Foundation (weeks 4–12): Stand up the new platform, build the integration layer to the top three systems of record, and implement observability, evaluation, and the kill switch before any intent is cut over.
3. Per-intent migration (months 3–12+): For each prioritised intent, build on the new platform, parallel-run against the legacy flow on a percentage of traffic, gate on measured containment and CSAT, then cut over and decommission the legacy flow.
4. Decommission (final 1–3 months): Wind down legacy licences, archive grammars and prompts for audit, and transfer remaining low-volume intents to the new platform or retire them.

The per-intent cutover gate

Each intent gets cut over only when it passes a written gate. The gate is not 'the new flow works'; it is 'the new flow performs at parity or better on the metrics the business measures the legacy flow on.' Without a written gate, scope creep and political pressure decide cutover order, which is how migrations stall.

• Measured containment at or above legacy baseline on a representative call sample
• CSAT at or above legacy baseline over a minimum 14-day window
• 7-day re-contact rate at or below legacy baseline
• Integration error rate within agreed tolerance on the systems of record
• Audit trail evidenced for a sampled set of calls including any vulnerability or compliance edge case

The operating-model shift

A legacy IVR is owned by a small team of specialists who change it monthly via a release process. A generative voice agent is owned by a cross-functional pod that ships changes weekly, monitors call-level metrics daily, and reacts to drift in hours. The org chart has to change before the technology does, or the new stack reverts to legacy operating cadence and stops improving.

The single most common reason 'modern voice AI' programmes underperform is that the operating-model change was deferred to phase two and then never happened.

What to negotiate into the new contract

Use the migration as commercial leverage. The vendor wants the logo; you want the optionality.

• Exit assistance: a written commitment to export call data, transcripts, intent labels, and configuration in machine-readable form at any point during the contract.
• Per-resolution pricing on at least one intent: transfers containment risk to the vendor and produces a clean economic comparison against the legacy baseline.
• Operating-model SLA: defined response times for vendor-side issues that block your weekly release cadence, not just for platform incidents.