本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 計劃將 Avaya 聯絡中心遷移至 AWS
<a name="migration-plan"></a>

若要成功將內部部署Avaya聯絡中心遷移至 Amazon Connect Customer 和 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>

您可以將工作負載*重新託管* （也稱為*lift-and-shift*) 到 AWS 雲端，或者您可以*轉換*或*重新建構*工作負載，以透過雲端原生功能驅動新的體驗。如需如何在這些策略之間進行選擇的詳細資訊，請參閱本指南[步驟 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 for IVR，則可能無法進行此類整合，您必須依賴資料庫整合。此外，您需要檢閱遷移計畫中的所有現有呼叫流程。在具有兩個不同電話系統的混合方法中，請確定您沒有複製流程的任何部分或忽略任何重要的邏輯。

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

Amazon DynamoDB 是存放和管理提示的最有效方式。業務和利益相關者可以即時進行變更，而不會中斷操作。

## 定義雲端基礎設施和安全性需求
<a name="defining-requirements"></a>

根據您的需求，列出您將用來實現成果的雲端服務清單。您的安全團隊需要驗證提議的目標架構是否符合組織需求，例如保留政策，並確保記錄已考慮和記錄。