AWS Prescriptive Guidance

Strategies for migrating your

contact center to Amazon Connect
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

AWS Prescriptive Guidance: Strategies for migrating your contact

center to Amazon Connect
Copyright © 2023 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not
Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or
discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may
or may not be affiliated with, connected to, or sponsored by Amazon.
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Table of Contents
Introduction ...................................................................................................................................... 1
Overview ........................................................................................................................................... 3
Pillars of successful migration ...................................................................................................... 3
Primary vision ............................................................................................................................ 3
Targeted business outcomes ........................................................................................................ 4
Agile methods to accelerate delivery and innovation .............................................................................. 6
Project phases and workstreams .......................................................................................................... 9
Operational workstream ............................................................................................................ 10
Program governance ......................................................................................................... 10
Alignment ....................................................................................................................... 10
Operating model definition ............................................................................................... 11
Service introduction (SI) .................................................................................................... 11
Training ........................................................................................................................... 12
Technical foundation workstream ............................................................................................... 12
Discovery and roadmap ..................................................................................................... 12
Design ............................................................................................................................ 13
Build ............................................................................................................................... 13
Test ................................................................................................................................ 13
Deploy ............................................................................................................................ 13
Post go-live support (PGLS) ............................................................................................... 13
User journeys workstream ......................................................................................................... 14
Discovery ......................................................................................................................... 14
Design ............................................................................................................................ 14
Build ............................................................................................................................... 15
Test ................................................................................................................................ 15
Deploy ............................................................................................................................ 15
Post go-live support (PGLS) ............................................................................................... 15
Running a pilot ................................................................................................................................ 16
Best practices .......................................................................................................................... 16
Selecting a pilot group ............................................................................................................. 16
Best practices for migrations ............................................................................................................. 18
Technical considerations ............................................................................................................ 18
Operational considerations ........................................................................................................ 21
Migration checklists .......................................................................................................................... 23
Before you go live .................................................................................................................... 23
On the day you go live ............................................................................................................. 23
Post-migration optimizations ............................................................................................................. 25
Next steps ....................................................................................................................................... 26
Resources ........................................................................................................................................ 27
Document history ............................................................................................................................. 28

iii
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Strategies for migrating your contact

center to Amazon Connect
Jag Jhutty, Amazon Web Services (AWS)

August 2022 (document history (p. 28))

This article defines the objectives and targeted business outcomes of a contact center migration
to Amazon Connect. It explains how you can plan the migration, get buy-in from the appropriate
stakeholders, carry out the migration, and cut over.

Your contact center is a gateway to your brand and business. Each interaction with an agent, supervisor,
or chatbot leaves an impression on your customer. Amazon Connect is a cloud-based contact center
service that enables you to provide personalized customer experiences and deliver exceptional customer
service. Amazon Connect provides the following features:

• Omnichannel: Customers can interact with the call center by using a channel of their choosing. You can
provide rich digital experiences beyond voice, such as chat, SMS, and social media.
• Consumption-based billing: There are no licenses, contracts, or usage commitments. With Amazon
Connect, you pay for what you use.
• Scalability: Amazon Connect is cloud-based, so it scales up and down dynamically to meet demand
without your intervention. It automatically handles large call volumes during peak events without
requiring you to pay for unused capacity.
• Agility: The frequent release of new features enables you to stay at the forefront of innovation and
customer experiences. New features are ready to activate without requiring any upgrades. Feature
roadmaps are customer-driven, based on customer requests, security and reliability points, and
operational improvements.
• AI and ML capabilities: You can use built-in artificial intelligence (AI) and machine learning (ML) to
personalize and automate interactions, understand customer sentiment, authenticate callers, and
enable capabilities such as interactive voice response (IVR) and chatbots.

An independent Forrester report from June 2020 analyzed six Amazon Connect customers and found
that it:

• Reduced total cost of ownership (TCO): 241 percent ROI compared to other contact center providers,
reduced subscription and usage costs by 31 percent.
• Deflected and streamlined calls: reduced call volume routing by up to 24 percent.
• Improved visibility: reduced supervisor effort by up to 20 percent due to improvements in reporting
and metrics dashboards.
• Simplified management: reduced system administrator efforts by up to 60 percent.
• Boosted customer experience: shortened average handle time (AHT) by up to 15 percent.
• Provided dependability and agility at scale.

This article is for decision makers (for example, the director of infrastructure) who are interested in
moving to Amazon Connect because they are unhappy with their existing contact center or they are
researching alternatives before an upcoming contract renewal. The article assumes some technical
knowledge and familiarity with contact center terminology but no AWS expertise. It provides additional
details so that you can forward this article to architects or other technical people within your teams and
get their perspective. We also encourage you to discuss the contents of this article with your leadership

1
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

(for example, corporate executives), recommend a further look at Amazon Connect, and initiate a
conversation with your AWS account manager.

2
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Pillars of successful migration

Overview
Pillars of successful migration
To carry out a successful contact center migration, you shouldn’t view the migration as only a technology
delivery project—you should approach it from multiple perspectives. Otherwise, you might overlook vital
preparations such as staff training and operating model changes. These non-technology considerations
are crucial in ensuring overall success.

The pillars illustrated in the following diagram are perspectives and capabilities described in the
AWS Cloud Adoption Framework (AWS CAF). This framework provides best practice guidance to
help you digitally transform and accelerate your business outcomes through innovative use of AWS.
Each perspective covers a set of capabilities that stakeholders own or manage in the contact center
transformation and migration process.

Moving users (customers, agents, and operators) to a new platform and tool set is a considerable amount
of work. Contact center migrations require thorough planning, whether you are taking your existing on-
premises contact center journeys to the cloud, or refactoring the whole customer and agent experience.

The following sections discuss approaches and best practices to plan, manage, and complete migrations
to Amazon Connect.

Primary vision
A successful contact center migration starts with business requirements and then focuses on people,
processes, and technology.

Start planning your Amazon Connect migration by first developing a primary vision statement. This
should be a general principle that guides the direction of decision-making. You can then define more
specific guiding principles for particular decision areas within the bounds of this general principle.

