Avaya Migration  /  Google CCAI Timeline

Avaya to Google CCAI Migration Timeline:
What 45 Days Actually Covers

An Avaya to Google CCAI migration takes approximately 45 days when discovery and flow generation are automated. Read-only discovery of the Avaya estate runs days 1 to 14, Dialogflow CX flow and intent generation runs days 15 to 30, and traffic-shifted cutover begins on day 31. Manual, SME-dependent migrations of the same estate typically run 8 to 18 months.

Published September 2026 Read time 8 min Published by Aumne AI
TL;DR
  • 45 days is the ingestion to production cutover window when discovery is automated rather than interview-based.
  • The single largest variable is not estate size, it is integration count. Each backend hook adds validation time.
  • Dialogflow CX suits complex Avaya IVR because its state machine architecture maps onto call-path branching more directly than a flat intent model.
  • Day 45 is a cutover milestone. Containment tuning continues afterwards and is where the business case is realized.
  • A manual program spends its first four to six weeks documenting an IVR that automated discovery reads in hours.
01 / The Short Answer

The short answer on timeline

Around 45 days from first ingestion to production cutover, assuming automated discovery and generated flows.

That figure is not a marketing average applied to every estate. It is the observed window on delivered migrations, and the two named Avaya programs on record landed at 42 days and 38 days respectively. Both were delivered by system integrators using the platform rather than by a consulting team rebuilding flows by hand. The full delivered migration results are published in our customer stories.

PhaseWindowWhat completesWho is involved
DiscoveryDays 1 to 14Full call-path inventory, integration map, grammar extraction, dead-code identificationRead-only platform access, one Avaya administrator for credentials
TransformationDays 15 to 30Dialogflow CX flows, pages, intents and webhook stubs generated from discovered logic2 to 5 engineers, business review of high-volume paths
Deploy and evolveDay 31 onwardsTraffic-shifted DID migration, parallel run, rollback windows, containment baselineTelephony and carrier coordination, CX operations
Post-cutoverContinuousIntent-drift monitoring, containment tuning, utterance retrainingPlatform monitoring plus CX team

The estate being moved is the same one described on our Avaya migration page: Experience Portal, Orchestration Designer projects and VDN-based routing.


02 / Discovery

Why the first fourteen days decide the whole schedule

In a manual migration, the first four to six weeks are spent reconstructing what the IVR does. Engineers interview subject matter experts, read Orchestration Designer projects that have been patched for a decade, and try to work out which of several hundred call paths still carry traffic.

That phase is the schedule. Everything downstream inherits its gaps, and every gap becomes a production defect discovered after cutover.

Automated discovery replaces the interviews with read-only ingestion. The platform reads every flow, VDN routing rule, integration hook and speech grammar directly from the live estate and produces a call-path inventory in hours to days. The fourteen-day window in the table is mostly review time, not extraction time. You are validating the inventory with the business, not building it.


03 / Schedule Risk

What makes a migration take longer than 45 days

Estate size matters less than most sponsors assume. These five variables matter more.

  1. 01
    Integration count.
    Every CRM lookup, host adapter, payment gateway and fraud check needs a webhook and its own validation cycle. Twenty integrations extends the transformation phase more than two thousand extra call minutes ever will.
  2. 02
    Carrier and DID complexity.
    Number porting schedules sit outside your control. Start carrier conversations during discovery, not at cutover.
  3. 03
    Compliance-bearing prompts.
    Regulated disclosures cannot be paraphrased by a generative model. They need legal sign-off against the discovered wording, and that review is calendar time, not engineering time.
  4. 04
    Open-ended speech.
    Directed dialogue converts cleanly into Dialogflow CX intents. Open-ended natural language recognition needs retraining against real utterance data and a tuning window after go-live.
  5. 05
    Organizational readiness.
    Agent training, workforce management reconfiguration and reporting rebuilds are frequently the actual critical path, and they are rarely on the migration plan at kickoff.

Get your integration count before you commit to a date

Discovery returns the full integration map in 48 hours, which is the variable that actually moves the schedule.

Run a free IVR assessment

04 / Platform Fit

Why Dialogflow CX suits Avaya estates specifically

