本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 计划将 Avaya 联络中心迁移到 AWS
<a name="migration-plan"></a>

为了成功将本地Avaya联络中心迁移到 Amazon Connect 客户和 Amazon Lex，您需要制定有效的计划。迁移计划通常采用多阶段方法，包括以下步骤和信息：
+ [构建团队](#building-team)
+ [准备数据](#preparing-data)
+ [移植电话号码](#porting-numbers)
+ [选择一个目标架构](#choosing-architecture)
+ [评估当前架构](#evaluating-architecture)
+ [管理 IVR 提示](#managing-ivr-prompts)
+ [定义云基础设施和安全要求](#defining-requirements)

## 构建团队
<a name="building-team"></a>

联络中心迁移通常由以下专业和参与者组成：
+ **发现**：产品经理、项目经理、业务分析师、解决方案架构师、实施工程师、QA、座席和主管
+ **设计**：对话设计师、软件开发人员、产品经理、项目经理
+ **构建**：软件开发者
+ **测试**：QA
+ **持续集成和持续交付 (CI/CD)** — 云支持或 DevOps
+ **账户配置** — 云支持或 DevOps
+ **运营**：支持工程师
+ **安全**：安全架构师

## 准备数据
<a name="preparing-data"></a>

IVR 工作负载可以分阶段迁移，例如按业务部门迁移。您可以与组织中的业务部门合作定义业务需求并*更换平台*或*重构* IVR 平台，以充分利用云原生功能来提高敏捷性、性能和可扩展性。因此，决定哪个业务部门首先迁移非常重要。记录需求，定义成功指标，并提供进度更新，以衡量项目的整体成功程度。

## 移植电话号码
<a name="porting-numbers"></a>

如果您想保留现有的电话号码，则必须将您的电话号码移植到 Connect Customer。这个流程需要一定的提前期，因此事先规划会很有帮助。

## 选择一个目标架构
<a name="choosing-architecture"></a>

根据您的迁移项目的目标，从本指南的[本地迁移的架构选项 Avaya 联系中心到 AWS](architecture-options.md)部分讨论的可能方法列表中进行选择。

## 评估当前架构
<a name="evaluating-architecture"></a>

您可以将工作负载*重新托管*（也称为*移动）到，也可以重新构建*平台或重新**架构*您的工作负载 AWS Cloud，以利用云原生功能*推动全新的体验。有关如何选择这些策略的更多信息，请参阅本指南中的[步骤 3：选择迁移策略](decision-making-processes.md#step-3)。除了了解目标状态外，了解当前状态和基础设施组件也至关重要。

例如，如果您使用的是 [https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_experience_portal/overview/index.gsp](https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_experience_portal/overview/index.gsp)，则可以使用 JavaScript 进行 API 集成。但是，如果您使用 Concentrix 进行 IVR，则可能无法进行此类集成，并且必须依赖数据库集成。此外，您需要查看迁移计划中的所有现有呼叫流。在使用两种不同电话系统的混合方法中，请确保不要复制流程的任何部分或忽略任何重要的逻辑。

## 管理 IVR 提示
<a name="managing-ivr-prompts"></a>

Amazon DynamoDB 是最高效的存储和管理提示的方式。企业和利益相关者可以在不中断运营的情况下即时做出更改。

## 定义云基础设施和安全要求
<a name="defining-requirements"></a>

根据您的要求，列出您将用来实现成果的云服务。您的安全团队需要验证建议的目标架构是否符合组织要求（例如保留策略），并确保考虑和记录日志记录。