기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 로 어바이어 고객 센터 마이그레이션 계획 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를 사용하는 경우 이러한 통합이 불가능할 수 있으므로 데이터베이스 통합에 의존해야 합니다. 또한 마이그레이션 계획의 모든 기존 통화 흐름을 검토해야 합니다. 서로 다른 두 가지 텔레포니 시스템을 사용하는 하이브리드 접근 방식에서는 흐름의 어떤 부분도 복제하거나 중요한 로직을 무시하지 않도록 해야 합니다.

## IVR 프롬프트 관리
<a name="managing-ivr-prompts"></a>

Amazon DynamoDB는 프롬프트를 저장하고 관리하는 가장 효율적인 방법입니다. 비즈니스와 이해관계자는 운영을 중단하지 않고 즉시 변경할 수 있습니다.

## 클라우드 인프라 및 보안 요구 사항 정의
<a name="defining-requirements"></a>

요구 사항에 따라 성과를 달성하는 데 사용할 클라우드 서비스 목록을 작성합니다. 보안 팀은 제안된 대상 아키텍처가 보존 정책과 같은 조직 요구 사항을 충족하는지 확인하고 로깅을 고려되고 문서화하는지 확인해야 합니다.