翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# への の移行を計画する 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) を使用している場合は、API 統合に JavaScript を使用できます。一方、IVR に Concentrix を使用している場合、このような統合はできない可能性があるため、データベース統合に依存する必要があります。また、移行計画の既存のコールフローをすべて確認する必要があります。2 つの異なるテレフォニーシステムを使用するハイブリッドアプローチでは、フローの一部を複製したり、重要なロジックを無視したりしていないことを確認してください。

## IVR プロンプトの管理
<a name="managing-ivr-prompts"></a>

Amazon DynamoDB は、プロンプトを保存および管理するための最も効率的な方法です。企業とステークホルダーは、運用を中断することなく、その場で変更を加えることができます。

## クラウドインフラストラクチャとセキュリティ要件の定義
<a name="defining-requirements"></a>

要件に基づいて、成果を達成するために使用するクラウドサービスのリストを作成します。セキュリティチームは、提案されたターゲットアーキテクチャが保持ポリシーなどの組織の要件を満たしているかどうかを検証し、ログ記録が考慮され、文書化されていることを確認する必要があります。