추측에 의존하지 않는 클라우드 전환.

애플리케이션은 최초 시스템 목록에 나타나지 않는 구성 요소, 즉 디렉터리 서비스, 예약된 백그라운드 작업, 파일 공유, 외부 파트너의 인터페이스 등에 의존할 수 있습니다. 이러한 연결 관계는 담당자와 함께 파악합니다. 이로부터 마이그레이션 그룹이 도출되며, 그 안의 구성 요소는 함께 전환되거나 과도기 동안 의도적으로 연결된 상태를 유지합니다. 데이터 용량, 유지보수 시간대, 참여 가능한 현업 담당자는 순서에 영향을 미칩니다. 이렇게 웨이브 계획은 기술적으로 이전 가능한 시스템 목록에 그치지 않고 실제 업무 절차를 반영합니다.

각 그룹에는 적합한 마이그레이션 경로를 정합니다. 일부 애플리케이션은 처음에는 거의 변경 없이 이전할 수 있고, 다른 애플리케이션은 목표 환경에 맞춘 조정이 필요합니다. 추가적인 현대화는 이전 작업을 불필요하게 키울 경우 별도의 단계로 진행하는 편이 합리적일 수 있습니다. 이 결정은 전환 위험, 이후 운영, 사용 가능한 리소스를 고려합니다. 이전 작업 전에는 목표 환경, 접근 권한, 필요한 연결을 점검하여, 이미 알려진 전제 조건을 예정된 전환 시간대에 가서야 마련하는 일이 없도록 합니다.

전환일에는 데이터 상태, 접근 권한 변경, 업무 검증이 서로 맞아떨어져야 합니다. 그렇기 때문에 조정된 절차는 기존 시스템에서의 작업이 언제 종료되는지, 어떤 데이터가 이전되는지, 그 이후 어떤 테스트가 진행되는지를 설명합니다. 여기에는 담당자와 소통 경로도 포함됩니다. 관련자는 누가 문제를 평가하고 누가 진행 여부를 결정하는지 알아야 합니다. 이때 기술적 접속 가능성은 하나의 점검 단계일 뿐이며, 애플리케이션은 귀사의 비즈니스 운영에 관련된 업무도 실제로 수행할 수 있어야 합니다.

또한 어떤 조건에서 전환을 중단하거나 되돌려야 하는지도 사전에 논의합니다. 롤백이 모든 애플리케이션에서 똑같이 쉬운 것은 아니며, 특히 목표 시스템에 이미 새로운 데이터가 생성된 경우에는 더욱 그렇습니다. 그렇기 때문에 계획에는 예정된 절차의 전제 조건과 한계를 명시합니다. 파일럿과 테스트는 가정을 검증하고 절차를 개선하는 데 활용됩니다. 이러한 결과가 있어야만 다음 마이그레이션 웨이브를 진행할 준비가 되었는지, 아니면 추가 작업이 필요한지를 함께 판단할 수 있습니다.

실제 운영을 시작한 이후에는 변경된 부하, 누락된 권한, 테스트에서 완전히 드러나지 않았던 절차 등 새로운 관찰 사항이 나타날 수 있습니다. 합의된 안정화 단계에서는 이러한 사항을 기록하고 평가하며 처리합니다. 운영으로의 인계에는 구성, 접근 권한, 모니터링, 알려진 잔여 작업이 포함됩니다. 귀사의 애플리케이션 책임자는 업무적 사용 가능성을 확인하며, 기술적 책임과 조직적 책임은 프로젝트 종료 후 누가 추가 신고에 대응하는지 명확히 알 수 있도록 문서화됩니다.

이후 기존 시스템을 검토 없이 계속 운영해서는 안 됩니다. 동시에 운영 종료 작업이 아직 필요한 의존 관계를 제거해서도 안 됩니다. 그렇기 때문에 검수 이후에는 어떤 리소스를 중단하고, 어떤 데이터를 보관하며, 어떤 계약을 조정해야 하는지를 함께 정합니다. 운영 종료 계획에는 순서와 승인 사항을 명시합니다. 이를 통해 중복 비용과 미해결 작업이 계속 파악 가능한 상태로 유지됩니다. 마이그레이션은 데이터가 이제 다른 위치에 있다는 단순한 확인이 아니라, 체계적인 인계와 조정된 후속 작업으로 마무리됩니다.