대부분의 클라우드 마이그레이션 프로그램은 인프라 스캔으로 시작합니다. Azure Migrate는 가상 머신(VM)을 검색하고, AWS Application Discovery Service는 서버를 매핑하며, Google Migration Center는 워크로드를 인벤토리화합니다. 며칠 안에 팀은 모든 서버, CPU 사용률, 메모리 사용량, 그리고 대상 클라우드에서 동일한 구성을 실행하는 데 드는 예상 비용이 포함된 스프레드시트를 갖게 됩니다. 인프라 평가가 완료되면 계획을 시작할 수 있습니다.
하지만 그럴 수 없습니다. 인프라 인벤토리는 애플리케이션이 실행되는 하드웨어 정보를 제공할 뿐, 해당 애플리케이션이 클라우드에서 실행될 수 있는지 여부, 클라우드 환경에 맞게 변경하는 데 드는 비용, 마이그레이션 시 문제가 발생할 수 있는 종속성, 클라우드 플랫폼에서 지원하지 않는 더 이상 사용되지 않는 API를 사용하는 애플리케이션, 또는 변환 검증 전에 이해해야 할 수십 년 된 문서화되지 않은 비즈니스 로직이 포함된 애플리케이션에 대한 정보는 제공하지 않기 때문입니다. 인프라 검색은 클라우드 마이그레이션 평가를 위한 필수 조건일 뿐, 평가 자체가 아닙니다.
클라우드 마이그레이션 평가란 무엇인가요?
클라우드 마이그레이션 평가는 특정 워크로드 세트를 클라우드로 이전할 수 있는지 여부, 이전 방법 및 비용을 결정하는 체계적인 분석입니다. 이 평가는 다음 세 가지 의사 결정에 필요한 근거를 제공합니다. 각 워크로드에 적용할 마이그레이션 전략, 마이그레이션에 실제로 소요되는 노력과 클라우드 비용, 그리고 워크로드 간 종속성 위험을 관리하기 위한 마이그레이션 순서입니다.
완벽한 클라우드 마이그레이션 평가는 다섯 가지 핵심 영역을 포괄합니다. 인프라 검색 도구는 이 중 한 가지 영역을 다룹니다. 나머지 네 가지 영역에는 각각 다른 도구, 기술, 그리고 전문 지식이 필요합니다.
| 평가 차원 | 이 책은 무엇을 설명할까요? | 기본 도구 |
|---|---|---|
| 인프라 | 현재 어떤 서버, 가상 머신, 서비스가 운영되고 있습니까? 각 항목의 사용률은 어떻게 됩니까? | Azure Migrate, AWS Application Discovery, Google Migration Center |
| 응용 프로그램 코드 | 해당 코드는 클라우드 환경과 호환됩니까? 무엇을 변경해야 합니까? | 출연진 하이라이트, SMART TS XLCloudPilot, GitHub Copilot 앱 현대화 |
| Data | 데이터 용량은 얼마나 되나요? 데이터는 어디에 저장되어 있나요? 마이그레이션의 복잡성과 규정 준수 제약 조건은 무엇인가요? | AWS 데이터베이스 마이그레이션 서비스, Azure 데이터베이스 마이그레이션 서비스, Striim |
| 보안 및 규정 준수 | 적용되는 규제 요건은 무엇인가요? 보안 취약점은 무엇인가요? IAM 및 암호화 관련 변경 사항은 무엇인가요? | AWS Security Hub, Microsoft Defender for Cloud, Prisma Cloud |
| 비용 및 TCO | 이주에 드는 총비용과 이주 후 소유에 드는 총비용은 얼마입니까? | AWS 가격 계산기, Azure 총소유비용 계산기, 인프라 비용, Apptio 클라우드 가능성 |
인프라 관리만 담당하는 조직은 범위가 불분명한 마이그레이션 계획을 수립합니다. 그 결과, 마이그레이션 과정에서 애플리케이션, 데이터, 보안 및 비용 측면에서 예상치 못한 문제에 직면하게 되는데, 이때 문제 해결에 드는 비용이 가장 높습니다.
클라우드 마이그레이션 평가의 5가지 차원
인프라 평가
인프라 평가는 출발점입니다. 이 평가는 소스 환경, 즉 모든 서버, 가상 머신, 컨테이너 및 서비스와 해당 구성, 사용 데이터, 그리고 다른 인프라 구성 요소와의 종속성 연결을 파악합니다.
Azure Migrate 또는 기타 제품과 같은 도구는 워크로드 구성 요소 및 구성을 자동으로 검색합니다. 이러한 도구는 수동 작업을 줄이고 환경 전체에서 일관된 데이터 수집을 제공하지만, 문서화되지 않은 종속성을 놓칠 수 있습니다.
Azure Migrate는 Azure로 마이그레이션하는 조직을 위한 표준 솔루션입니다. VMware vSphere, Hyper-V 및 물리적 서버 환경을 에이전트 없이 검색하여 준비 상태 평가, 성능 기반 적정 규모 권장 사항 및 비용 추정치를 단일 워크로드 이동 전에 제공합니다.
AWS 애플리케이션 마이그레이션 서비스(MGN) 와 AWS 애플리케이션 검색 서비스는 AWS 대상에 대해 동일한 기능을 수행합니다. 검색 서비스는 에이전트 없는 수집 방식 또는 로컬에 설치된 에이전트를 통해 온프레미스 구성 및 성능 데이터를 수집합니다.
Google 마이그레이션 센터는 자산 인벤토리, 종속성 분석 및 총소유비용(TCO) 모델링을 단일 콘솔에 통합하여 Google Cloud 마이그레이션을 위한 통합 검색 및 평가 기능을 제공합니다.
인프라 도구가 제공하는 정보: 서버 인벤토리, 사용률 기준선, 인프라 구성 요소 간 네트워크 종속성 맵, 대상 클라우드 계층에 대한 적정 규모 조정 권장 사항. 하지만 이러한 도구가 제공하지 않는 정보: 해당 서버에서 실행되는 애플리케이션이 클라우드와 호환되는지 여부, 코드 변경 비용, 애플리케이션 내 데이터 마이그레이션 방법.
애플리케이션 코드 평가
애플리케이션 코드 평가는 마이그레이션 성공에 영향을 미칠 수 있는 호환성 문제와 현대화 기회를 파악하는 데 필수적입니다. 이 평가는 애플리케이션이 Azure에서 안정적으로 실행되도록 보장하고 마이그레이션 단계를 효과적으로 계획하는 데 중요합니다. 마이그레이션 실패 위험을 줄이고 목표 아키텍처 결정에 필요한 정보를 얻으려면 애플리케이션 코드 평가를 통해 잠재적 문제점을 조기에 발견해야 합니다.
애플리케이션 코드 평가에서는 인프라 스캔으로는 감지할 수 없는 네 가지 유형의 문제를 발견합니다.
대상 클라우드 환경에 존재하지 않거나 다르게 동작하는 API, 프레임워크 또는 런타임 기능 등 의 호환성 문제가 발생할 수 있습니다. 대상 PaaS 서비스에서 사용할 수 없는 Java EE 애플리케이션 서버를 기반으로 빌드된 Java 애플리케이션은 배포 전에 코드 변경이 필요합니다. Windows 전용 파일 경로 규칙을 사용하는 애플리케이션은 수정 없이 Linux 기반 클라우드 인스턴스에서 실행할 수 없습니다.
클라우드 환경에서는 더 이상 유효하지 않은 하드코딩된 인프라 가정 , IP 주소, 파일 시스템 경로, 서버 이름 또는 포트 번호는 마이그레이션을 방해하는 요소입니다. 이러한 요소들은 인프라 구성이 아닌 애플리케이션 코드 내부에 있기 때문에 인프라 스캔으로는 발견할 수 없습니다.
더 이상 사용되지 않는 API 사용 , 대상 클라우드 환경에서 지원하지 않거나 더 이상 사용되지 않는 API, 라이브러리 또는 플랫폼 기능 호출은 문제가 될 수 있습니다. 클라우드 플랫폼 제공업체는 정기적으로 이전 버전의 API 사용을 중단하며, 이러한 API를 사용하는 애플리케이션은 현재 정상적으로 실행되더라도 새 플랫폼에서는 작동하지 않을 수 있습니다.
의존성 복잡성은 애플리케이션의 내부 구조로, 마이그레이션 난이도와 독립적으로 배포 가능한 서비스로 분할 가능 여부를 결정합니다. 내부 결합도가 높은 모놀리식 애플리케이션은 인프라 인벤토리와 관계없이 결합도가 낮은 애플리케이션보다 마이그레이션이 더 어렵고 비용도 더 많이 듭니다.
CAST Highlight는 자동화된 포트폴리오 수준 애플리케이션 코드 평가를 수행하며, 여러 언어의 소스 코드를 스캔하여 클라우드 준비 상태 점수, 장애 요인 식별 및 오픈 소스 위험 분석을 제공합니다. Microsoft의 Azure 클라우드 도입 프레임워크에서 .NET 및 Java 이외의 워크로드에 권장되는 도구로 언급되어 있습니다.
CloudPilot은 JavaScript, Python, Node.js 및 Go를 아우르는 상세한 클라우드 준비 상태 평가, 호환성 점수 부여 및 마이그레이션 로드맵 생성 서비스를 전문으로 제공합니다.
GitHub Copilot 앱 현대화는 CAST의 AppCAT 평가 기능과 AI 기반 코드 수정 기능을 결합하여 .NET 및 Java 워크로드에 특화되어 있습니다.
COBOL, JCL, PL/I, RPG 및 기타 메인프레임 언어와 최신 기술 스택을 아우르는 엔터프라이즈 환경에서는 이러한 도구로는 충분하지 않습니다. 레거시 시스템의 애플리케이션 코드 평가는 완전히 다른 범주의 도구가 필요합니다.
데이터 평가
데이터 평가는 대상 데이터 저장소 각각의 복잡성, 용량, 규정 준수 요구 사항 및 마이그레이션 방법을 결정합니다. 데이터베이스와 데이터를 옮기면 되는 것처럼 간단해 보이기 때문에 실제 복잡성이 드러나기 전까지는 그 중요성을 간과하기 쉽습니다.
데이터 평가가 반드시 답해야 할 핵심 질문:
용량 및 처리량 : 데이터 양은 얼마나 됩니까? 데이터 변경 속도는 어떻습니까? 다운타임 없이 마이그레이션이 가능합니까, 아니면 거의 다운타임 없이 전환하려면 지속적인 복제를 사용해야 합니까?
스키마 호환성 : 대상 데이터베이스 서비스가 소스와 동일한 스키마 기능, 데이터 유형 및 저장 프로시저를 지원하는지 확인하십시오. Oracle 고유의 PL/SQL 구문은 PostgreSQL 또는 클라우드 네이티브 대안으로 마이그레이션하기 전에 변환해야 합니다.
데이터 주권 및 규정 준수 : 데이터는 법적으로 어디에 저장되어야 합니까? GDPR, HIPAA, PCI-DSS 및 특정 산업 분야 규정은 특정 데이터 범주를 호스팅할 수 있는 클라우드 지역을 제한할 수 있습니다.
애플리케이션 결합도 : 애플리케이션 코드가 특정 데이터베이스 스키마에 얼마나 밀접하게 결합되어 있습니까? 기술적으로는 간단해 보이는 스키마 변경이라도 이를 수용하기 위해 애플리케이션 코드에 광범위한 변경이 필요할 수 있습니다.
AWS Database Migration Service 와 Azure Database Migration Service는 동종 마이그레이션(Oracle에서 Oracle, SQL Server에서 SQL Server)의 경우 다운타임을 최소화하면서 지속적인 복제를 지원하고, 이기종 마이그레이션(Oracle에서 PostgreSQL, SQL Server에서 Aurora)의 경우 스키마 변환을 지원합니다.
Striim 과 Attunity는 데이터베이스 다운타임이 허용되지 않는 고가용성 마이그레이션 시나리오를 위해 실시간 데이터 스트리밍 및 복제 기능을 제공합니다.
보안 및 규정 준수 평가
보안 평가는 각 워크로드의 현재 보안 상태를 파악하고 클라우드 보안 표준, 규정 준수 프레임워크 및 제로 트러스트 아키텍처 원칙을 충족하는 데 필요한 변경 사항을 식별합니다.
보안 평가에서 다뤄야 할 영역은 다음과 같습니다.
ID 및 액세스 관리(IAM) : 온프레미스 애플리케이션은 종종 광범위한 권한과 암호 기반 인증을 가진 서비스 계정을 사용합니다. 클라우드 환경에서는 역할 기반 액세스 제어, 최소 권한 서비스 ID, 인증서 또는 토큰 기반 인증이 필요합니다. 현재 IAM과 필요한 IAM 간의 격차는 인프라 인벤토리와는 무관한 마이그레이션 작업에서 발생합니다.
암호화 : 저장 데이터와 전송 데이터 암호화 요구 사항은 온프레미스 환경과 클라우드 환경에서 서로 다릅니다. 애플리케이션 계층에서 자체 암호화를 관리하는 애플리케이션은 클라우드 키 관리 서비스와 통합해야 합니다. 사설 네트워크에서 사용 가능한 암호화되지 않은 데이터 저장소는 클라우드 호스팅 서비스로 이전하기 전에 암호화해야 합니다.
네트워크 보안 : 온프레미스 네트워크 하드웨어에 구현되었던 방화벽 규칙, 네트워크 분할 및 트래픽 검사는 클라우드 보안 그룹, 가상 네트워크 구성 및 클라우드 네이티브 방화벽 규칙으로 재구성해야 합니다.
규정 준수 프레임워크 정렬 : 각 규제 산업은 특정 클라우드 구성에 맞춰야 하는 특정 규정 준수 요구 사항을 가지고 있습니다. HIPAA 워크로드는 스토리지, 액세스 로깅 및 암호화 전반에 걸쳐 특정 구성 선택을 요구합니다. PCI-DSS는 네트워크 분할을 요구하는데, 이는 물리적 네트워크 인프라와는 다르게 클라우드 VPC에서 구현해야 합니다.
Microsoft Defender for Cloud는 Azure 워크로드에 대해 CIS 벤치마크, NIST, PCI-DSS 및 기타 프레임워크에 대한 보안 상태 평가 및 규정 준수 평가를 제공합니다.
Prisma Cloud (Palo Alto Networks)와 AWS Security Hub는 동등한 수준의 멀티 클라우드 보안 평가 및 규정 준수 모니터링 기능을 제공합니다.
비용 및 총소유비용 평가
비용 평가는 비즈니스 이해관계자에게 가장 눈에 띄는 마이그레이션 결과물이지만, 동시에 가장 자주 잘못 작성되는 부분이기도 합니다. 가장 흔한 오류는 현재 온프레미스 하드웨어 비용과 클라우드 컴퓨팅 및 스토리지 비용을 비교하는 것인데, 이는 불완전하고 오해의 소지가 있는 비교로 이어집니다.
종합적인 TCO 평가에는 다음 사항이 포함됩니다.
클라우드 인프라 비용 : 대상 클라우드 구성에서의 컴퓨팅, 스토리지, 네트워킹 및 관리형 서비스 비용. 실제 사용량 데이터(프로비저닝된 용량이 아닌)를 기반으로 한 적정 규모 산정은 정확한 추정치와 과장된 추정치의 차이를 나타냅니다.
마이그레이션 작업 비용 : 애플리케이션 코드 변경, 데이터 마이그레이션, 보안 재구성 및 테스트를 완료하는 데 필요한 엔지니어링 시간입니다. 인프라만 평가하는 방식은 애플리케이션의 복잡성을 파악하지 못하기 때문에 이 비용을 체계적으로 과소평가하는 경향이 있습니다.
라이선스 변경 : 영구 온프레미스 라이선스에서 클라우드 기반 라이선스 모델로 전환하거나, 특정 공급업체 소프트웨어에서 클라우드 네이티브 대안으로 전환하면 라이선스 비용 구조가 근본적으로 바뀝니다.
운영 모델 변경 : 물리적 하드웨어를 관리하던 온프레미스 운영팀이 클라우드 서비스를 관리하던 클라우드 운영팀으로 대체됩니다. 필요한 기술, 도구 및 인력 규모가 변화합니다.
교육 및 전환 비용 : 새로운 클라우드 플랫폼, 새로운 배포 모델 및 새로운 운영 절차를 학습하는 팀은 전환 과정에서 생산성 저하 비용을 부담합니다.
AWS 가격 계산기 , Azure TCO 계산기 , Google Cloud 가격 계산기는 클라우드 인프라 비용 측면을 다룹니다. Infracost는 IaC 파이프라인에 통합된 비용 추정 기능을 제공하여 CI/CD 프로세스의 일부로 비용을 산출합니다. Apptio Cloudability 및 유사한 FinOps 도구는 마이그레이션 후 지속적인 비용 가시성을 제공합니다.
7가지 이주 전략: 평가를 통해 어떤 전략이 적용되는지 결정하는 방법
"7R" 프레임워크는 각 워크로드 마이그레이션에 사용할 수 있는 전략을 설명합니다. 평가를 통해 어떤 전략이 적절한지 결정하는데, 평가가 잘못되면 잘못된 전략을 적용하게 되고, 이것이 대부분의 마이그레이션 비용 초과의 근본 원인입니다.
| 전략 | 의미 | 평가 신호가 그것을 암시합니다 |
|---|---|---|
| 리호스팅 (리프트 앤 시프트) | 코드 변경 없이 클라우드로 마이그레이션하세요 | 낮은 애플리케이션 복잡성, 호환성 문제 없음, 인프라 호환성 |
| 리플랫폼 | 클라우드 서비스를 활용하기 위한 약간의 변경 사항 (예: 관리형 데이터베이스로 전환) | 적당한 결합도, 특정 플랫폼 업그레이드 기회, 허용 가능한 코드 변경 범위 |
| 리팩터링 | 클라우드 네이티브 패턴(마이크로서비스, 컨테이너)에 맞춰 아키텍처를 재설계합니다. | 높은 모놀리식 결합도, 상당한 확장성 요구 사항, 예상되는 트래픽 증가로 인한 타당성 |
| 재설계자 | 애플리케이션 아키텍처의 대대적인 재설계 | 기존 애플리케이션은 클라우드 환경과 근본적으로 호환되지 않습니다. 새로운 아키텍처는 주요 비즈니스 이점을 제공합니다. |
| 재 구축 | 처음부터 다시 작성하세요 | 해당 설비는 경제적으로 수리가 불가능하며, 교체하는 것이 수리하는 것보다 저렴합니다. |
| 교체 | 맞춤형 애플리케이션을 폐기하고 SaaS 대안을 도입하세요. | 이 애플리케이션은 기존 클라우드 서비스에서 더 잘 제공될 수 있는 일반적인 기능을 제공합니다. |
| 은퇴 | 해당 애플리케이션은 더 이상 필요하지 않으므로 서비스 종료합니다. | 평가 과정에서 해당 애플리케이션이 더 이상 사용되지 않거나, 불필요하거나, 대체된 것으로 확인되었습니다. |
인프라 인벤토리는 리호스팅, 리플랫폼, 리팩토링, 리빌드 대상을 구분할 수 없습니다. 인프라 계층에서는 모두 동일하게 보이기 때문입니다. 이러한 구분은 애플리케이션 코드 분석을 통해 이루어집니다.
레거시 및 메인프레임 시스템의 클라우드 마이그레이션 평가
표준 클라우드 마이그레이션 평가 도구는 가상 머신, 컨테이너, 마이크로서비스 및 클라우드 네이티브 애플리케이션과 같은 최신 인프라에 맞춰 설계되었습니다. 따라서 메인프레임 워크로드, IBM z/OS에서 실행되는 COBOL 프로그램, 배치 처리를 관리하는 JCL 작업 스트림, 금융 거래를 처리하는 PL/I 애플리케이션, AS/400 시스템에 내장된 RPG 프로그램 등에서는 성능이 저조하거나 전혀 작동하지 않습니다.
메인프레임 클라우드 마이그레이션 평가에는 근본적으로 다른 접근 방식이 필요합니다. 인프라 계층이 제약 조건이 아니기 때문입니다. 제약 조건은 애플리케이션 코드, 수십 년간 축적된 비즈니스 로직, 공유 데이터 세트 및 카피북을 통한 암묵적인 종속성, 그리고 인프라 스캔으로는 드러낼 수 없는 런타임 동작입니다.
메인프레임 마이그레이션을 책임감 있게 계획하기 전에 필요한 8가지 분석, 즉 프로그램 목록 작성, 종속성 매핑, 비즈니스 로직 추출, 사용되지 않는 코드 식별, 복잡성 분류, 배치 스케줄링 분석, 데이터 품질 평가 및 통합 매핑은 메인 프레임 마이그레이션 위험 완화 라는 맥락에서 자세히 설명됩니다 . 이러한 각 분석은 인프라 평가 활동이 아닌 코드 수준 평가 활동입니다.
클라우드 마이그레이션 평가 도구 비교
아래 표는 주요 클라우드 마이그레이션 평가 도구를 각 도구가 다루는 평가 영역 및 가장 적합한 시나리오와 연결한 것입니다.
| 수단 | 평가 레이어 | 클라우드 대상 | 지원 기기 |
|---|---|---|---|
| Azure 마이그레이션 | 인프라 | 하늘빛 | VM 및 서버 검색, 적정 규모 조정, Azure 비용 예측 |
| AWS 애플리케이션 검색 서비스 | 인프라 | AWS | AWS 마이그레이션을 위한 온프레미스 서버 검색 |
| 구글 마이그레이션 센터 | 인프라 | GCP | GCP 마이그레이션을 위한 자산 목록 및 총소유비용(TCO) |
| 캐스트 하이라이트 | 응용 프로그램 코드 | 다중 클라우드 | 다양한 언어에 걸친 포트폴리오 규모의 코드 준비도 평가 |
| 클라우드파일럿 | 응용 프로그램 코드 | 다중 클라우드 | Python, JS, Node.js, Go와의 상세 호환성 분석 |
| SMART TS XL | 애플리케이션 코드 + 종속성 매핑 | 다중 클라우드 | COBOL, JCL, 메인프레임 및 다국어 포트폴리오 분석 |
| AWS DMS | Data | AWS | 스키마 변환을 포함한 데이터베이스 마이그레이션 |
| Azure 데이터베이스 마이그레이션 서비스 | Data | 하늘빛 | SQL Server, MySQL, PostgreSQL을 Azure로 마이그레이션 |
| 스트리임 | Data | 다중 클라우드 | 데이터 마이그레이션 시 다운타임이 발생하지 않도록 실시간 복제 기능을 제공합니다. |
| 클라우드용 Microsoft Defender | 보안 | Azure / 멀티클라우드 | 보안 상태 및 규정 준수 평가 |
| 프리즈 마 클라우드 | 보안 | 다중 클라우드 | AWS, Azure, GCP 전반에 걸친 CSPM 및 규정 준수 |
| 인프라 비용 | 비용 | 다중 클라우드 | CI/CD 파이프라인에서 IaC 통합 비용 추정 |
| 앱티오 클라우드 가능성 | 비용 | 다중 클라우드 | FinOps 및 지속적인 클라우드 비용 관리 |
| 코렌트 SurPaaS | 인프라 + 애플리케이션 | 다중 클라우드 | AI 기반 탐색, 평가 및 마이그레이션 오케스트레이션 |
방법 SMART TS XL 클라우드 마이그레이션을 위한 애플리케이션 코드 평가를 수행합니다.
SMART TS XL 이 솔루션은 인프라 도구가 접근할 수 없는 애플리케이션 코드 평가 계층, 특히 애플리케이션 포트폴리오가 여러 언어, 플랫폼 및 기술 세대에 걸쳐 있는 엔터프라이즈 및 레거시 환경에 대한 문제를 해결합니다.
COBOL 프로그램, JCL 작업 스트림, Java 서비스, Python 파이프라인 및 SQL 스키마를 포함하는 마이그레이션 프로그램의 경우, SMART TS XL 마이그레이션 팀이 어떤 것을 재호스팅하고, 어떤 것을 리팩토링하고, 어떤 것을 폐기할지 결정하기 전에, 이 모든 것에 걸쳐 통합된 종속성 모델을 동시에 구축합니다. SMART TS XL 제공 :
완전한 프로그램 목록 : 환경 내 모든 언어의 모든 소스 프로그램, 카피북, 프로시저 및 스키마를 포함하는 실제 목록이며, 문서화된 목록이 아닙니다. 레거시 환경에서는 문서화된 목록과 실제 목록의 차이가 20~30%에 달하는 경우가 흔합니다.
언어 간 종속성 매핑 : 애플리케이션 종속성 매핑 기능은 COBOL 프로그램이 DB2 스키마에 연결되는 방식, Java 서비스가 쿼리하는 스키마, 그리고 이 쿼리 결과를 Python 파이프라인에 전달하여 최신 React 프런트엔드에서 소비되는 출력을 생성하는 방식을 추적합니다. 이러한 언어 간 종속성 체인은 마이그레이션 순서를 결정하며, 종속 요소가 많은 구성 요소는 해당 종속 요소의 마이그레이션이 완료된 후에 마이그레이션되어야 합니다.
사용되지 않는 코드 식별 : 어떤 운영 실행 경로에서도 호출되지 않는 프로그램과 프로시저는 마이그레이션 범위에서 완전히 제외할 수 있습니다. 대규모 레거시 환경에서 이는 일반적으로 전체 코드의 10~25%를 차지하며, 평가 단계에서 상당한 비용 절감을 가져올 수 있습니다.
복잡도 분류 : 정적 코드 분석 기능은 순환 복잡도, 카피북 의존성 개수, 호출 횟수 및 마이그레이션 난이도를 결정하는 기타 지표를 기준으로 각 프로그램을 분류합니다. 호출자가 많고 복잡도가 높은 프로그램은 리팩토링 또는 재구축 대상이 됩니다. 복잡도가 낮고 의존성이 적은 프로그램은 재호스팅 대상이 됩니다.
변경 전 영향 분석 : 영향 분석 기능은 마이그레이션 작업이 시작되기 전에 "이 프로그램이 변경되면 어떤 영향을 받을까요?"라는 질문에 대한 답을 제공하여 알려지지 않은 위험을 구조화되고 열거된 범위로 변환합니다.
메인프레임에서 클라우드로의 마이그레이션 프로그램을 계획하는 조직의 경우, SMART TS XL의 레거시 현대화 이 분석은 마이그레이션 업체가 변환 작업 시작 전에 요구하는 사전 마이그레이션 평가 자료를 생성합니다. 여기에는 완전한 구조적 목록, 종속성 그래프, 복잡성 분류 및 사용되지 않는 코드 제외 보고서가 포함됩니다.
완벽한 클라우드 마이그레이션 평가에서 도출해야 할 결과
평가의 가치는 그 평가를 통해 도출되는 의사결정의 가치에 달려 있습니다. 완벽한 클라우드 마이그레이션 평가는 마이그레이션 프로그램을 정의하는 데 필요한 다섯 가지 결과물을 도출해야 합니다.
마이그레이션 전략이 포함된 애플리케이션 포트폴리오 목록 : 범위 내 모든 애플리케이션을 Rehost, Replatform, Refactor, Rearachitect, Rebuild, Replace 또는 Retire로 분류하고, 각 분류를 뒷받침하는 평가 근거를 제시합니다.
의존성 기반 마이그레이션 단계 계획 : 애플리케이션 마이그레이션 순서는 임의 그룹화가 아닌 의존성 그래프를 기반으로 결정됩니다. 대상 애플리케이션 중 다른 애플리케이션으로부터 인바운드 의존성이 없는 애플리케이션은 초기 단계에서 마이그레이션할 수 있습니다. 다른 많은 애플리케이션에 의존하는 애플리케이션은 해당 의존 애플리케이션의 마이그레이션이 완료된 후 후기 단계에서 마이그레이션됩니다.
마이그레이션 총비용 추정치 : 인프라 비용 차이뿐 아니라 엔지니어링 노력, 마이그레이션 도구 비용, 임시 병렬 운영 비용 및 교육 비용을 모두 포함합니다.
마이그레이션 후 총소유비용(TCO) 모델 : 적정 규모의 구성과 실제 사용량 데이터를 기반으로 예측한 클라우드 지출액을 현재 온프레미스 운영 비용과 비교하고, 라이선스 변경 및 운영 모델 전환에 대한 현실적인 가정을 반영합니다.
위험 등록부 : 식별된 위험, 호환성 문제, 복잡한 데이터 마이그레이션, 문서화되지 않은 종속성, 규정 준수 제약 조건과 각 위험의 발생 확률, 영향, 그리고 제안된 완화 방안을 포함합니다.
마이그레이션을 시작하기 전에 이 다섯 가지 결과물을 모두 제공하는 조직은 프로그램 성공에 필요한 정보를 확보하게 됩니다. 반면 애플리케이션 코드 평가, 데이터 평가 또는 보안 평가를 생략하는 조직은 이러한 결과물을 불완전하게 제공하고, 마이그레이션 중에 누락된 부분을 발견하게 되는데, 이때 발견되는 모든 문제점을 해결하는 데 더 많은 비용이 소요됩니다.