For example, the primary vision statement for your project might answer the question, “What does
success look like?” as follows: “Minimal user disruption (in order of significance: customers, agents, system
operators) while migrating service lines at pace.”

Notice the emphasis on the following phrases:

3
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Targeted business outcomes

• Minimal user disruption – Depending on your contact center’s opening hours and backend systems,
it might not be possible to avoid downtime entirely during the migration. Be realistic and consider
whether the expected disruption is tolerable compared with the time and effort required to complete
the migration without any downtime. Accepting minimal disruption rather than no disruption might
reduce risks in other areas of project delivery or provide significant cost savings. For example, you
might decide to circulate a new web address to users for accessing the new Amazon Connect desktop
instead of migrating an existing web address. This helps avoid the effort and expense of signing new
domain certificates and having to manage a web address cutover.
• User list in order of significance – Customers, agents, and system operators have different priorities
during a migration. Generally, the highest priority is to avoid disruption to your customers, even if it
means additional disruption to agents and backend system operators.
• Pace – It is costly, both financially and resource-wise, to operate more than one contact center
platform during the migration. Your objective should be to keep the dual-system period as short
as practical. The longer it is, the greater the cost, the burden on operators, and the risk of human
errors such as making changes on the wrong platform. Balance rigor and depth with the need to move
rapidly. Develop a realistic delivery plan and try to follow it.

Targeted business outcomes

Keep these business outcomes in mind when you plan your contact center migration:

• Increased business agility – Deliver new capabilities into production rapidly and safely. For example,
sentiment analysis and big data call transcript crawling help you gather near real-time insight
into customer communications and enable you to optimize your products and services based
on their needs. After you identify and implement these features, you can deliver them by using
DevOps principles, which encourage collaboration among your developers and operators, and use
infrastructure as code (IaC) tools and continuous integration and continuous delivery (CI/CD) pipelines
to manage builds and automate testing. Avoid repeating steps manually wherever possible to avoid
human error, which can introduce bugs into the implementation process.
• Improved total cost of ownership (TCO), especially in early stages – Rework costs time and effort.
To get key decisions right the first time, allocate sufficient time to the discovery and design phases
of migration. Infrastructure decisions are difficult to alter without significant cost, so consult with
the appropriate stakeholders. For example, changing the encryption policy for call recordings might
require additional infrastructure components, so make sure that your security compliance teams
approve the encryption policy before you start implementation. Get sign-off on designs before moving
into the build phase.
• Agile customer experience – Use agile methodologies to rapidly and iteratively develop caller
journeys. Unlike infrastructure components, contact flows and user journeys are easy to alter, so start
early with a basic flow and iterate frequently with stakeholders to reach the desired state. It’s easy to
add a message prompt or to alter menu options in Amazon Connect—no programming knowledge is
required. Your objective should be to deliver the right user journey, not to rigidly follow the journey
that you originally designed. Iterating frequently gives stakeholders the ability to tweak the journey as
it matures and feedback is received.
• Smooth and timely service introduction – User training, process changes, and service desk changes
are often overlooked until the project is close to completion. The new contact center has to be
accepted into your organization’s business as usual (BAU) operations as well as meeting the go-live
date. Without a proper handover, the project team will not be able to recede and BAU teams will not
be prepared to use the new platform. Make your project’s integration into BAU operations a gate
for go-live approval. It is vital to agree on platform ownership before you go live. Engage service
introduction and operating model stakeholders from the beginning of the project, and keep them
engaged throughout.
• Introduce new, differentiating capabilities to improve customer satisfaction (CSAT) scores – Ask
yourself whether the user experience can be simplified or improved by Amazon Connect. Don't limit
yourself to lifting and shifting your current call center to the cloud. Use Amazon Connect features to

4
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Targeted business outcomes

improve the user (customer and agent) experience or to simplify the technical implementation of your
platform. With relatively little effort, you can incorporate new Amazon Connect capabilities into your
call center and see a significant improvement in your CSAT scores.

5
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Agile methods to accelerate delivery

and innovation
We recommend that you use an agile methodology in conjunction with DevOps and CI/CD practices as
the underpinnings of your migration to Amazon Connect. These practices become the foundation for a
dynamic, user-focused, and experiment-driven approach to customer experience.

If you have a compelling business reason to initially migrate your contact center as is to Amazon
Connect, without adding new features, we still highly recommend adapting an agile approach to enable
experimentation and the continuous improvement of the customer experience over time.

Borrowing from Amazon’s business approach to transformation, we recommend a think big, start small,
go fast approach. You start by clarifying your business goals and focus areas, and brainstorm with key
stakeholders to define and align on key opportunities for innovation. You then work back from the
customer to understand who they are, what they need, and how to improve their experience. From there,
you define and prioritize key initiatives to create a minimum lovable product (MLP) that drives business
outcomes and provides immediate impact within the initial agile sprint. Establishing an Amazon Connect
technical foundation and the agile delivery framework during the initial sprint builds the foundation of
the customer experience (CX) flywheel, which is depicted in the following diagram.

6
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Subsequent sprints are prioritized by working back from customer needs, and organized by additional
functionality, additional users and business units, or a combination of the two. The following diagram
shows a typical agile sprint process. Change management (CM) activities underpin the agile sprint
process and ensure that the organization is keeping pace with technology delivery.

7
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

After teams and stakeholders agree on a multi-phase migration and transformation plan (as discussed
in the following sections), the initial agile sprint establishes the foundation of an Amazon Connect
contact center, which provides a common baseline of capability, prepares the flywheel mechanism
for accelerating transformation, and defines the mechanisms for continuous improvement. The key
elements of this foundation include:

• Deploying Amazon Connect on a secure, high-performing, resilient, and efficient AWS infrastructure.
• Configuring contact flows that define the customer experience and establishing design conventions for
consistent experiences.
• Developing representative experiences such as customer identification and lookups.
• Setting up the business administration console.
• Integrating critical third-party systems.
• Configuring the data model and data pipeline, such as how to access Amazon Connect data from a
data lake or data warehouse.
• Creating a DevOps operational runbook.