Avaya IVR built in Orchestration Designer is state driven. Calls move through defined nodes with explicit transitions, conditional branches and re-entry points.

Dialogflow CX uses a state machine model with flows, pages and transition routes, which maps onto that structure far more directly than a flat intent model does. Google's earlier Dialogflow ES lacked versioning, environment promotion, A/B testing and a test-case framework at the level CX provides, and those are exactly the controls an enterprise migration needs in order to validate hundreds of call paths before cutover. The mechanics are covered in our Dialogflow CX migration page, and in Google's own Dialogflow CX documentation and Dialogflow CX basics.

The practical effect on timeline is that generated flows need less structural rework. The transformation phase spends its time on integration wiring and prompt review rather than on rearchitecting the dialogue model.


05 / Cutover

What happens on day 45 and what happens after

Day 45 is production cutover, not project close.

Cutover itself is traffic-shifted. DIDs migrate in controlled percentages, both platforms run in parallel, and rollback stays available at every increment. That structure is what makes zero downtime achievable, and it is worth insisting on contractually.

After cutover, the work becomes containment tuning and intent-drift monitoring. Containment is the proportion of contacts resolved fully in self-service without an agent. Aging Avaya IVRs often sit in the low twenties. A tuned post-migration deployment commonly reaches around 65 percent, and the gap between those two numbers is where the return on the program sits. Google's Google Cloud contact center solutions pages set out the wider CCAI positioning.


06 / Accountability

How to hold a vendor to the timeline

  1. 01
    Ask for the discovery output before contract signature, not after.
    A vendor that cannot show your call-path inventory has not automated discovery.
  2. 02
    Require the plan to state which days are engineering time and which are your review time.
    Sponsors miss dates because nobody scheduled the business review.
  3. 03
    Get the integration list frozen at the end of discovery.
    Integrations added during transformation are the most common cause of slip.
  4. 04
    Ask for the rollback definition in writing.
    Zero downtime and traffic shifting are not the same commitment.
  5. 05
    Confirm whether post-cutover containment tuning is included or is a separate engagement.
    On a time and materials program it usually is separate.

The same accountability questions apply across enterprise migration programs, whatever the destination platform. For the wider method, read our IVR transformation guide. The VXML layer being converted is defined by the W3C VoiceXML 2.0 specification.

Frequently asked questions

How long does an Avaya to Google CCAI migration take?

Around 45 days from first ingestion to production cutover when discovery and flow generation are automated. Discovery runs days 1 to 14, Dialogflow CX transformation days 15 to 30, and traffic-shifted deployment from day 31. Delivered Avaya programs have landed at 38 and 42 days.

Why do manual Avaya migrations take 8 to 18 months?

Because they begin with four to six weeks of manual documentation. Engineers interview subject matter experts to reconstruct undocumented IVR logic, and the gaps in that reconstruction surface later as production defects that extend testing. Manual programs also need 8 to 14 engineers against 2 to 5 on an automated one.

What is the biggest cause of migration delay?

Integration count, not call volume or estate size. Every CRM lookup, host adapter and payment gateway needs its own webhook and validation cycle. Freezing the integration list at the end of discovery is the single most effective schedule control available to a program manager.

Is Dialogflow CX better than Dialogflow ES for Avaya migrations?

For enterprise IVR, yes. CX uses a state machine of flows and pages that maps onto Avaya's state-driven call paths, and it adds versioning, environment promotion and a test-case framework. ES uses a flat intent model without those controls, which makes validating hundreds of call paths considerably harder.

Can the migration run without downtime?

Yes, when cutover is traffic-shifted. DIDs move in controlled percentages while both platforms run in parallel, keeping rollback available at every increment. Ask any vendor to define rollback explicitly, because a single cutover weekend offers none.

What does the timeline look like after day 45?

Continuous containment tuning and intent-drift monitoring. Containment on an aging Avaya IVR is often in the low twenties, and a tuned deployment commonly reaches around 65 percent. That improvement accrues over the weeks after cutover, not on cutover day itself.

Scope Your 45 Days Before You Commit to a Date

Discovery returns your call-path inventory and integration map in 48 hours, so the delivery date you defend is based on your estate, not an average.

Book Free Assessment Explore the ACT Platform