기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 마이그레이션 체크리스트
다음 체크리스트를 사용하여 중요한 마이그레이션 활동을 올바른 순서로 완료하세요.
## 가동 전
1. 릴리스가 사용자 수용 테스트(UAT)를 통과했고 나머지 문제가 이해관계자의 승인을 받았는지 확인합니다.
1. 전화번호 전환을 계획합니다.
+ 수신자 부담 전화번호 서비스(TFNS)를 사용하는 경우: 서비스가 고객 연결 대기열 전화번호를 다시 지정할 준비가 되었는지 확인합니다. 이는 셀프 서비스 작업일 수도 있고 제공업체에 티켓이 필요할 수도 있으므로 이 작업을 완료하는 데 소요되는 리드 타임을 고려하세요.
+ 번호를 로 포팅하는 경우 대상 가동 날짜보다 훨씬 전에 번호 포팅 요청 티켓을 AWS제출합니다. 이 가이드 앞부분의 [마이그레이션 모범 사례](tech-considerations.md) 섹션에서 *번호 이동*을 참조하세요.
1. 최종 사용자가 교육을 받고 새 플랫폼 사용 방법을 알고 있는지 확인합니다.
1. 운영 팀이 새 플랫폼을 승인하고 지원 모델에 통합했는지 확인합니다. 예를 들어, BAU(Business As Usual) 팀은 새 플랫폼에서 개설되는 모든 지원 티켓을 관리할 준비가 되어 있어야 합니다.
1. 코드 베이스가 프로덕션 환경에 배포되었는지 확인합니다.
**참고**
이 활동에는 전환을 위해 실행 CR 이전 및 별도로 제출되는 자체 변경 요청(CR)이 필요할 수 있습니다.
1. 임시 전화번호를 사용하여 범위 내에 있는 서비스 회선이 UAT 스크립트를 성공적으로 실행했는지 확인합니다.
1. 실시간 전환을 위한 변경 요청(CR)을 제출하고 관련 CAB(Change Approval Board)의 승인을 받습니다. 이 체크리스트의 증거는 CAB 토론에 입력으로 제공됩니다. CAB 논의의 결과는 특정 날짜 및 시간에 전환을 수행할 수 있는 승인입니다.
## 가동일에
1. 에이전트가 Connect Customer에 로그인되어 있고 전화를 받고 채팅에 참여할 수 있는지 확인합니다. 감독자와 운영자는 고객 연결 대시보드에서 실시간 보고서를 사용하여 에이전트 활동을 확인할 수 있습니다.
1. PGLS(Post Go-Live Support) 팀이 있고 준비되어 있는지 확인하세요.
1. (선택 사항) 상담원을 지원하고 문제 해결을 도울 수 있는 직원이 현장에 있는지 확인합니다(현장 또는 원격 헬프 데스크).
1. BAU 지원 팀이 전환 시간을 인지하고 지원 티켓을 처리할 준비가 되었는지 확인합니다.
**참고**
PGLS 팀은 BAU 지원 팀과 함께 일합니다.
1. 컨퍼런스 브리지를 열어 이해관계자들이 현황 업데이트를 받을 수 있도록 합니다. 이 브리지는 발생할 수 있는 모든 문제를 논의하는 포럼 역할도 합니다. 가동 또는 롤백 활동이 성공적으로 완료될 때까지 브리지를 열어 둡니다.
1. 승인된 시간에 전환(예: TFNS 재지정)를 시작합니다.
1. 고객 연결 대시보드에서 실시간 지표를 검토하여 다음을 확인합니다.
+ 전화를 받고 있습니다.
+ 포기율과 평균 처리 시간(AHT)이 예상대로입니다.
+ 대기열 깊이가 올바른 상태를 유지합니다.