These elements are the building blocks for delivering operational fundamentals with next-generation
capabilities to elevate the customer experience and reduce operational costs. They are the first items to
be used by a project, so they should be prioritized. The foundation is the catalyst for additional sprints
and becomes the enabler for continuous experimentation and improvement.

8
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Project phases and workstreams

In the context of a contact center migration project, sprint, workstream, and phase have the following
meanings:

• A sprint is a time-bound collection of activities that are delivered by different workstreams. For
example, each sprint could be two weeks long.
• A workstream is a team-bound collection of activities associated with a set of technology components
or scope. Sprints include workstream activities. For example, AWS account and landing zone creation
can be included in a technical foundation workstream, which involves architect and developer team
resources. Mapping customer experiences and recording call prompts should be handled by a different,
user journey-related workstream, because these tasks involve business stakeholders and service line
owners.
• A phase is a goal-oriented collection of activities across workstreams. Phases usually end at milestones,
and reaching these milestones means that the project progresses to the next phase. For example,
the design phase involves creating documents that are appropriate to each workstream, such as
architectural diagrams, build specifications, and high-level design documents. The design phase is
completed when these documents are approved by the necessary stakeholders.

Well-defined and autonomous workstreams improve overall project agility. Basing workstreams on
specific teams and roles gives team members autonomy in prioritizing sprint backlog items. It also
creates boundaries between workstreams, so you can identify and track dependencies, and provides clear
accountability.

The high-level plan in the following diagram shows the parallel workstreams and sequence of typical
activities in an example contact center migration project.

We recommend that you run at least three parallel workstreams: operational, technical foundation, and
user journeys. The phasing and approach to project activities differ, depending on the nature of the
workstream. Each workstream requires a different delivery approach, as explained in the following
sections. As the diagram illustrates:

• Tasks within each workstream are bundled into agile sprints.

• Sprint 0 is a collection of early tasks focused on project kick-off, discovery, planning, and design.

9
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Operational workstream

• Sprint MLP is a collection of activities for creating a minimum lovable product (MLP) that future sprints
can iterate on to provide end-state target capabilities. For example, the MLP could deliver a relatively
straightforward caller journey to a small group of agents. After the platform is live and proven stable
for the MLP use cases, future sprints (Sprints 2, 3, and so on in the diagram) can iterate rapidly to
deliver innovative capabilities.
• Each project and environment is different, so the diagram doesn’t provide specific timelines. Use this
plan as a starting point for discussions with stakeholders during the initial project planning phase.
Determine which activities are relevant, identify any activities that should be added, and determine
their estimated duration.

Operational workstream
The operational workstream supports the technical foundation and user journey workstreams.
The majority of non-technical activities that are crucial to overall migration success are part of this
workstream.

This workstream involves decisions that can be changed or reversed with little effort or impact. Product
specifications that are based on how people work and engage are rarely right the first time―there are
many stakeholders and voices to consider. It is important to engage early and consult widely and often,
so an agile and iterative approach makes sense for this workstream. You start with an early draft of an
operating model or training materials and iterate frequently and rapidly to get to the final product.

The operational workstream consists of five phases: project governance, alignment, operating model
definition, service introduction, and training.

Program governance
Program governance activities run throughout the entire timeline of a migration project. Regardless
of the stage the project is in, activities should be regular (scheduled recurring meetings), transparent
(project team is given the opportunity to raise risks and issues frankly), and with engaged governance
(leaders are empowered and willing to make decisions or escalate accordingly). These are vital for
highlighting and resolving issues promptly and effectively.

Alignment
This is the first formal activity of the project and focuses on aligning the project scope to business
outcomes. Alignment provides an opportunity to validate and adjust earlier plans and estimates based
on discussions with stakeholders.

Key actions during this activity include:

• Discover high-level customer use cases, current technical and business pain points, and opportunities
for improvement.
• Discuss and agree on desired business outcomes, determine their relative priorities, and identify
success criteria.
• Develop a high-level solution design, which is used to define scope and technology choices in this early
phase. This high-level design provides direction to accelerate low-level design activities in later phases.

10
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Operating model definition

• Validate timelines and implementation costs.

Operating model definition

The activities in this phase define who will use the contact center solution and how the solution will
be managed. The operating model is not a procedural document, a runbook, or a configuration file.
For example, it shouldn’t explain how to pull logs and attach them to a support ticket, or provide
screenshots of this procedure. Instead, it should identify who should pull the logs and which queue or
vendor they should be sent to.

The operating model definition should include:

• A responsible, accountable, supported, consulted, and informed (RASCI) matrix, so each team
understands its roles and responsibilities, and how they will interact with other teams. The following
provides an excerpt from a RASCI matrix.

• Process flow swimlanes that define the end-to-end activities and who is responsible for each activity.
For example, there should be a process flow for engaging out-of-hours support so it's clear who gets
paged, what happens if they can’t be reached, who logs the support ticket, and how the business
criticality is judged. Another example is the emergency queuing message. The process flow should
show who decides that it needs to be initiated, and what data they should use to make that decision.

The operating model is typically defined in the second half of a project, because you have to finalize
the solution design and user journeys before you can define the processes to manage them accurately.
However, we recommend that you line up stakeholders early in the process and reserve their time for the
later phases of the project.

Gather examples of similar documents from your organization that you can use as templates. This will
facilitate review and sign-off by stakeholders because the document structure will be familiar to them.

Make sure that your stakeholders sign off on the operating model before your new contact center moves
into production, and make it a requirement for your decision to go live. Each team member needs to
understand their role and the process for operating the contact center in the production environment.

Service introduction (SI)

SI activities implement the changes defined in the operating model. Think of the operating model
definition as the design and build phases for the new model, and SI as the deploy phase of the operating
model.

