Most of the contact centres still running on-prem in 2026 are running Avaya Aura, Cisco UCCX or Genesys Engage. The hardware is in a colocated cage somewhere, the SBCs are paired and aging, the dial plan has been edited by four generations of telecom engineers, and the IVR was last meaningfully rewritten in 2017. The reason these platforms are still in production is not that they are still the best fit for the workload. It is that the migration is hard, the integration depth is real, and every previous attempt to move stalled in the contact-flow rebuild or got vetoed by compliance.
Amazon Connect is now the default destination for these migrations. The platform has matured enough that the boring questions — number porting, SIP handoff, identity bridge, CRM integration — have settled answers, and the interesting questions — generative-AI agents over Bedrock, real-time supervisor assist, Contact Lens analytics — are where the actual operational uplift now lives. AWS published the Connect AI Agent feature general availability earlier in 2026, and the Bedrock-backed agent pattern is now well-trodden enough to be the reference architecture rather than the experiment.
What this piece is about is the engineering shape of the migration itself. Not the marketing case for moving. Not the AI capability that arrives once you have moved. The cutover. Where the SBCs land. How the contact flows get rebuilt. Which agent productivity dip is recoverable and which is structural. The day-two operations after the porting completes and the legacy gear gets decommissioned. And, with no marketing slop, where the migration goes wrong.
Key takeaways
- The migration architecture decomposes into four planes — voice transport (SIP trunk handoff or Direct Connect), identity (AD/Entra/Okta federation into Connect), CRM (Salesforce or Dynamics CTI via Connect Streams), and contact flows (Lambda-driven rebuilds of the legacy IVR). Get the planes wrong and the cutover slips by quarters.
- Dual-run with DNIS shadowing is the only cutover pattern that survives audit on regulated workloads; phased line-of-business migration is the default for everything else; big-bang is appropriate only when the legacy platform is already actively failing.
- The financial model inverts on day one — Connect bills per minute of usage, not per agent seat, which means seasonal and shift-pattern workloads can save 40-60% while always-on high-utilisation workloads barely move and occasionally cost more.
- The agent productivity dip during cutover is real and measurable — expect 15-25% AHT inflation for two to four weeks on Finesse-to-Connect Agent Workspace transitions, recovering to baseline within six to eight weeks if the training program is honest.
- Where the migration goes wrong is rarely the voice path. It is the IVR rebuild that no one budgeted, the CRM screen-pop nobody tested at port-cutover, and the supervisor reports that the business uses daily but no one mentioned in the requirements document.
Why teams are still on legacy in 2026
The honest read is sunk cost plus integration depth plus regulatory risk-aversion, in roughly that order.
Sunk cost shows up as fully-depreciated PBX hardware in a colocated cage that costs almost nothing to keep running, paired against a Connect bill that — even at favourable per-minute rates — looks like a new line item rather than a replacement for a cost that has been amortised down to staff and circuits. The CFO who signs off on the migration is the one who has to write a forward-looking three-year TCO that compares an apparent zero against a real per-minute spend. That comparison is winnable, but it is not free, and it is harder when the contact centre is not the strategic priority for the quarter.
Integration depth is the longer answer. A contact centre that has been in production for a decade has accumulated screen-pop integrations to half a dozen line-of-business systems, recording archives that compliance requires the search interface for, supervisor dashboards built in some forgotten BI tool that the workforce-management team checks every morning, custom CTI integrations into the CRM that everyone has forgotten how to extend, and a dial plan that handles seventeen edge cases nobody documented. None of this is in the platform contract. All of it has to be rebuilt or replaced on the new side.
Regulatory risk-aversion is the cap on speed. In regulated sectors — banking, healthcare, insurance, government — the auditor wants to know where the recordings live, who has access, how long they are retained, what the encryption posture is, and which jurisdiction the storage sits in. Connect answers all of these, but the answers are different from the on-prem answers, and they require a control-mapping exercise that nobody has time to do until the migration sponsor forces it through. The teams that are still on Avaya in 2026 are not unaware of the alternative. They are unable to clear the queue of dependencies fast enough to leave.
The migration playbook below assumes you have cleared that queue, or are about to.
The migration architecture
The architecture decomposes into four planes that you can scope and ship independently. Get the planes wrong — collapse them or skip one — and the cutover slips by quarters.
Voice transport. Two patterns work. SIP trunk handoff from your existing carrier into Connect via the AWS-managed inbound SIP endpoint, with the carrier doing the number porting on a per-DNIS schedule. Or Direct Connect from your data centre to AWS with SIP trunks running over the private circuit, which is the pattern that survives the strictest network-security postures because the voice traffic never traverses the public internet. Direct Connect adds three to six weeks of provisioning lead time and a circuit charge that runs $1,500-$5,000 a month depending on region and bandwidth, but for regulated workloads it is the only answer that the network architecture review will accept. For everyone else, the SIP trunk handoff is faster, cheaper, and operationally indistinguishable once it is running.
Number porting is the sequencing problem. Most carriers will port a number block within ten business days once the LOA is signed; some require thirty. The cutover plan needs to assume the longer number because one delayed port can stall the entire line-of-business migration it sits in. Do not port the main inbound number first. Port a low-volume test DNIS, verify the routing end-to-end, port a secondary line-of-business, then port the high-volume numbers last when you have run dual-flow for two to four weeks.
Identity bridge. Connect integrates with SAML 2.0 and now with OIDC. The clean pattern is to federate Connect against your existing IdP — Entra ID, Okta, or AD FS in the older deployments — and provision agent accounts via SCIM if your IdP supports it. The unclean pattern, which we still see in flight, is local Connect users mirrored manually from the directory by an ops team that has not been told the migration is supposed to remove that work. Federate from day one. The cost of un-doing local accounts later is steeper than it looks because every supervisor mapping and skill assignment has to be re-applied on the federated side.
CRM integration. This is the plane that almost always slips. If the existing contact centre is screen-popping into Salesforce or Dynamics via the legacy CTI adapter, the Connect equivalent is the Salesforce CTI integration (Service Cloud Voice if you want the deep-integration path, or the standalone CTI adapter for lighter touch) or the Dynamics Channel Integration Framework v2 bridge. Both work. Both require the same screen-pop URL parameters, the same call-attached-data conventions, and the same call-wrap logic on agent disposition. The trap is assuming the existing integration is documented well enough to be re-implemented. It usually is not. Plan for a two-to-four-week integration discovery before the rebuild starts, because the CRM team will not have looked at the CTI code since the original vendor walked away from it.
Contact flows. Connect contact flows are the new IVR. They are graphical in the console, executable as JSON, and trigger Lambda functions for anything beyond menu prompts and queue routing. The rebuild is where the engineering volume actually lives, and the rebuild gets its own section below.
The four planes are independent enough that you can prototype voice transport against a sandbox account, ship the identity bridge in parallel, scope the CRM integration as a separate workstream, and treat contact-flow rebuild as the long pole that drives the cutover date. Teams that try to land all four together hit dependency stalls. Teams that ship them as four parallel workstreams with a clear integration milestone at the end ship on time.
Contact flow rebuild — the engineering volume
What the Avaya IVR or the Cisco UCCX call script is, in Connect, is a contact flow plus a set of Lambda functions plus a Lex bot for any natural-language handling. The mapping is conceptually clean. The execution is where teams underestimate the work.
A legacy Avaya CCX script that takes a caller through "press 1 for billing, press 2 for technical support, press 3 for an agent" becomes a Connect Get Customer Input block, a few branch nodes, and three Transfer to Queue endpoints. That is the easy 20% of the rebuild. The other 80% is the conditional logic. The "if the caller is calling from a number we recognise as a high-value account, skip the menu and route directly to the dedicated team" branch. The "if the wait time in queue A is over four minutes, offer a callback or route to queue B" branch. The "if this is the third call from this number in the last hour, route to a supervisor" branch. The hours-of-operation logic that handles four time zones and ten public-holiday schedules.
All of this is executable in Connect, and most of it lives in Lambda functions invoked from the contact flow. The pattern that works is to write the Lambda functions as small, single-responsibility handlers that take the contact attributes as input and return a routing decision — getCallerSegment, getQueueDepth, shouldOfferCallback, checkBusinessHours. Compose the contact flow around the Lambda outputs rather than embedding the logic in the graphical flow itself. Graphical flows are unreadable past a certain size; Lambda code is testable.
Skill-based routing maps from the legacy skill groups to Connect routing profiles plus queues. The trap here is that the legacy platform almost certainly has more skill granularity than the business actually uses, because skill groups accumulate over time and never get pruned. Do the pruning during the migration. Talk to operations about which skills routed real volume in the last six months and which are vestigial. The Connect routing profile model rewards parsimony.
The Lex bot question is whether to keep the touch-tone IVR or move to natural-language. Most teams keep the touch-tone for the first cutover and add Lex in a phase two, because debugging a Lex bot against real caller utterances is its own multi-month engineering project. The exception is teams whose existing IVR contains-out at a rate that is itself a business problem — then Lex moves up the priority list, and the Connect AI Agent feature (announced earlier this year, generally available now) is a credible starting point for the generative path.
Cutover patterns
There are three patterns. They are not interchangeable.
Dual-run with DNIS shadowing. The legacy platform and Connect run in parallel for a defined window — typically two to six weeks per line of business. Inbound calls land on the legacy SBC, which forks a copy of the call leg to Connect via SIP. Connect receives the shadow leg, runs it through the new contact flow, and routes to a small population of pilot agents on the Connect Agent Workspace. The legacy platform handles the production call. This pattern gives you real call data, real routing behaviour, real agent feedback, and a defensible cutover date, all without exposing production traffic to the new platform until you are confident. It is the only pattern that survives audit on regulated workloads. It is also the most operationally complex, because two platforms are live and the WFM team has to manage agent capacity across both.
Phased line-of-business migration. Different parts of the business cut over on different dates. Customer service moves first, sales moves four weeks later, collections moves six weeks after that. Each line of business gets a clean port-cutover for its DNIS numbers, the agents in that line of business are trained, and the cutover happens at a defined date with the legacy queue going dark for that line. The benefit is operational simplicity inside each phase — one platform per line of business at any given time — at the cost of running two platforms in the organisation as a whole for the duration of the migration, which can stretch six to nine months for a large estate. This is the default for non-regulated workloads where the audit overhead of dual-run is not worth the operational simplicity.
Big-bang. Everything cuts over on one weekend. There is exactly one scenario where this is the correct answer: the legacy platform is already actively failing — the SBCs are out of vendor support, the agent desktops are crashing, the recording archive is corrupting — and the migration is the rescue, not the upgrade. In that case, big-bang is appropriate because the dual-run option does not exist. In every other scenario, big-bang concentrates all of the risk into one window, and the rollback story is "we revert to the platform we were already trying to leave," which is not a rollback story.
DNIS shadowing deserves its own paragraph. The pattern is that the SBC duplicates the inbound call leg — same caller, same dialled number, same call-attached data — and sends one copy to legacy and one to Connect. The Connect leg runs the new contact flow but does not terminate to a production agent. Either the Connect leg is connected to a pilot population of agents who handle the call in parallel (and the legacy agent is the customer-facing leg), or the Connect leg is recorded and analysed without an agent at all (silent shadowing). Both patterns produce comparison data — same call, two platforms, two routing outcomes — which is the data the cutover decision actually needs.
The agent UX migration
Avaya Workforce Optimisation, Cisco Finesse, Genesys Workspace Web Edition — these are not interchangeable products. They are not, however, irreplaceable. The Connect Agent Workspace is the default destination. The Custom CCP route, where you embed the Connect Contact Control Panel into your existing CRM screen, is the destination for teams that want to keep the existing CRM as the agent's primary surface.
The productivity dip is real, measurable, and recoverable. Expect Average Handle Time to inflate by 15-25% for the first two to four weeks after cutover. Expect first-call resolution to dip by a similar margin. Expect agent escalations to supervisors to rise sharply in the first week, then trail off. The recovery curve takes six to eight weeks to return to baseline, and the slope of the recovery is determined more by the training program than by the platform.
What the training program needs to cover, and what most miss: the new keyboard shortcuts (Finesse muscle memory does not transfer); the new way to put a caller on hold during a warm transfer (the affordance is different); the new way to access the call history (it lives in a different panel); the new way to flag a call for QA review (the supervisor reports look different on the back end); and the new way to handle a problematic caller (the disposition codes are not the same). None of this is platform deficiency. All of it is six years of accumulated workflow that has to be re-learned.
The teams that recover fastest are the ones that build a transition lab where agents spend two days working through real shadow calls on the new platform before their go-live date, supervised by a peer who has been on Connect for at least four weeks. The teams that take the longest are the ones that ship training as a slide deck and a 30-minute Zoom.
Day-two operations
Once the legacy platform is dark, the operations model changes shape.
Contact Lens is the analytics layer. Real-time call categorisation, sentiment analysis, agent assist surfaces. It is materially better than what most legacy platforms shipped, and it is also a separate per-utterance cost that did not exist on the previous TCO line. Budget for it. The same is true of Voice ID, real-time agent assist, and the Connect AI Agent feature if you adopt the generative path.
The billing surprise is the per-minute model. Connect charges for inbound minutes, outbound minutes, and per-message rates for chat and task channels. There is no per-seat licence cost. For seasonal workloads — retail, tax-season finance, healthcare open enrolment — the inversion is favourable because you stop paying for agents who are not on calls. For always-on, high-utilisation workloads — 24/7 technical support, regulated banking lines — the per-minute model can come out roughly the same as per-seat licensing or occasionally more expensive. Model both before you cut over. The financial model that worked on Avaya is not the financial model that works on Connect, and the CFO needs the new model in their hand before the first invoice arrives.
The headcount question is its own conversation. Legacy contact centres in regulated industries often have a back-office headcount — workforce management, telephony engineers, IVR developers, recording archivists — that is sized for an on-prem platform. Connect collapses some of that. The IVR developer role becomes a Connect contact-flow engineer plus a small Lambda team. The telephony engineer role becomes an AWS networking engineer plus a SIP specialist for the carrier edge. The recording archivist role mostly disappears, replaced by a Contact Lens analyst. The headcount question is not "do we still need a contact centre engineering team" — the answer is yes — it is "what does that team look like once the migration is complete." Be honest about this in the business case.
Where the migration goes wrong
The voice path is rarely where it goes wrong. SIP handoff is well-understood, number porting is operationally boring, the Direct Connect circuit either provisions or it does not. The places we have seen the migration slip, in roughly decreasing order of frequency:
The IVR rebuild that nobody budgeted properly. The Avaya CCX script has 800 nodes and twelve years of edits. The migration plan allocated four weeks to "contact flow build." Reality is twelve to sixteen. This is the single most common slip and the single hardest to negotiate back from, because the contact flow is the long pole.
The CRM screen-pop that nobody tested at port-cutover. Dev environment works. Test environment works. Pilot agents on shadow traffic work. Then the first production call lands, and the screen-pop fires against the wrong caller record because a contact attribute is being passed in a different format than the dev environment expected. The fix is to test the screen-pop against real production-shape data — anonymised production call attributes, not synthesised test data — before cutover.
The supervisor reports nobody mentioned. The business uses a daily report from the legacy WFM tool that nobody flagged in the migration requirements. Cutover happens. The report stops working because the data source moved. The business is unhappy. The fix is to interview every report consumer before cutover, not after, and to land the Connect equivalents — Contact Lens dashboards, Athena queries against the analytics S3 bucket, Amazon QuickSight on top — in the same week as the platform cutover.
The agent training program that was a slide deck. Covered above. Worth repeating because it is the most preventable cause of a long productivity dip.
The recording-archive question that wasn't answered before cutover. Legacy recordings live in a vendor-specific format on a vendor-specific archive. Connect recordings land in S3, with Contact Lens transcripts in a separate location. The compliance question is whether the legacy archive needs to remain searchable, and the answer is almost always yes, for the retention period. The fix is either to leave the legacy archive running in read-only mode for the retention window, or to migrate the recordings to S3 with metadata that lets the existing search interface query them. Both are valid; both need to be decided before the legacy platform gets switched off.
What this teaches us about contact-centre modernisation
Two takeaways for teams that are about to start this work.
One. The Connect migration is not a telephony project. It is a four-plane migration where the voice path is the most well-understood plane and the IVR rebuild plus CRM integration plus supervisor reporting are where the engineering volume actually lives. Plan the work proportional to where the volume sits, not proportional to where the marketing material focuses.
Two. The generative-AI capability that ships on top of Connect — the AI Agent feature, the Bedrock-backed contact flows, the real-time agent assist — is the reason the platform is increasingly the default destination for these migrations in 2026. But it is not the reason to do the migration. The reason to do the migration is the operational uplift on the boring layer: better routing, better analytics, better integration with the rest of the AWS estate, better unit economics for variable workloads. The generative layer arrives once the boring layer is in place. Sequence the work that way. The migrations that fail are the ones that try to ship the generative layer on top of an unfinished migration of the boring layer.
FAQs
How long does an Avaya-to-Amazon-Connect migration realistically take?
For a mid-sized estate of 500-1,500 agents with two or three lines of business, six to nine months from kickoff to legacy decommission is the realistic envelope. Two months for the architecture work and identity bridge, three to four months for the contact-flow rebuild and CRM integration, two to three months for the phased line-of-business cutover. The contact-flow rebuild is the long pole; if the legacy IVR is unusually complex, the timeline stretches accordingly.
Is Direct Connect required, or is SIP trunk handoff over the public internet acceptable?
SIP trunk handoff over the public internet is acceptable for most workloads, including most healthcare and financial-services workloads, because the SIP signalling is TLS-secured and the media is SRTP. Direct Connect becomes the answer when the network architecture review requires that voice traffic never traverses the public internet at all, which is common in regulated banking and some government contexts. Direct Connect adds 3-6 weeks of lead time and a monthly circuit cost. For everyone else, SIP handoff is faster, cheaper, and operationally equivalent.
How do we model the financial change from per-seat licensing to per-minute usage?
Pull two months of detailed call data from the legacy platform — inbound minutes, outbound minutes, per-agent utilisation — and price it against the Connect per-minute rates for your region. Add Contact Lens utterance costs if you plan to adopt the analytics layer, add AWS networking costs for Direct Connect if applicable, and add the carrier porting and circuit costs separately. For seasonal workloads the inversion typically saves 40-60% annually. For high-utilisation always-on workloads the bills come out roughly equal or occasionally higher on Connect. Model both before the cutover so the CFO is not surprised by the first invoice.
What is the agent productivity dip and how long does it last?
Expect Average Handle Time to inflate by 15-25% in the first two to four weeks after cutover, with a recovery curve back to baseline over six to eight weeks. The slope of the recovery is determined more by the training program than by the platform. Teams that build a transition lab where agents work shadow calls on the new platform before go-live recover fastest. Teams that ship training as a slide deck and a 30-minute Zoom take the longest and sometimes never fully recover the original baseline.
Should we adopt the Connect AI Agent feature during the initial migration or wait until phase two?
Wait until phase two for most workloads. The migration itself is enough engineering volume that adding a Bedrock-backed agent layer on top concentrates risk in a window where it cannot be debugged cleanly. The pattern that works is to land the boring layer first — voice, identity, CRM, contact flows, agent workspace, day-two operations — and then add the AI Agent feature in a controlled rollout three to six months after the legacy decommission. The exception is teams whose legacy IVR contains-out at a business-problem rate, where the generative path is the migration justification and moves up the priority list accordingly.
Companion content
- Identity-First AWS Migration for Nigerian Banks
- AWS Architecture for Nigerian Banks
- AWS Operational Implementation for Nigerian Banks
- The LLM Is the Easy Part: Legacy Banking Stacks
- Glue Code Is the Job: Enterprise LLM Integration
How to engage
If your team is sizing or executing a legacy contact-centre migration to Amazon Connect and wants engineering input on the four-plane architecture, the cutover pattern, or the day-two operations model, talk to us at creativeminds.dev/contact.