- Cisco migrations fail on ICM routing complexity more than on telephony.
- Most Cisco estates carry substantial CVP dead code. Migrating it multiplies cost and testing effort for no benefit.
- Compliance-bearing prompts must be preserved verbatim, never paraphrased by a generative model.
- A single cutover weekend has no rollback. Traffic shifting is the control that makes zero downtime real.
- Agent readiness and workforce management reconfiguration are frequently the true critical path and are rarely on the plan at kickoff.
Undocumented ICM routing logic
Cisco ICM routing scripts accumulate. A ten-year-old estate typically holds scripts written by engineers who have left, referencing peripheral variables whose meaning is no longer recorded, with conditional branches nobody can explain. The scope of a Cisco migration is set here, not in telephony.
The exposure is that a manual migration reconstructs this logic from interviews. Whatever the interviews miss becomes a misrouted call after cutover, and misrouted calls in a regulated environment are incidents, not defects.
The control is read-only automated discovery. Ingest the ICM scripts, CVP applications and peripheral configuration directly and produce a complete call-path inventory before anyone designs anything. You cannot manage a risk in logic you have not read. The estate itself is documented in the Cisco contact center product family reference.
Migrating CVP dead code
Cisco Unified CVP estates commonly contain call paths that carry no traffic. Discontinued product lines, retired campaigns, test flows promoted to production years ago.
Migrating them is pure cost. Each dead path consumes design, build and test effort, and every one increases the surface area you have to regression test before cutover.
The control is attaching volume data to the call-path inventory during discovery. Anything with no traffic over a full seasonal cycle gets explicitly retired, with business sign-off, before transformation begins. This routinely removes a meaningful fraction of the apparent scope.
CTI and integration breakage
Cisco contact centers are usually wired deeply into the enterprise. Finesse desktop integrations, CRM screen pops, host adapters into core banking or policy systems, payment and fraud services.
In Amazon Connect these become Streams API integrations and Lambda functions, and each one is a separate validation cycle with a separate owning team. Integration count is the most reliable predictor of schedule slip on any migration.
The control is to produce the integration map during discovery, freeze it at the end of the discovery phase, and assign a named owner in each downstream system before transformation starts. Integrations added mid-build are the single most common cause of a missed cutover date. Queue and routing-profile behavior is set out in the Amazon Connect administrator guide.
Losing speech recognition coverage
Cisco estates running speech self-service carry tuned grammars, sometimes with years of accumulated coverage for accents, product names and caller phrasing.
Converting those into Amazon Lex intents and slot types is straightforward for directed dialogue, where the vocabulary is bounded. Open-ended natural language recognition is a different matter, and expecting day-one parity there is unrealistic. The conversion targets are described in the Amazon Lex developer guide.
The control is to extract grammars during discovery, convert them into seed training utterances, and plan an explicit tuning window after go-live. Set the expectation with the business before cutover rather than defending a containment dip afterwards.
Altering compliance-bearing prompts
Regulated disclosures, recording notices and consent language are legally exact. A generative model that improves the phrasing of a disclosure has created a compliance incident.
The control is a hard rule enforced in the transformation phase: compliance-bearing prompts are lifted verbatim from discovery and routed to legal for sign-off against the original wording. They are never regenerated.
Identify these prompts during discovery and tag them in the inventory. Treating this as a review step at the end of build is how it gets missed.
Agent and operations readiness
This is the risk that is almost never on the migration plan and frequently determines the actual go-live date.
Moving from a Cisco Finesse desktop to Amazon Connect changes the agent workflow, the reporting model and the workforce management inputs. Supervisors lose familiar real-time views. Historical reporting has to be rebuilt, and the business will compare new numbers to old ones that were calculated differently. This is a recurring pattern in enterprise migration programs.
The control is to run the operations workstream in parallel with discovery rather than sequentially after build. Rebuild the reporting definitions during discovery, using the same call-path inventory, so that day-one metrics are explainable.
Cutover without rollback
A single cutover weekend is not a migration plan, it is a bet.
The control is traffic-shifted cutover. DIDs move in controlled percentages with both Cisco and Amazon Connect live in parallel, so rollback stays available at every increment and each step validates against real traffic before the next one runs.
Insist that this is written into the statement of work with defined rollback triggers. Zero downtime is a claim. Traffic shifting with a stated rollback threshold is a commitment.
Surface all seven risks in the first fortnight
Read-only discovery reads your ICM scripts and CVP applications without touching production traffic.
What retiring these risks costs in time
Handled manually, this risk register is what produces an 8 to 18 month program with 8 to 14 engineers on time and materials, landing somewhere between $200K and $2M. That is the shape of most system integrator delivery quotes.
Handled through automated discovery and generated flows, the same register is retired inside a 45-day window with 2 to 5 engineers on a fixed fee from $25K. Discovery runs days 1 to 14, Contact Flow JSON and Lex intents are generated days 15 to 30, and traffic-shifted cutover begins on day 31.
The difference is not that the risks disappear. It is that discovery surfaces them in the first fortnight, while there is still time and budget to do something about them, rather than in month nine. The timing pressure itself is covered in our Cisco end of life crisis briefing, and the underlying dates are published in Cisco's Cisco end-of-life and end-of-sale listing.