The SI team is often a dedicated team in your organization, and works independently from the project
team. The project must pass the SI team’s criteria and checklists before it receives approval to go live. For
example, checklists include user acceptance testing (UAT) results and confirmation that a clashing event
(such as a change freeze or another scheduled go-live event) isn’t taking place on the same day that the
project goes live, that users have the necessary training, and that operations teams are ready to proceed.

Do not leave SI activities to the end of the project. Engage the SI team early in the project and include
them in your distribution list for design documentation. Early involvement ensures that the SI team

11
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Training

can assist in the preparation to go live, such as helping to select the most suitable AWS support plan,
providing impact statements for change requests (CRs), and supporting change approval board (CAB)
discussions.

Training
Creating training materials and conducting well-attended training sessions are vital to successful
migrations. Technology can work perfectly, but if users don’t know how to answer calls and perform
their daily tasks, the migration will be considered a failure.

Training activities might include direct user training, training the trainers, training for supervisors,
training for support staff, and training for system administrators or product owners. Each organization is
unique, so some options might be a better cultural fit than others.

We recommend a train the trainer approach that involves your organization's in-house training staff. Your
staff knows your organization’s culture, and the training format and techniques that best suit your users.
Project team members can take on subject matter expert (SME) roles to provide technical materials (such
as user manuals, administrator console manuals, and screen guides) that can be used as source material
for the train the trainer sessions. If your organization doesn’t have a training team, project SMEs should
train supervisors and lead support staff, who can then train the users of the contact center.

We also recommend that system administrators and product owners take formal, instructor-led product
training courses to gain a deeper understanding of the AWS environment and Amazon Connect console,
so they can use product features and troubleshoot effectively.

Technical foundation workstream

This workstream involves decisions that require significant rework if changed, so the workstream
emphasizes careful design, wide consultation, and up-front investment in DevOps processes and testing.

The technical foundation workstream consists of five phases: discovery and roadmap, design, build, test,
deploy, and post go-live support.

Discovery and roadmap

In this phase, you gather information and schedule workshops for the following:

• As-is mapping – Examine systems and capabilities, gather data, and meet with SMEs to understand the
current state of the contact center.
• To-be design and gap assessment – Determine the ideal experience for all contact center agents and
customers to determine project scope.
• Gap closure plan – Outline a roadmap for building and deploying the future state of the contact
center.

Workshop attendees:

12
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Design

• Project managers
• Business, solutions, technical, and security architects
• Infrastructure platform owners

Design
In this phase, you produce design documents. You might have your own conventions or processes for
creating design artifacts. We recommend including at least three sections in the design document:
Amazon Connect configuration, networking, and security. Each section will likely have different,
specialized stakeholder groups to ensure effective reviews and sign-offs, so it might be more practical to
create separate documents for these three areas. Stakeholders should include architects, the security and
compliance team, and platform owners.

Build
In this phase, you follow infrastructure as code (IaC) principles by using DevOps tools to standardize
and manage stable releases. Avoid adopting a manual build process, even if it helps you get started
more quickly, because this can increase the risks to stability and the number of bugs as the build
becomes more complex and is promoted to the test and production environments. If you don’t have
your own DevOps tools, we recommend that you use AWS tools such as AWS CodePipeline and AWS
CodeBuild, which can be switched on quickly. Factor the effort for setting up these tools into the scope
of the project; they will be beneficial in the long term and enable you to follow DevOps principles.
We recommend that you build in at least three separate AWS accounts for development, testing, and
production. DevOps tools and automation can help you move code through these environments.

Test
The test phase consists of three sequential subphases:

1. Unit testing – Testing individual infrastructure components to ensure that they are correct and within
design specifications. Performed by: developers
2. Integration testing – Testing items that form integration boundaries, such as Microsoft Active
Directory (AD) identity management services. Performed by: developers
3. Product testing – End-to-end testing of functional journeys throughout the infrastructure; for
example, testing that each agent event is logged in the security monitoring tool, the call is taken, and
the call recording is in the correct Amazon Simple Storage Service (Amazon S3) bucket. Performed by:
functional test team

Deploy
The infrastructure must be ready to handle live traffic when user journeys are scheduled to go live. The
focus in the deployment phase is to ensure that AWS service quotas meet expected call volumes and the
number of concurrent agents, number porting or toll-free number service (TFNS) repointing is complete,
and the health of backend systems is being monitored as live traffic volumes ramp up. The security and
compliance team should also confirm that the platform is ready for live traffic from their perspective.

Post go-live support (PGLS)

The project team remains engaged with the business as usual (BAU) support teams and end-users during
the first few weeks after the new contact center goes live. The project team can help users get started
on the new system, get involved in troubleshooting issues alongside the BAU support team, and improve
support documentation based on feedback.

13
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
User journeys workstream

User journeys workstream

The user journeys workstream also involves decisions that can be changed or reversed with little effort
or impact. The emphasis is on starting with a basic build of the user journey and iterating frequently and
rapidly to get to the final product. It is rare for the final user journey to look exactly like the first one
proposed, so an agile and iterative approach makes sense for this workstream.

The user journeys workstream consists of five phases: discovery, design, build, test, deploy, and post go-
live support.

Discovery
In this phase, you gather existing user journey flows and designs, and pass them to the contact flow build
team. If these do not exist or you want to design a new user journey, gather stakeholders in a workshop
and collaboratively develop a user journey framework in a visual capture tool such as the following:

• Visual canvas tool – Use a tool such as Microsoft PowerPoint, Microsoft Visio, or draw.io. Screen-share
the canvas to all stakeholders in a workshop. Add blocks and decision points to build an end-to-end
user journey, and add placeholders for steps that should be confirmed later (for example, the exact
wording or import of a queuing message audio file). Add the name of the owner who should confirm
the placeholder.
• Contact flow designer – Instead of using a drawing tool like draw.io or Visio, consider using the contact
flow designer that’s included in Amazon Connect to develop and document the user journey over
screen-share. Use prompt block placeholders for steps that should be confirmed later (for example,
the exact wording or import of queuing message audio file). Use a simple text-to-speech (TTS) prompt
block to record the owner who is confirming the step (for example, “Queue A message .wav file to be
provided by John Smith”). This enables you to perform end-to-end testing of the user journey and
routing logic in parallel.

