Amazon Connect Post-Migration Regrets: The Hidden Costs UK Contact Centres Discover After Go-Live

Arkadas Kilic
Arkadas Kilic 9 min read · 2026-09-08
By Arkadas Kilic, Founder & CEO, Rel8 CX

The migration is done. The legacy PBX is decommissioned. The project team has celebrated. Then, three months later, the CFO asks why the contact centre bill is 40% higher than projected, the compliance team is raising flags about call recording gaps, and the operations director is fielding complaints that agents cannot see customer history during live calls.

This is not a hypothetical. It is the pattern we see repeatedly when UK contact centres bring us in after a go-live that has not delivered what was promised. The Amazon Connect platform is genuinely powerful. The problem is almost never the platform. The problem is how the migration was scoped, delivered, and handed over.

Here is a frank account of the hidden costs and operational failures UK contact centres discover after go-live, and what it actually takes to avoid them.

The Telephony Bill That Nobody Modelled Correctly

Amazon Connect pricing looks simple on paper: per-minute usage, per-agent licensing for certain features, and data transfer costs. What gets missed in the pre-migration modelling is the compound effect of several line items running simultaneously.

Contact Lens charges are the most common surprise. Contact Lens for Amazon Connect provides real-time and post-call analytics, sentiment analysis, and transcription. It is priced per minute of analysis, not per call. A contact centre handling 500,000 minutes of calls per month and enabling Contact Lens across all queues can add £15,000 to £25,000 per month to their AWS bill, depending on the features enabled. Most migration scoping documents we have reviewed treat Contact Lens as a checkbox feature rather than a cost line. Amazon Lex charges compound this further. If your IVR uses conversational AI for intent recognition, every utterance processed by Lex carries a cost. A poorly designed IVR that fails to resolve intent quickly will generate three to five Lex requests per call instead of one. At scale, that difference is material. Data transfer and storage for call recordings is routinely underestimated. A contact centre recording 100% of calls at 8kHz mono generates roughly 1MB per minute. At 500,000 minutes per month, that is 500GB of new recordings monthly. Add S3 storage costs, lifecycle policy misconfiguration that keeps recordings in the wrong storage tier, and the absence of automated deletion policies for recordings past their retention window, and the bill climbs.

The fix is not to disable features. The fix is to model costs at the feature level before go-live, implement tagging and cost allocation from day one, and design IVR flows that minimise unnecessary Lex invocations.

Compliance Gaps That Surface After the Auditors Arrive

UK contact centres operating under FCA regulation, GDPR, or PCI DSS face a specific set of compliance requirements that Amazon Connect can absolutely meet. The keyword is can. Out of the box, without deliberate configuration, several compliance controls are absent.

Call recording consent and suppression is the most common gap. GDPR and FCA rules require that call recordings containing sensitive data, particularly payment card data, are either not recorded or that the sensitive segment is suppressed. Amazon Connect does not suppress recording by default during DTMF payment capture. Contact centres that go live without a suppression mechanism are recording card numbers into S3. We have seen this in production environments serving tens of thousands of customers. Encryption key management is a second gap. By default, Amazon Connect uses AWS-managed keys for call recording encryption. FCA-regulated firms and those handling sensitive financial data typically require customer-managed keys (CMK) via AWS KMS, with key rotation policies and access logging. Retrofitting CMK after go-live requires re-encrypting existing recordings and updating all downstream processes that access them. The effort is significant. Access control and audit trails for agent and supervisor activity are not automatically configured. Who accessed a recording? Who changed a routing profile? Who exported contact data? Without CloudTrail configured correctly and logs shipped to a SIEM, answering these questions during an audit is painful and slow. Data residency is a recurring concern for UK contact centres post-Brexit. Amazon Connect operates from the EU (Frankfurt) region for most UK deployments. Confirming that all data, including Contact Lens transcripts, Lex interaction logs, and contact records, stays within the expected geographic boundary requires deliberate configuration and ongoing verification. It is not automatic.

Compliance built in at architecture stage costs a fraction of what it costs to retrofit. The conversations we have with contact centres who are three months post-go-live and facing an audit are always harder than the conversations we have before the first line of infrastructure code is written.

Integration Failures That Break the Agent Experience

The promise of Amazon Connect is a unified agent workspace where customer context flows from CRM to screen pop to call handling without friction. The reality, when integrations are rushed or under-scoped, is agents toggling between four browser tabs while a customer waits.

