실행은 계획이 현실로 바뀌는 곳입니다. 이 단계에는 모든 사람이 변경에 대비하고, 비프로덕션 환경에서 개발 작업을 수행하는 작업이 포함됩니다. 철저하게 테스트하고 제어된 방식으로 프로덕션에 배포합니다. 변경이 중요할 수 있다는 점을 감안할 때 비즈니스 중단을 최소화하기 위해 엄격한 테스트 및 안전한 배포 관행에 중점을 둡니다.
현대화를 위한 관련자 준비
배포 단추를 누르기 전에 모든 이해 관계자와 사용자가 예정된 작업을 준비하는 것이 중요합니다. 놀라움은 혼란이나 운영 문제로 이어질 수 있습니다. 주요 준비 단계에는 통신, 변경 동결(앞에서 언급) 및 지원 계획이 포함됩니다.
모든 관련자에게 배포 일정을 알릴 수 있습니다. 현대화 배포가 수행되어야 하는 경우와 예상되는 작업을 영향을 받는 모든 당사자와 사전에 통신하세요. 이해 관계자가 적절하게 준비할 수 있도록 변경 동결 시작 및 라이브 전환 기간과 같은 주요 날짜를 포함합니다. 기대치를 설정하면 사용자는 가동 중지 시간을 계획하고 내부 팀을 준비할 수 있습니다.
원본 및 종속 워크로드에 대한 변경 중지를 구현합니다. 거버넌스의 앞부분에서 계획한 대로 지금은 실제로 동결을 시행할 때입니다. 배포 전과 배포 중에 일정 기간 동안 워크로드(및 종속 워크로드)에서 코드 변경, 구성 조정 또는 기타 배포가 발생하지 않도록 합니다. 이렇게 하면 환경을 안정적으로 유지할 수 있습니다. 모든 팀 구성원과 통합된 제3자가 알고 있는지 확인합니다. 혼동을 방지하기 위해 특정 시작 및 종료 시간을 사용하여 고정 창을 명확하게 정의합니다.
최종 사용자 작업 및 배포 후 변경 내용을 전달합니다. 사용자는 워크플로 중단을 방지하기 위해 배포 전후에 필요한 작업에 대한 사전 알림이 필요합니다. 컷오버가 시작되기 전에 사용자에게 로그아웃하거나 작업을 저장하도록 안내합니다. 새 액세스 URL, Microsoft Entra ID 로그인 요구 사항과 같은 인증 변경 내용 및 매일 작업에 영향을 주는 업데이트된 워크플로를 공유합니다. 첫날 혼동을 줄이기 위한 지원 설명서 및 빠른 시작 가이드를 제공합니다.
배포를 위한 지원 인력을 조정합니다. IT 운영 및 개발 팀은 중요한 배포 단계에서 문제를 모니터링하고 대응할 수 있어야 합니다. 문제가 발생할 가능성이 가장 큰 경우 배포 후 첫 번째 영업일에 대한 추가 지원 시간 및 기타 직원을 예약합니다. 신속한 문제 해결을 위해 배포 후 지원 계획 및 에스컬레이션 절차를 사업부에 알릴 수 있습니다.
중요한 워크로드에 대한 대체 프로시저를 정의합니다. 중요 업무용 워크로드에는 배포 기간 동안 비즈니스 작업을 유지하기 위한 수동 해결 방법 및 대체 계획이 필요합니다. 워크로드 읽기 전용 기간 동안 수동 순서 처리와 같은 특정 절차를 문서화합니다. 이러한 절차를 미리 공유하고 필요한 경우 원활한 실행을 보장하기 위해 영향을 받는 팀과 준비 상태를 확인합니다.
비프로덕션 환경에서 현대화 개발
현대화 변경 내용의 모든 개발 및 통합은 프로덕션 외부에서(개발, 테스트, 스테이징 환경에서) 발생해야 합니다. 기본 원칙: prod와 유사한 환경에서 먼저 빌드 및 테스트하므로 prod에 배포할 때 이미 알려진 수량입니다.
구현하는 동안 Well-Architected Framework 원칙을 따릅니다. 새 변경 내용을 코딩하고 구성할 때 Azure의 WAF(Well-Architected Framework)에서 모범 사례를 지속적으로 적용합니다. Azure Advisor 권장 사항 및 아키텍처 검토 프로세스를 사용하여 디자인 결정의 유효성을 검사합니다. 이 접근 방식은 현대화된 구성 요소가 Azure 모범 사례 및 운영 표준을 충족하도록 보장합니다.
프로덕션을 미러링하는 비프로덕션 환경을 만듭니다. 프로덕션 설정에 최대한 가까운 Azure에서 개발/테스트 환경을 실행합니다. 프로덕션에서 특정 Azure 서비스를 사용하는 경우 동일한 테스트, 더 작은 규모 또는 낮은 성능 계층(SKU)을 사용하여 비용을 절감합니다. 테스트 환경이 프로덕션 환경에 가까울수록 테스트 결과가 프로덕션 동작으로 이월되어야 한다는 확신을 가질 수 있습니다.
소스 제어 및 CI/CD를 사용하여 변경 내용을 증분 방식으로 구현합니다. 현대화 작업을 다른 소프트웨어 프로젝트와 같이 처리합니다. 모든 코드 변경 내용 및 인프라에 대해 Git 또는 기타 소스 제어를 코드 스크립트로 사용합니다. 필요한 경우 코드를 롤백하는 기록 및 기능을 제공합니다. 작업을 작은 작업 단위(기능별 또는 수정별)로 분할하고 기능별 분기를 사용합니다. 코드 검토 후 변경 내용을 자주 병합합니다. 각 커밋에서 테스트 도구 모음을 실행하도록 연속 통합 빌드를 설정하여 문제를 조기에 파악할 수 있습니다.
테스트를 사용하여 현대화 변경 내용 유효성 검사
테스트는 중요합니다. 현대화는 새로운 기능을 추가하지 않으므로 회귀 테스트(중단된 항목 없음) 및 성능/보안 테스트(이전보다 더 잘 작동하며 더 나빠지지 않음)에 초점을 맞춥니다. 프로덕션을 터치하기 전에 테스트 환경에서 워크로드의 모든 측면을 확인하려고 합니다.
수정된 모든 구성 요소에서 단위 및 통합 테스트를 실행합니다. 개발자는 리팩터링된 모든 코드에 대한 단위 테스트를 만들거나 업데이트해야 합니다. 레거시 코드인 경우에도 중요한 함수에 대한 단위 테스트를 작성하면 리팩터링이 실수로 변경된 동작을 catch하는 데 도움이 될 수 있습니다. CI 파이프라인에서 단위 테스트를 지속적으로 실행합니다. 또한 통합 테스트를 실행하여 구성 요소가 서로 올바르게 통신하는지 확인합니다. 버그가 수정된 후 관련 테스트를 다시 실행하여 버그가 실제로 해결되고 다른 문제가 발생하지 않도록 합니다(회귀 방지).
엔드 투 엔드 기능 테스트를 수행합니다. 스테이징 또는 테스트 환경에서는 마치 최종 사용자인 것처럼 전체 워크플로 테스트를 수행합니다. 이 테스트는 QA 또는 자동화된 UI 테스트를 통해 수동으로 테스트할 수 있습니다. 애플리케이션에 로그인하고 주요 작업을 수행합니다. 변경되지 않은 기능이 변경되지 않은 상태로 유지되는지 확인합니다. 기본적으로 단위 테스트가 놓칠 수 있는 모든 항목을 catch하기 위해 실제 사용을 시뮬레이션합니다.
관련자와 함께 UAT(사용자 승인 테스트)를 수행합니다. 라이브로 전환하기 전에 일부 실제 최종 사용자 또는 비즈니스 이해 관계자가 현대화된 워크로드를 테스트하는 것이 좋습니다. 개발자가 간과하는 뉘앙스를 포착할 수 있습니다. 유용성, 성능 및 기능 차이에 대한 피드백을 캡처합니다. 배포 전에 중요한 UAT(사용자 승인 테스트) 문제를 해결하고 관련자로부터 공식적인 승인을 받아 비즈니스 준비 상태를 확인합니다.
실제 조건에서 부하 테스트를 사용하여 성능의 유효성을 검사합니다. 현대화는 성능을 향상시키거나 유지 관리하는 것이 이상적입니다. 부하 테스트 도구(예: Azure Load Testing)를 사용하여 실제 사용 패턴을 시뮬레이션합니다. 원본 환경의 성능 기준과 결과를 비교하여 성능 저하를 식별합니다. 예상 부하의 150% 스트레스 테스트를 수행하여 워크로드 제한을 확인하고 압력을 받고 있는 복원력의 유효성을 검사합니다.
보안 유효성 검사 및 규정 준수 검사를 실행합니다. 새 코드 및 컨테이너 이미지에 대한 취약성 검사를 실행하여 보안 위험을 검색합니다. 산업별 도구를 사용하여 규제된 워크로드에 대한 규정 준수 유효성 검사를 수행합니다. 클라우드용 Microsoft Defender를 사용하여 인프라 잘못된 구성을 검색하고 요구 사항을 충족하는 보안 제어의 유효성을 검사합니다.
프로덕션 배포 전에 모든 중요한 문제를 해결합니다. 테스트 단계에서 식별된 기능, 성능 및 보안 문제를 해결합니다. 모든 테스트가 통과되고 성능이 SLA(서비스 수준 계약)를 충족하는지 확인합니다. 나머지 우선 순위가 낮은 문제를 문서화하고 배포 후 해결을 위한 수정 계획을 만듭니다.
재사용 가능한 인프라 만들기
현대화된 솔루션이 비프로덕션 환경에서 모든 테스트를 통과하면 인프라 설정 및 구성을 코드로 캡처해야 프로덕션 및 향후 환경에서 쉽게 복제할 수 있습니다. 재사용 가능한 인프라는 일관성과 속도를 위해 IaC(Infrastructure-as-code) 템플릿 및 자동화를 사용하는 것을 의미합니다.
검증된 구성에 대한 IaC 템플릿을 만듭니다. 테스트 환경의 최종 아키텍처(prod에서 원하는 것을 반영)를 가져와서 명문화합니다. Bicep, Terraform 또는 Azure Resource Manager 템플릿을 사용하여 인프라를 정의합니다. 이러한 템플릿을 매개 변수화하여 개발, 테스트, 이름 또는 크기와 같은 작은 조정으로 prod와 같은 다양한 단계에서 다시 사용할 수 있습니다. 이 설정은 사용자가 만든 프로덕션 환경이 테스트한 환경과 일치하도록 합니다. 리소스를 만들기 위해 Azure Portal을 수동으로 클릭할 때 발생하는 사용자 오류를 방지합니다. 또한 재해 복구 또는 새 지역에 배포하는 것과 같이 환경을 다시 만들어야 하는 경우 인프라 배포가 준비됨을 의미합니다. 자세한 내용은 CAF 관리 - 코드 기반 배포 관리를 참조하세요.
버전 제어에 템플릿을 저장합니다. 인프라 코드를 Git 리포지토리(애플리케이션 코드와 함께 또는 별도의 리포지토리)로 확인합니다. GitHub 또는 Azure DevOps를 사용하여 적절한 버전 제어를 사용하여 IaC 자산을 관리합니다. 버전 제어를 사용하면 코드 검토를 사용하도록 설정하고, 팀 공동 작업을 지원하며, 프로젝트 간에 템플릿을 다시 사용하도록 권장합니다. 이 방법은 인프라 변경에 대한 완전한 추적 기능을 제공하고 문제가 발생할 때 롤백 기능을 지원합니다.
종속성 설치 및 구성을 자동화합니다. 스크립트 또는 파이프라인 작업을 만들어 이러한 템플릿을 배포하고 필요한 구성 또는 시드 작업도 처리합니다. Azure Pipelines, GitHub Actions를 사용하여 IaC 템플릿을 사용하고 대상 구독/리소스 그룹에 배포하는 배포 작업을 실행합니다. 앱 종속성 설치, 설정 구성 및 비밀 관리를 자동화합니다. 목표는 한 번의 클릭(또는 한 명령) 환경 설정입니다. 아무것도 없는 환경부터 테스트한 것과 일치하는 완전히 실행 중인 환경까지입니다.
IaC 및 자동화 전체 과정을 테스트합니다. 별도의 Azure 구독 또는 리소스 그룹을 샌드박스로 사용하고 템플릿 및 스크립트를 사용하여 전체 환경을 처음부터 배포하는 방법을 연습합니다. IaC 템플릿, 파이프라인 및 스크립트가 아무것도 없는 전체 인프라 스택을 만들 수 있도록 테스트합니다. 초기 배포, 구성 업데이트 및 롤백 절차를 비롯한 다양한 배포 시나리오를 테스트하여 자동화가 제대로 작동하는지 확인합니다.
자세한 내용은 WAF 의 코드로 워크로드 개발 공급 변경 및 인프라 설계를 참조하세요.
배포 설명서 만들기
자동화를 사용하더라도 감사, 새 팀 구성원 온보딩 및 향후 유지 관리에 배포에 대한 좋은 설명서를 보유하는 것이 중요합니다. 배포 설명서에는 사람이 읽을 수 있는 형식의 구성, 절차 및 롤백 단계가 설명되어 있어야 합니다.
문서 구성 설정 및 단계. 액세스 가능한 설명서에 모든 환경별 설정, 연결 문자열, 서비스 엔드포인트 및 보안 구성을 기록합니다. 단계별 배포 지침, 필수 구성 요소 요구 사항 및 배포 후 유효성 검사 단계를 포함합니다. 이 설명서는 일관된 배포를 가능하게 하고 문제가 발생할 때의 문제 해결을 지원합니다. 새 엔지니어가 배포해야 하는 경우 이 문서를 읽고 파이프라인의 출력을 따르거나 이해할 수 있습니다.
롤백 및 복구 절차를 업데이트합니다. 테스트를 완료한 후 배포 문제가 발생할 때 변경 내용을 되돌리는 단계를 공식화합니다. 롤백 트리거, 데이터 백업 및 복원 절차 및 복구 유효성 검사 단계를 포함합니다. 롤백 및 복구 프로시저를 정기적으로 테스트하여 필요할 때 제대로 작동하는지 확인합니다. 이 준비는 가동 중지 시간을 줄입니다.
이 모든 설명서를 중앙 위치에 수집합니다. SharePoint, GitHub 또는 Wiki를 사용하여 이 정보를 저장합니다. 팀과 지원 담당자가 찾을 위치를 알고 있는지 확인합니다. 스트레스가 높은 사건에서 명확한 문서를 손에 들고 있는 것은 생명의 은인입니다.
현대화 배포
프로덕션 배포는 현대화 노력의 절정입니다. 선택한 전략(현재 위치 및 병렬)에 따라 단계가 다릅니다. 실행하기 전에 이해 관계자에게 알림, 동결, 수행된 백업, 대기 상태 모니터링 등 모든 준비 단계가 수행되는지 다시 확인합니다.
시스템 내 현대화 배포
유지 관리 기간 예약 변경 내용에 데이터베이스 스키마 마이그레이션과 같이 리소스를 잠그는 가동 중지 시간 또는 실행 중인 스크립트가 필요한 경우 미리 예고된 유지 관리 기간에서 수행합니다. 모든 사용자가 해당 시간에 워크로드를 해제하는지 확인합니다. 또한 명확한 창을 사용하면 배포를 완료하거나 시간이 부족한 경우 롤백을 결정할 수 있는 대상이 됩니다.
배포에 CI/CD 파이프라인을 사용합니다. 프로덕션 배포는 테스트에 사용했지만 프로덕션 환경을 가리키는 것과 동일한 자동화된 파이프라인을 사용해야 합니다. 이 설정은 일관성을 보장하므로 인프라와 코드가 동일한 방식으로 배포됩니다. 실행하기 전에 중요한 데이터(데이터베이스)의 최종 백업을 수행합니다. 롤백할 수 있더라도, 뭔가 문제가 발생할 경우 백업을 갖는 것은 추가 안전망입니다. 파이프라인을 실행하여 새 코드 및 인프라 변경 내용을 배포합니다. 로그 및 모니터링을 실시간으로 볼 수 있습니다. 단계가 실패하면 일시 중지하고 앞으로 수정할 수 있는지 또는 롤백해야 하는지 평가합니다.
가능하면 점진적 트래픽 라우팅(카나리아)을 구현합니다. 많은 Azure 서비스는 현재 위치 시나리오에서도 슬롯 교환 또는 점진적 트래픽 이동을 허용합니다. Azure는 Azure App Service 배포 슬롯, Azure Container Apps 트래픽 분할, 및 Azure Pipelines를 사용하는 Azure Kubernetes Service을 통해 카나리아 배포를 지원합니다. 부하 분산 장치 뒤에 여러 가상 머신이 있는 경우 다른 가상 머신이 트래픽을 처리하도록 한 번에 하나의 인스턴스(롤링 업그레이드)를 업데이트한 다음 순환적으로 처리합니다.
모니터링하면서 점차적으로 전체 트래픽을 증가시키십시오. 새 버전이 라이브 상태가 되면 자세히 모니터링합니다. 애플리케이션 로그, 성능 메트릭, 오류 비율을 확인합니다. 소수의 사용자로 시작하거나 가능한 경우 유효성 검사 모드에서 워크로드를 시작합니다. 몇 분 후에 모든 것이 문제 없으면 트래픽을 25%로 증가시킵니다. 메트릭을 다시 확인합니다(500개의 오류가 급증하지 않고 응답 시간이 정상임). 계획한 기간에 따라 50%까지 증가시키고, 그 후 100%까지 증가시킵니다. 주의하려는 경우 한 시간 이상이 될 수 있습니다. 어떤 단계에서든 심각한 문제가 관찰되면 모든 사용자에게 영향을 미치기 전에 롤백을 시작합니다.
배포하는 동안 데이터 일관성을 유지 관리합니다. 인플레이스 배포는 데이터 스키마를 수정할 가능성이 있으면서도 기존 데이터 엔드포인트를 유지합니다. 이전 버전과 호환되는 방식으로 데이터베이스 스키마 변경 내용을 적용하여, 구버전과 신버전 애플리케이션을 모두 지원합니다. 배포가 성공적으로 완료될 때까지 기존 구조를 제거하지 않고 새 열 또는 테이블을 추가하는 데이터베이스 마이그레이션 스크립트를 사용합니다.
병렬 환경에 현대화 배포
병렬 프로덕션 환경을 만듭니다. IaC 템플릿을 사용하여 Azure에서 테스트한 내용을 반영하는 새 프로덕션 환경을 만듭니다. 이 환경에는 모든 컴퓨팅, 네트워킹, 스토리지가 포함됩니다. 작동 중이지만 현재 사용자 트래픽은 없습니다. 네트워크 보안 그룹, 방화벽, ID(관리 ID 또는 서비스 주체) 및 모니터링이 모두 필요에 따라 구성되었는지 확인합니다(기본적으로 prod 구독에서 테스트 env 설정을 반복).
데이터베이스 복제를 설정합니다. 원본과 Azure 대상 워크로드 간에 연속 데이터 복제를 설정하도록 데이터베이스 플랫폼의 네이티브 복제 기능을 구성합니다. 초기 데이터 동기화가 성공적으로 완료되고 복제가 정상인지 확인합니다. 백업 또는 스냅샷에서 데이터베이스의 초기 대량 복사를 수행한 다음 새 트랜잭션에 대해 복제를 사용하도록 설정할 수 있습니다. 데이터베이스 플랫폼의 모니터링 도구를 사용하여 복제 지연을 모니터링합니다. 대기 시간이 높을수록 중단 위험 및 기간이 증가합니다. 복제 지연 시간이 0이 될 때까지 다음 단계로 진행하지 마세요.
구조화되지 않은 데이터 및 파일을 복사합니다. 최종 중단 전에 구조화되지 않은 데이터 및 파일을 Azure에 복사합니다. 기능을 사용하여 개체 및 파일 마이그레이션을 위한 도구를 사용하여 적절한 Azure Storage 서비스로 파일을 전송합니다. 이 준비는 최종 컷오버 중에 복사해야 하는 데이터의 양을 줄입니다.
최종 데이터 동기화를 완료합니다. 전환 순간에 데이터 손실이 0이거나 최소화되기를 원합니다. 데이터베이스의 경우 소스 워크로드에 보류 중인 트랜잭션이 없고, 데이터베이스 복제가 최신 상태인지 확실히 확인하는 절차를 거치세요. 경우에 따라 원본 데이터베이스에서 쓰기를 잠시 일시 중지하여 최종 변경 내용을 플러시해야 할 수 있습니다(특히 트랜잭션 일관성과 같은 경우). 트랜잭션 로그 전달 또는 짧은 가동 중지 시간과 같은 기술을 사용하여 마지막 증분 백업 복원을 수행할 수 있습니다. AzCopy 또는 유사한 도구를 사용하여 수정된 구조화되지 않은 데이터를 복사합니다.
사용자 트래픽을 새 환경으로 점진적으로 줄입니다. 사용자 트래픽을 Azure 환경으로 보내도록 DNS 레코드 및 부하 분산 장치 구성을 업데이트합니다. 워크로드 상태 및 성능을 모니터링합니다. Azure 부하 분산 장치에서 가중 라우팅을 사용하여 현대화된 워크로드로 전달되는 라이브 트래픽의 1%부터 시작합니다. 응답 시간, 오류 비율 및 데이터베이스 연결 상태를 포함한 실시간 메트릭을 모니터링합니다. 임계값을 초과하는 경우 자동화된 롤백 트리거를 사용하여 시간보다 몇 분 동안 트래픽을 빠르게 증가(5%, 15%, 50%)합니다.
100%로 최종 전환합니다. 확신이 있으면 모든 사용자를 새 환경으로 라우팅합니다. 이 스위치는 TTL(Time to Live) 값이 낮았을 경우 몇 초에서 몇 분 정도가 걸릴 수 있는 DNS 절체 또는 로드 밸런서 구성을 전환하는 작업일 수 있습니다. 이 시점에서 사용자는 현대화된 워크로드에 살고 있습니다.
즉시 전환 작업 후 확인하고 모니터링합니다. 전환 후 유효성 검사를 수행하십시오. 자동화된 테스트 제품군을 사용하여 모든 중요한 비즈니스 프로세스의 엔드 투 엔드 기능 테스트를 수행합니다. 원본 워크로드와 대상 워크로드 간의 체크섬 확인 및 해시 함수 비교를 사용하여 데이터 정확도의 유효성을 검사합니다. 워크로드 소유자가 모든 주요 함수가 올바르게 작동하는지 확인합니다. 중단 후 처음 24~48시간 동안 워크로드 성능, 오류 비율 및 사용자 액세스 패턴을 모니터링하여 성능 저하 또는 기능 문제를 식별합니다.
이전 환경을 잠시 동안 실행(활성 대기)으로 유지합니다. 아직 아무것도 찢어하지 마십시오. 가능한 경우 진행 중인 데이터 동기화(또는 신속하게 동기화할 준비가 됨)를 사용하여 이전 워크로드를 최소 24-72시간 동안 핫 대기 상태로 유지하는 것이 좋습니다. 프로덕션 환경에서 예기치 않은 심각한 문제가 발생하면 트래픽을 다시 전달하여 롤백을 결정할 수 있습니다. 데이터 손실을 최소화할 수 있습니다. 로그 또는 다른 방법을 통해 따라잡을 수 있기 때문입니다.
현대화 성공 유효성 검사
이제 새 워크로드가 라이브 상태가 되었으므로 프로덕션 환경에서 모든 것이 의도한 대로 작동하는지 유효성을 검사하고 수용 기준을 충족해야 합니다.
성공적인 사용자 액세스 및 워크로드 성능을 확인합니다. 사용자 액세스 유효성 검사를 통해 현대화가 투명하고 성능이 기대에 부합하는지 확인합니다. 이 확인은 사용자가 중단 없이 워크로드에 액세스할 수 있음을 확인합니다. 초기 마이그레이션 후 기간 동안 사용자 액세스 패턴, 워크로드 성능 메트릭 및 오류 비율을 모니터링합니다.
철저한 유효성 검사 후에만 마이그레이션 성공을 발표합니다. 완전한 유효성 검사를 수행하면 모든 관련자가 워크로드가 안정적이고 기능적인지 확인합니다. 이 확인은 나중에 문제가 발생할 수 있는 조기 성공 선언을 방지합니다. 워크로드 소유자, 테스터 및 비즈니스 관련자로부터 워크로드가 모든 요구 사항을 충족하고 올바르게 작동한다는 확인을 받습니다.
안정화 중 워크로드 지원
성공적인 출시 후에도 워크로드에 각별한 주의를 기울이는 안정화 기간을 계획합니다. 새로 현대화된 워크로드에는 몇 시간 후에 실제 사용 패턴에만 나타나는 알 수 없는 문제가 있을 수 있습니다.
안정화 기간 동안 향상된 지원 범위를 설정합니다. 라이브로 전환한 후 처음 며칠 또는 몇 주 동안(복잡성에 따라) 지원 프로토콜이 강화됩니다. 숙련된 IT 직원 또는 마이그레이션 파트너를 할당하여 워크로드를 면밀히 모니터링하고 일반 작업보다 짧은 SLA를 제공합니다.
운영 설명서 및 도구를 업데이트합니다. 모든 Runbook, 지원 문서 및 모니터링 구성이 새로운 현실을 반영하도록 업데이트되었는지 확인합니다. 새 백업 프로세스, 마이크로 서비스에 대한 새로운 다시 시작 절차와 같은 새로운 절차에 대해 운영 팀을 학습시킵니다. 전체 지식 전송을 통해 현대화된 워크로드를 ops/지원 팀에 전달합니다. 자산 인벤토리/CMDB가 새 서버, IP, 서비스를 기록하고 레거시 서버를 제거하거나 표시해야 합니다.