Workshop attendees:

• Project managers
• Business and solutions architects
• Business analysts
• Service line owner and operator

Design
Design documentation is optional. It depends on the size and complexity of the contact flow. If you use
the contact flow designer, which has an intuitive, easy-to-follow flowchart interface, the journey is self-
documented and represents the actual build of the contact flows. This ensures a single source of truth
during the rapid and agile development of the user journey. Otherwise, standalone design documents for
contact flows must adhere to change control to avoid diverging from the actual build over time.

14
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Build

Build
Amazon Connect configuration is available by using AWS CloudFormation templates and APIs in
infrastructure as code (IaC) tools. Use DevOps tools to build and manage Amazon Connect components
such as security profiles and contact flows. If you design flows by using the contact flow designer, you
can include the flows in your IaC DevOps tools and manually export them as JSON files.
Note
You can also start building contact flows in a development environment while other AWS
accounts are being created, and export the flows into the test and production environments
when their Amazon Connect instances are ready.

Test
The test phase consists of two sequential subphases:

• Functional testing – Performed iteratively over agile sprints as contact flows are created in Amazon
Connect. Performed by: functional test team
• User acceptance testing (UAT) – Performed only after contact flows have passed functional tests.
Performed by: client business users (a dedicated team or users from the service line business unit)

Deploy
In this phase, agent and user credentials are uploaded into the Amazon Connect production instance
so that users can log in. You should upload contact flows only after they successfully pass UAT testing
in the previous phase. Claim a temporary phone number in the Amazon Connect dashboard and assign
it to the contact flows. These phone numbers will be visible only to the project team, who will use
them to place test calls. The project team often runs a selection of UAT scripts during this process. This
approach provides preparatory (pipe-clean) testing of the user journey before the system goes live and
real agents can access the workflow. At the scheduled go-live time, this temporary number is replaced by
the publicly routable number used by customers―this is the point where you cut over to the new system.
If necessary, you can roll back changes by swapping the number back to the legacy service line.

Post go-live support (PGLS)

The project team remains engaged with the service line stakeholders, the business as usual (BAU)
support teams, and end users during the first few weeks after the new contact center goes live. The
project team can help users get started on the new system, get involved in troubleshooting live issues
alongside the BAU support team, and improve contact flows based on customer and agent feedback.

15
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Best practices

Running a pilot
Completing an end-to-end migration project for a small business area allows for fast deployment
without the risk of large-scale business disruption. This experience builds confidence in the value
proposition (capability, operations, and cost) for a relatively small outlay and can be used to justify a
larger release of funds and resources for a full-scale project.

Pilots gather lessons for a full-scale deployment based on how end-users react to the new platform.
They help stakeholders answer important questions with real-life data such as the following:

• Is the training we’re providing suitable and sufficient?

• Do new processes work properly when end-users take real calls?
• Are users distracted by other applications on their device?
• Does an architecture or pattern work as expected in the live environment?

Best practices
• Ideally, pilots should become part of the initial minimum lovable product (MLP) delivery in an early
sprint.
• Participants in a pilot should include technical users, business users, and end-users.
• Interview stakeholders to get anecdotal feedback on how they use the system, and capture data
on average handle time, abandonment rate, and so on, to compare the new system with previous
platforms.
• Make sure that tweaks and amendments that are identified during the pilot are tracked to completion.
• Define your success criteria and next steps before the pilot begins. Success criteria should be data-
driven to enable conclusive scoring to reach a success/fail decision. If stakeholders sign off on the pilot
and the delivery plan for any amendments, the predefined next step (for example, to start a full-scale
deployment) is initiated.
• Be positive when your pilot reveals areas that have to be changed or even redesigned. This is a
valuable outcome of the pilot and builds the foundation for a successful go-live deployment. Do not
aim for a pilot with zero recommendations―this outcome would raise concerns on the validity of the
pilot.

Selecting a pilot group

The business area you select to pilot the solution would ideally demonstrate all capabilities in scope
of the minimum lovable product (MLP) to meet business outcomes. The successful delivery of the MLP
becomes the starting point for building out complexity and adding service capabilities. The MLP pilot
group should:

• Represent a non-critical business area (for example, an internal help desk, or a notification of change
of circumstances).
• Handle a low volume of calls, so users have the time to learn the new platform and to record their
feedback and observations.
• Be trusted by the project team and stakeholders, to ensure that feedback is fair, accurate, and
objective. This helps instill confidence in the outcome of the pilot and helps create a collaborative
development environment.

16
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Selecting a pilot group

• Perform the majority of in-scope platform functions. There is little value or relevance in a pilot that
uses only ten percent of the functions that are in scope of the full-scale deployment.
• Perform a function that might have been excluded from, or not fully integrated in, the old platform
because of technical limitations (such as remote work) or licensing. By starting with a group that has
no reports or recordings in the old system, you might be able to avoid building legacy integrations or
migrating legacy data. However, you should make sure that the pilot continues to represent the full-
scale deployment.

In reality, you might have to compromise on some of these factors, depending on the ability and
willingness of teams in your organization to take part in a pilot.

17
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Technical considerations

Best practices for migrations

Migrating to Amazon Connect is likely to change your contact center’s technical architecture and your
staff’s daily processes. To minimize disruptions, follow the best practices in this section when you design
and build your new contact center.

• Technical considerations (p. 18)

• Operational considerations (p. 21)

Technical considerations
For more information about the following technical best practices and additional recommendations, see
Best practices for Amazon Connect in the Amazon Connect Administrator Guide.

Voice traffic path – Will audio streams travel across your corporate internet link, or should you use an
AWS Direct Connect connection as a dedicated link? AWS Direct Connect avoids latency-sensitive voice
traffic competing with general traffic across data center internet pipes such as web browsing and email.