Salesforce and Dynamics integrations are the most common integration points for UK contact centres, and both carry complexity that is routinely underestimated. The Amazon Connect CTI adapter for Salesforce works well when Salesforce is cleanly configured and the contact centre has a clear data model. When Salesforce has years of custom objects, workflow rules, and legacy data quality issues, the integration requires significant custom Lambda development to surface the right data at the right moment. Scoping this as a four-hour task and delivering it as a four-day task is a pattern we see constantly. Workforce management (WFM) integration is another area where post-go-live regret is common. Tools like Verint, NICE IEX, and Calabrio require real-time and historical data feeds from Amazon Connect. The Amazon Connect Data Streaming feature (Kinesis-based) requires infrastructure setup, schema mapping, and transformation logic. Contact centres that go live without this in place are flying blind on adherence and forecasting for weeks or months. Back-office system integrations for financial services contact centres, whether that is a core banking platform, a policy administration system, or a claims management tool, are almost always underscoped in migration projects. The assumption is that these integrations can be built post-go-live. The reality is that agents cannot do their jobs without them, and the post-go-live sprint to build them under operational pressure produces fragile, poorly tested code that becomes a maintenance burden.

The Agent Training Gap That Kills CSAT in Month One

Amazon Connect's agent workspace, the Contact Control Panel (CCP), is genuinely simple to use. That simplicity creates a false confidence in training timelines. The CCP is simple. The workflows around it are not.

Agents need to understand how to handle transfers, conference calls, and queue callbacks correctly. They need to know what to do when a contact arrives with no screen pop data. They need to understand how to use after-call work (ACW) codes correctly, because those codes feed every operational report downstream.

Contact centres that cut training to two hours of self-guided e-learning and go live on a Monday morning typically spend the first two weeks in firefighting mode. CSAT scores in month one are frequently 15 to 20 points below baseline. Recovering that ground takes time that the business cannot afford.

Supervisor training is consistently worse than agent training in post-migration projects. Supervisors need to understand the real-time dashboard, how to monitor and barge calls, how to adjust routing in real time, and how to interpret Contact Lens sentiment data. When supervisors are not trained, the operational intelligence that Amazon Connect provides is simply not used.

Routing Logic That Was Copied, Not Redesigned

The most expensive technical decision in many Amazon Connect migrations is the decision to replicate existing routing logic rather than redesign it.

Legacy contact centre platforms accumulate routing complexity over years. Skills-based routing rules, priority queues, time-of-day routing, and overflow logic become deeply embedded in the platform configuration, often undocumented. When a migration project lifts this logic and recreates it in Amazon Connect contact flows, the result is a system that is technically functional but operationally suboptimal.

Amazon Connect contact flows support dynamic routing driven by Lambda functions, real-time queue metrics, and external data sources. A contact centre that migrates with static routing logic and never revisits it is leaving significant efficiency gains on the table. Average handle time, first-contact resolution, and queue abandonment rates all improve materially when routing logic is redesigned rather than replicated.

The counterargument is always timeline pressure. Redesigning routing logic takes longer than replicating it. Our view is that the 4 to 6 weeks required to build production-grade routing from scratch, rather than migrate legacy logic, pays back within the first quarter of operation.

What a Post-Migration Recovery Actually Looks Like

When UK contact centres bring us in after a troubled go-live, the recovery work follows a consistent pattern.

Week one is assessment: cost analysis, compliance gap audit, integration inventory, and routing logic review. We produce a prioritised remediation plan with effort estimates and business impact for each item.

Weeks two and three address the compliance and cost items first. Suppression mechanisms for payment data, CMK configuration, CloudTrail and SIEM integration, and cost allocation tagging. These items carry the highest risk and the most immediate business impact.

Weeks four through six address integration quality and routing redesign. Lambda functions are refactored or rebuilt. CRM integrations are stabilised. Routing logic is redesigned with dynamic queue-based rules. WFM data feeds are stood up correctly.

The outcome is a contact centre that is actually running on the platform it thought it was buying. The cost of recovery work is real, but it is consistently lower than the cost of continued underperformance.

How to Avoid Post-Migration Regret Entirely

The contact centres that do not end up in recovery mode share a set of common characteristics.

They scoped compliance requirements before writing a single line of contact flow code. They modelled AWS costs at the feature level, not the platform level. They treated integrations as first-class deliverables, not post-go-live tasks. They redesigned routing logic rather than replicating it. And they allocated real time to agent and supervisor training, not the minimum viable hours.

They also worked with practitioners who build Amazon Connect systems in production, not consultants who advise on what good looks like from a distance.

The difference between a migration that delivers and one that creates six months of operational pain is almost always in the pre-go-live decisions. The platform does not fail. The scoping fails.

The Numbers Worth Knowing Before You Go Live

Final Word

Amazon Connect is the right platform for UK contact centres that want enterprise-grade telephony, native AWS integration, and the foundation for autonomous AI-driven contact handling. The regrets are not about the platform. They are about the gap between what was promised in the migration project and what was actually built.

If you are planning a migration, or if you are already post-go-live and recognising some of what is described here, the next step is a structured assessment of where you are and what it takes to get to production-grade operation.

Book a discovery call

Is your pilot going to reach production?

Fifteen questions, three minutes, no cost. You get a score against the ten checks we run every deployment through, and a straight answer on what is blocking yours.

Find out what is blocking you