Setting up your network – A healthy end-to-end network connection is essential for a consistent and
stable user experience. You should consider every component, from the agent's device, through their
local network connection and virtual private network (VPN), if applicable, to Amazon Connect. A network
connection is only as healthy as its weakest link. To optimize your network for Amazon Connect, review
Set up your network in the Amazon Connect Administrator Guide.

Remote agents – Do your agents use a VPN when they work from home? If so, consider enabling VPN
split tunneling for voice traffic. This routes delay-sensitive voice traffic across the local internet instead
of sending it back to the data center and routing it out to Amazon Connect over the internet. If you don’t
use split tunneling, latency is needlessly increased (resulting in delayed audio or sluggish soft-phone
actions), additional traffic load is placed on the VPN concentrator device, and your data center internet
ingress and egress charges go up.

Data migration – For data such as call recordings and reporting statistics, consider two approaches:

• Migrate the data to the new platform. This requires planning and feasibility assessment (for example,
to check audio format compatibility), but means that you can access your legacy data from a single
portal on the new platform.
• Archive your data in place and decommission it when the minimum retention period expires. This
might be more cost-effective, especially if data is stored on a purchased platform and accessed
infrequently so that having two portals to browse old and new data is a practical option.

Number porting

• Consider whether a non-geographic number (NGN) or toll-free number service (TFNS) provider is
required. Porting toll-free, local rate, or direct-dial-in (DDI) numbers to Amazon Connect allows for
centralized management and billing of the end-to-end call. Consider the current charging model for
your NGN/TFNS service and compare it with Amazon Connect charges. Be mindful of charges for calls
that are made outside operating hours. Some NGN/TFNS providers do not charge for these calls if
they handle the out-of-hours check and messaging. NGN/TFNS contracts and terms vary, so collect the
information carefully to perform an accurate comparison.
• Timelines for number porting can take several weeks, so file the porting request through a ticket as
early as possible. Use the ticket to finalize a cutover date and time. If there are challenges with the

18
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Technical considerations

timeline, temporarily set a number forwarding transfer from your existing telephony queue to the new
Amazon Connect phone number, as detailed in cutover option below.

Cutover approaches for porting numbers

You can use NGN backend repointing or number porting to port phone numbers.

NGN backend repointing – Perform a backend repoint of the frontend NGN number to the inbound
number (DDI) hosted on Amazon Connect, as shown in the following diagram. This does not require any
public-facing number changes and is typically managed as a service request ticket to the NGN carrier
provider. Repointing can be scheduled for a specific date and time.

Number porting – This process consists of two stages:

• Number forwarding – This optional step, illustrated in the following diagram, directs traffic from the
old platform to the new platform without changing the public-facing number. You can complete this
step before your scheduled number porting date. This expedites the migration of agents onto the new
platform in parallel with the number porting process. It also allows for rapid rollback (which depends
on a relatively simple change to call forwarding rules) without any dependencies on a carrier. However,
we recommend not leaving number forwarding in place for a long period of time, because it increases
call charges (you pay for inbound traffic on DDI-1, outbound forwarding, and inbound traffic on the
new DDI-2) and consumes infrastructure capacity (each inbound call also consumes an outbound
circuit for the forwarding path).

• Completion of number porting – On an agreed date and time, the carrier for DDI-1 ports the number
to AWS, so it becomes available for Amazon Connect to use, as illustrated in the following diagram.

19
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Technical considerations

You can then assign the number to user journeys or functions, and manage it as if it were a natively
sourced DDI in AWS. This simplifies billing and provides flexibility, because you can manage telephone
numbers in the Amazon Connect console instead of relying on a third-party carrier to process service
requests.

Separate AWS accounts – Set up different AWS accounts for your Amazon Connect development,
testing, and production instances. This approach separates those activities and limits the impact of
changes to a single account. It also provides billing boundaries so that the appropriate business unit can
pay for development, testing, and production work.

You can create new accounts with specific policies, rules, and principles, based on predefined templates.
This means that any build or configuration in that account will have to comply with the specifications
defined by the organization. You can use AWS Organizations to centrally manage and govern accounts.

Logging and alerting – Enable Amazon CloudWatch Logs to track usage thresholds and errors in contact
flows. You can view usage and errors by using CloudWatch dashboards. You can also proactively send
alerts through email or SMS text messages. By gaining visibility into low-level system behavior, you
can identify and resolve issues quickly before they become bigger problems. An example of a proactive
alerting solution for Amazon Connect is described in the blog post Monitor and trigger alerts using
Amazon CloudWatch for Amazon Connect.

Single sign-on (SSO) – Use SSO to enable users to log in to Amazon Connect by using their corporate
credentials (for example, through Active Directory) instead of requiring a separate username and
password. This provides the optimum user experience because it doesn’t require an additional login step
or another set of credentials. It also avoids the need to centrally manage separate login credentials for
password resets and other operations. Amazon Connect supports a number of identity management
integration patterns. For more information, see Plan your identity management in Amazon Connect in
the Amazon Connect Administrator Guide.

Workstation devices – Verify that end-user (for example, agent and supervisor) machines meet the
minimum CPU and memory requirements noted in the Agent headset and workstation requirements for
the CCP section of the Amazon Connect Administrator Guide. If you’re planning to use these workstations
for tasks outside contact center work, they should meet higher requirements. Use the Amazon Connect
Endpoint Test Utility to check device and network compatibility. We recommend that you run this utility
on a variety of agent workstations at different locations, including agents who are working from home or
from distinct network-island locations, to ensure compatibility across your organization.

Virtual desktop infrastructure (VDI) environments – Consider network and deployment optimizations
for virtual desktop users.

Headsets – Use wired USB-powered headsets to ensure a consistent audio experience. Discourage the use
of bluetooth or wireless headsets, which can add latency and reduce audio quality.

20
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Operational considerations

Wired network connections – Devices should use wired (Ethernet) connections to ensure a stable,
high-quality audio experience. Verify that devices have wired ports. If a dongle is required, it must be
budgeted and procured before migration.

Microphone and speaker settings – If your organization uses multi-purpose devices, confirm that shared
use of microphones and speakers is allowed (turn off exclusive mode). For guidance, see One-way audio
from customers? in the Amazon Connect Administrator Guide. This guidance applies to both speakers and
microphones.

Dedicated devices (ideal) – If possible, users should be given devices for exclusive contact center use. You
can then optimize these devices for the contact center experience, and use different devices for other
duties.

Legacy habits – Watch out for legacy user behavior that might affect new processes. For example:

• Do agent devices predominantly connect over Wi-Fi today? If so, requiring wired connections will be a
cultural shift for agents and might lead to poor compliance and call experience. An end-user education
campaign might be required to drive this culture shift.
• Do agents use other collaboration applications (such as Microsoft Teams or Zoom) on their devices?
This can lead to conflicting demands for speaker and microphone devices on the device, such as when
Amazon Connect tries to deliver an incoming call while the agent is on another call. It can also lead to
agents missing customer calls because they are busy making internal calls. We recommend removing
other collaboration applications, where practical, to avoid call clashes.

Operational considerations
The best practices in this section focus on smoothing operations and keeping end-users happy with
the new contact center platform and processes so they can provide constructive feedback. If end-users
feel ignored or under-valued during the project, they will be reluctant to move to the new platform. If
end-users are unhappy, the migration will be considered a failure regardless of how well the technology
performs.

Shifting to soft phones – Will this be the first time agents use a soft phone, which provides the phone
interface on the screen, because they currently control calls through a physical desk phone? If so, it
might be difficult for agents to transition from pressing buttons on a desk phone to using a soft phone
keypad on a PC.

• Make sure that adjustment time is included in the training schedule. Expect a learning curve after the
new contact center goes live.
• Accessibility might be a concern for agents who are used to desk phones, which are tactile devices.
Consult agents who have accessibility concerns and include their feedback in design specifications for
the soft phone color scheme and keypad button sizes.

Desk phone alternative – Agents can have calls delivered to a desk phone, as explained in the Amazon
Connect setup instructions, as an alternative to a soft phone. This alternative handset must have a
publicly reachable phone number, which is then configured in the agent profile. For example, this can be
useful when a remote internet connection cannot support high-quality audio on the soft phone audio. In
this case, the audio is sent across the traditional (PSTN) phone network.

Device inventory – Ensure that end-users have the right equipment on the day the new contact center
goes live:

• Desk phones are no longer needed, so they can be decommissioned to free up desk space.
• Devices (such as laptops) might need Ethernet dongles to support hardwired Ethernet connections.
Issue these to users before the go-live date to avoid last-minute demands that will affect your local IT
parts team.

21
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Operational considerations

• Devices might have to provide faster CPU and more memory to run soft phone and business
applications in parallel. Perform real-life testing (during UAT) with end-users by using the soft phone
alongside their usual applications, to see if devices remain performant.

Support model (raising support tickets, levels 1-3 technical support desk ownership) – Work with your
AWS account team, such as your technical account manager (TAM), to verify that you're on the most
suitable AWS support plan. Make sure that everyone knows their role in the support model―from
receiving incident reports from end-users to raising incident bridges for business-critical issues. Simulate
an issue by raising a test incident to the level 1 support desk and tracking it through support model
processes. This will help you find gaps in the support model, so you can avoid issues after you go live.

Back office – Consider how tasks will flow between front-office agents and back-office teams. For
example, the process for transferring calls and escalating customer cases might change. Include task
workflows and routing in your test scripts.

Billing – AWS billing costs will increase and legacy platform costs will decrease immediately after the
new contact center goes live. Contact center charges will be subsumed into AWS billing after migration.
Notify your finance and accounting teams of this change so that costs from AWS accounts that host
Amazon Connect instances can be mapped to the appropriate business unit. This is likely the same
business unit that’s responsible for legacy platform charges.

Access permissions – You can provide granular permissions to your contact center users by creating
security profiles in Amazon Connect. This feature enables you to create advanced user access models
based on the principle of least privilege to perform a role. On legacy platforms, permissions are typically
granted too broadly. In contrast, in Amazon Connect, you can give users access to very specific resources
and activities. For example, you can grant employees permission to edit users but not create or delete
them, or to view user journey contact flows but not change them. Granular permissions are a powerful
way to improve user engagement and optimize how responsibilities are distributed across roles and (such
as agents, operators, supervisors, and developers) and teams. In addition to using security profiles, you
can use Amazon Connect with AWS Identity and Access Management (IAM) features and polices. For
more information, see How Amazon Connect works with IAM in the Amazon Connect Administrator Guide.

Service quotas – Service quotas are default settings that protect you from unexpected load and
consumption charges. For example, service quotas can limit you to 10 concurrent calls or 5 phone
numbers per instance. We recommend that you view your service quotas and request increases to
support your expected usage. For more information, see Amazon Connect service quotas in the Amazon
Connect Administrator Guide.

Agility through DevOps – Use a DevOps deployment pipeline to accelerate your release schedules and
deliver new features more frequently. Business owners might have to reset expectations on how quickly
they can release software, because the technology is more agile. Using deployment pipelines enables you
to release smaller code bundles more frequently, so your releases are less risky and reach your customers
faster.

22
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
Before you go live

Migration checklists
Use the following checklists to ensure that you complete important migration activities in the correct
order.

Before you go live

1. Verify that the release passes user acceptance testing (UAT) and that any remaining issues have been
accepted by stakeholders.
2. Plan the phone number cutover:
• If you’re using toll-free number service (TFNS): Verify that the service is ready to repoint to the
Amazon Connect queue phone number. This might be a self-service task or might require a ticket
with the provider, so consider the lead time to complete this task.
• If you’re porting the number to AWS; File a number porting request ticket well before the target
go-live date. (See Number porting in the Best practices for migrations (p. 18) section earlier in this
guide.)
3. Verify that end-users have been trained and know how to use the new platform.
4. Verify that the operations team has signed off on the new platform and has incorporated it into
their support model. For example, the business as usual (BAU) team should be ready to manage any
support tickets that are opened on the new platform.
5. Verify that the code base has been deployed to the production environment.
Note
This activity might require its own change request (CR), which would be submitted before and
separately from the go-live CR for cutover.
6. Verify that the service lines that are in scope have successfully run UAT scripts by using a temporary
phone number.
7. Submit a change request (CR) for go-live cutover and gain approval from the relevant change approval
board (CAB). The evidence from this checklist is provided as input into the CAB discussion. The
outcome of the CAB discussion is an approval to perform a cutover on a specific date and time.

On the day you go live

1. Ensure that agents are logged in to Amazon Connect and are available to receive and make calls and
participate in chats. Supervisors and operators can check agent activity by using real-time reports on
the Amazon Connect dashboard.
2. Ensure that the post go-live support (PGLS) team is present and ready.
3. (Optional) Confirm that staff who can assist agents and help troubleshoot problems is in position (on-
site or at remote help desk).
4. Ensure that BAU support teams are aware of the cutover time and are ready to handle any support
tickets.
Note
The PGLS team works alongside the BAU support teams.
5. Open a conference bridge for stakeholders to receive status updates. This bridge also serves as a
forum to discuss any issues that might occur. Keep the bridge open until go-live (or rollback) activities
have been completed successfully.

23
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect
On the day you go live

6. Initiate the cutover (for example, the TFNS repoint) at the approved time.
7. Review real-time metrics on the Amazon Connect dashboard to verify the following:
• Calls are being answered.
• Abandonment rates and average handle times (AHT) are as expected.
• Queue depth remains sensible.

24
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Post-migration optimizations
Your work to develop and improve the user experience doesn’t end on the day you go live. Amazon
Connect and AWS have tools that provide detailed business insights, from granular reporting to fraud
detection and voice biometrics driven by artificial intelligence (AI). This information helps you add new
and innovative capabilities, and transform the customer and agent experience in your contact center.

You can use agile delivery methods to deliver new capabilities as sprint iterations after you go live. You
can prioritize new capabilities and optimizations, and add them to a sprint backlog.

Examples of innovative capabilities that help deliver significant changes in operations and user
experiences include the following:

• Amazon QuickSight dashboards provide easy-to-use metrics and graphical reports, and enable
supervisors to monitor agent utilization to ensure balanced staffing across teams.
• Proactive alerting through email and SMS when defined operational thresholds are breached helps
you identify problems before an issue or outage occurs. For example, if queue depth or average
handle time (AHT) values rise above a defined limit, proactive alerting enables supervisors to rapidly
intervene.
• Contact Lens for Amazon Connect performs sentiment analysis by using AI and speech recognition to
transcribe a call. It can generate alerts on profanity or negative sentiments, and enable supervisors
and agents to escalate these problems.
• Amazon Connect Voice ID provides voice biometrics based on a few seconds of speech audio. This
voice print can be gathered during normal conversation with a bot or agent and eliminates having to
remember pass phrases and secret answers. This feature greatly improves customer experience and
reduces agent handle time.
• Amazon high-volume outbound dialer provides a a way to reach millions of customers to communicate
news, reminders, and delivery notifications without requiring any third-party tools. This feature
automates dialing and includes voice mail detection to connect agents to real customers with minimal
effort, without having to look up customer records manually.
• An array of AWS-powered data analytics, AI, and machine learning (ML) tools are available, including
Amazon Athena, Amazon Comprehend, and Amazon SageMaker. Apply models to look for trends in
interactions that could lead to business insights, such as:
• Fraud detection
• Frequent utterances, to identify what people are calling about, possibly leading to proactive
messaging campaigns or contact center team changes
• High-touch customers who call more frequently than others, possibly allowing targeted outreach by
an agent to preempt them from calling in

A successful migration is only the start of the journey to reimagine and transform your contact center.
AWS services provide innovative experiences that you can add to your contact center to generate unique
customer and agent experiences.

25
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Next steps
If you’re planning to migrate your contact center to the cloud, you might be concerned about how the
migration will affect your customer portal and your brand. If you have the right vision, a robust delivery
plan, and continued innovation after you go live, the migration can be a success from multiple angles:
technical, operational, and financial.

Include some form of transformation in the initial phase of your migration plan to improve the customer
experience. Establish mechanisms to work back from the customer and to listen to the voice of the
customer to fuel this innovation. Use real data and end-user insights as much as possible. Ultimately
these innovations will reduce customers’ efforts to resolve issues and will increase customer retention
and loyalty.

This strategy is a starting point for planning your migration journey. Reach out to your AWS account
manager or fill out the AWS Professional Services form for more information or if you need help in any
of these areas:

• Resource constraints
• Help developing AWS competencies and skills
• Help working with agile methodologies
• Time constraints, need for acceleration

26
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Resources
Books

• Dixon, Matthew, Nick Toman, and Rick DeLisi. 2013. The Effortless Experience: Conquering the New
Battleground for Customer Loyalty.

Case studies

• The Amazon Connect Customers website has a list of case studies categorized across industries.

Partners

• Amazon Connect Delivery Partners are AWS Partners who help companies build cloud contact centers
with Amazon Connect. These AWS Partners can help you improve customer experiences and outcomes
through Amazon Connect.

Official blog

• AWS Contact Center Blog hosts articles written for business and technical users. Use these to discover
market insights, new ideas, and ways to optimize your contact center.

AWS Online Tech Talks

• Migration Best Practices and Resources: Moving Your Contact Center to Amazon Connect

Useful links

• AWS Migration Acceleration Program (MAP)

• AWS Cloud Adoption Framework (AWS CAF)
• AWS Professional Services (contact AWS Sales from this page)
• AWS Prescriptive Guidance
• Amazon Connect Administrator Guide
• Amazon Connect resources

27
 AWS Prescriptive Guidance Strategies for
migrating your contact center to Amazon Connect

Document history
The following table describes significant changes to this guide. If you want to be notified about future
updates, you can subscribe to an RSS feed.

Change Description Date

Initial publication (p. 28) — August 24, 2022

28