페이퍼요약 - 데이터 마이그레이션 프로젝트에서 테스팅과 품질 보증 by Matthes

제목: 데이터 마이그레이션 프로젝트에서 테스팅과 품질 보증(Testing & Quality Assurance in Data Migration Projects)

저자: Florian Matthes 외 2인, 독일

문서유형: 컨퍼런스 페이퍼(총 10 페이지), 2011년

 

저자의 경험(관계형 DB, 하나의 소스에서 기존 데이터가 없는 하나의 타겟으로 마이그레이션)을 바탕으로 데이터 마이그레이션 프로젝트의 프로세스 모델과 리스크를 기술한 자료

---

데이터 마이그레이션

• 정형화된 데이터를 소스 구조로부터 타겟 데이터 구조로 이전하는 것이 목표인 도구 지원의 일회성 프로세스(개념적/기술적 레벨에서 양쪽의 구조가 다름)
• 아래와 같은 여러 이유로 데이터 마이그레이션이 요구됨
  – M&A, 다운사이징 같은 기업 이벤트로 인한 전사 차원의 데이터 통합 노력
  – 신규 사업 모델과 프로세스 구현을 위해 이를 지원하지 않는 기존 애플리케이션 교체(이런 교체에 데이터의 마이그레션도 포함됨)
  – 기술적 진화와 업그레이드(예, 더 일반적인 플랫폼이나 구외 데이터 스토리지로 이전)
  – 새로운 법령이나 규제 요구사항을 지원하는 최신 비지니스 애플리케이션 도입(기존 애플리케이션을 해제하는 일에 데이터의 마이그레이션도 포함됨)
• 일회성 이벤트의 성격, 규모 및 복잡도의 과소평가 등으로 인해 데이터 마이그레이션에 대한 축적된 노하우와 경험이 부족(충실하게 문서화가 된 경우도 희박). 연구 그룹 Bloor의 보고서에 따르면 프로젝트에서 데이터 마이그레이션 부분의 성공률(즉, 제 시간에 예산 내에서 완성)이 16%에 그침

데이터 마이그레이션 프로젝트의 주요 구성 요소

• 모든 데이터 마이그레이션 프로젝트는 데이터를 처리/변경하는 마이그레이션 프로그램, 스크립트, 변환 규칙(transformation rules)을 구현함
• 이 프로그램들은 산업 분야, 회사, 프로젝트 마다 각기 다르지만 근본적으로 유사한 데이터 마이그레이션 아키텍쳐를 따르고 있음(아래 그림). 즉, 마이그레이션 프로그램의 일반적인 구조, 지휘 컴포넌트(orchestration component)의 개념, 3개의 데이터 마이그레이션 데이터베이스 활용 등이 공통적임

[데이터 마이그레이션 아키텍쳐]

1) 데이터 마이그레이션 데이터베이스

• 소스 스테이징 데이터베이스(Source staging database): 소스 애플리케이션 데이터베이스의 복사본을 저장. 데이터 마이그레이션 프로젝트가 여전히 사용중인 소스 애플리케이션 데이터베이스를 훼손하거나 느리게 만드는 것을 방지함
• 변환 데이터베이스(Transformation database): 대량의 데이터를 합치고, 비교하고, 총괄하고, 걸러내고, 변환하는 데이터 마이그레이션 프로그램의 중간 결과를 저장. 이 데이터베이스는 대규모 데이터 셋을 효과적으로 처리할 수 있도록 최적화됨(예, 언제 오퍼레이션을 메인 메모리에서 실행하고 언제 데이터를 디스크로 쓰는지 등)
• 타겟 스테이징 데이터베이스(Target staging database): 타겟 애플리케이션으로 업로드 준비가 된 변환 결과를 저장. 업로드 API가 존재하는지 아니면 데이터가 데이터베이스 테이블로 직접 복사되어야 하는지는 타겟 애플리케이션에 따라 다름. 후자의 경우 업로드 스테이징 데이터베이스 구조의 테이블이 타겟 애플리케이션 데이터베이스의 테이블과 동등해야 함. 업로드 API가 존재하는 경우 타겟 스테이징 영역의 테이블이 마이그레이션 API를 호출하기 위한 호출 패러미터(invocation parameters)를 담고 있음

 

위 데이터베이스들은 논리적 인스턴스임. 즉, 하나의 물리적인 데이터베이스 인스턴스가 세 개의 다른 스키마를 사용하여 이 3개의 논리적 데이터베이스 모두를 저장할 수 있음

2) 데이터 마이그레이션 프로그램

• 데이터와 그 표현(representation)을 필요에 따라 변환하여 데이터를 소스 애플리케이션 데이터베이스로부터 타겟 애플리케이션 데이터베이스로 이동하는 프로그램을 의미
• 데이터 마이그레이션 프로그램은 하나의 비즈니스 오브젝트 타입을 이전하는데 필요한 아래와 같은 3개 유형의 프로그램을 함축하는 용어
  – 추출/사전필터 프로그램(Extract & pre-filter program): 소스 애플리케이션 데이터베이스로부터 관련 데이터를 복사. 사전필터는 데이터를 줄이기 위한 목적이지만 어떤 데이터가 타겟 애플리케이션 데이터베이스로 복사되어야 하는지를 결정하지는 않음(예, 사전필터 단계에서 수십 년 전에 폐쇄된 계정을 제외시키기는 해도 특정 내부 계정을 걸러내거나 하지는 않음). 소스에 원래 저장되지 않았지만 타겟 애플리케이션에서 요구되는 데이터를 더하여 데이터를 더 풍부하게 만드는 작업이 이 단계에서 수행되거나 또는 다음 단계의 변환 프로그램에 의해 수행될 수 있음
  – 변환 프로그램(Transformation program): 소스 구조와 타겟 구조 간의 모든 데이터 매핑을 수행(예, 저축 계좌의 계정 타입 ID가 소스 애플리케이션에서는 4553이고 타겟에서는 85571임). 또한 타겟 애플리케이션이 어떤 데이터를 필요로 하는지 결정하는 상세 레벨의 필터링을 수행
  – 업로드 프로그램(Upload program): 데이터를 타겟 애플리케이션 데이터베이스로 로드함. 업로드 프로그램은 타겟 애플리케이션 API가 제공되는 경우 이를 이용하거나 또는 데이터를 직접 타겟 데이터베이스의 테이블에 쓴다(write).
• 모든 데이터 마이그레이션 프로그램을 정확한 순서로 실행시키는 것이 쉽지 않음. 지휘 컴포넌트(orchestration component)는 시간표(timetable)와 유사한 메커니즘을 사용하여 프로그램들의 정확한 시작 순서를 보장함

데이터 마이그레이션 프로세스 모델

데이터 마이그레이션 프로세스가 아래 그림처럼 4개의 주요 단계와 14개의 세부 단계로 구성됨

[데이터 마이그레이션 프로세스 모델]

A. 초기화(Initialization)

프로젝트 조직(organization)과 기술적 인프라구조를 정립하는 단계

 

1. 입찰 요청(Call for tender and bidding)

• 누가(내부 IT 부서, 외부 전문 업체) 데이터 마이그레이션 프로젝트를 수행할지 결정
• 주 산출물인 입찰서(bidding report)는 프로젝트 범위, 영향을 받는 비즈니스 애플리케이션과 이해관계자, 필수 리소스, 프로젝트 계획, 예상 리스크 등을 포함해야 함

2. 전략과 사전분석(Strategy and pre-analysis)

• 프로젝트 범위와 마이그레이션 로드맵을 구체화함. 빅뱅 vs. 점진적 마이그레션 같은 기본적인 마이그레이션 전략을 결정하고, 로드맵에서는 소스 애플리케이션에 있는 과거 데이터(historic data)를 어떻게 처리할지 등이 다루어져야 함
• 직면할 어려움(예, 큰 데이터 볼륨, 데이터를 이미 포함하고 있는 타겟 데이터베이스, 분산된 프로젝트 팀 같은 조직적인 어려움, 나쁜 데이터 품질)을 고민하고 의사결정을 함
• 주어진 시간과 예산에 따라 소규모 테스트 데이터 셋을 준비하여 검증 목적으로 마이그레이션을 해 볼 수 있음(고객 설득과 프로젝트 사기 증진에 도움)

3. 플랫폼 셋업(Platform set-up)

• 기술적인 개발 및 실행 인프라구조를 셋업함
• 데이터 마이그레이션 프로젝트의 핵심이 데이터를 소스 애플리케이션 데이터 구조로부터 새로운 구조로 영구 이동시키기 위한 변환 프로그램 개발에 있음. 따라서 중간 저장을 위한 데이터베이스(소스와 타겟 스테이징 영역)가 셋업되어야 하고, 마이그레이션 프로그램을 위한 저장소(repository)도 준비되어야 하며, 특수한 데이터 마이그레이션 도구도 설치되어야 함

B. 개발(Development)

실제 데이터 마이그레이션 프로그램 구현을 위한 모든 관련 측면을 커버하는 단계

 

4. 데이터 언로딩(Data unloading)

• 프로젝트 팀이 추출/사전필터 프로그램을 개발하고 이를 이용하여 모든 관련 데이터의 최신 스냅샷을 준비함. 즉, 소스 비즈니스 애플리케이션 데이터베이스로부터의 관련 데이터가 소스 스테이징 영역으로 복사됨

5. 소스와 타겟의 구조 및 데이터 분석(Structure and data analysis for source and target)

• 다양한 비즈니스 오브젝트 타입을 위한 변환 프로그램을 구현하기 전에(그리고 구현 중에) 소스 데이터베이스와 타겟 데이터베이스의 데이터 및 구조에 대하여 최대한 많이 습득하는 것이 중요함
• 산출물인 데이터 분석 보고서(data analysis report)는 마이그레이션 관련 소스 데이터의 품질과 애트리뷰트 레벨에서의 구조에 대하여 상세히 기술함. 이 문서는 또한 선택 작업인 데이터 클리닝의 추정 비용, 필수 리소스, 액션 항목(action items)을 기술함
• 소스와 마찬가지로 타겟 데이터 구조도 상응하는 스테이징 영역으로 매핑되어야 함(해당 구조의 철저한 검사를 허용하기 위한 목적)
• 전반적인 마이그레이션 프로세스의 속도를 높이기 위해 소스와 타겟의 분석을 병행하여 수행하는 것이 가능함

5.1a 소스 데이터 클린징(Source data cleansing)

• 손상되고 난해한 데이터를 수정하여 데이터 품질을 개선함
• 대개는 클린징이 소스 데이터베이스나 타겟 데이터베이스에서 일어나지만 언로딩과 변환 활동의 일부가 될 수도 있음. 후자의 단점은 데이터 마이그레이션 프로그램에 추가적인 클린징 로직이 더해짐에 따라 코드 루틴의 복잡도가 증가하는 점

6. 데이터 변환(Data transformation)

• 점진적이고 반복적인 마이그레이션 방법에 따라 변환 단계가 여러 번 반복됨(즉, 이전의 데이터 언로딩과 분석 단계로 되돌아가 반복). 각 반복을 통해 데이터 변환 프로그램(데이터를 소스로부터 타겟 데이터 구조로 이전하기 위한 규칙과 로직을 포함)이 점진적으로 확장되고 지속적으로 개선됨
• 이 단계의 궁극적인 목표는 모든 관련 데이터를 소스 스테이징 영역으로부터 타겟 스테이징 영역으로 완전하고 정확하게 이전하는 것이며, 이를 위해 비즈니스적 변환 개념과 기술적 변환 규칙이 활용됨. 소스에서 타겟 데이터베이스로 기본키(primary keys)와 외래키(foreign keys)를 매핑하는 작업이 상당히 복잡해질 수도 있음
• 여러 이유로 변환 규칙이 마이그레이션 관련 데이터 전부를 커버하지는 못하며, 이런 특이 값(outliers)들은 수작업 입력, 마이그레이션 포기, 또는 클린징 등을 통해 처리됨

C. 테스팅(Testing)

• 데이터와 데이터 마이그레이션 프로그램의 정확성, 안정성, 실행 시간을 확인하는 단계
• 소프트웨어 공학에서 테스팅 순서는 단순한 것부터 시작하여 더 복잡한 것으로 이동하는데 동일한 원칙이 데이터 마이그레이션 프로젝트의 테스팅에도 적용됨
• 데이터 마이그레이션 프로젝트의 테스팅 기법은 아래 그림과 같은 카테고리로 구분됨

7. 마이그레이션 런 테스트(Migration run test)

• 데이터 마이그레이션 프로그램(추출/사전필터, 필터링과 변환, 타겟 애플리케이션으로의 로드)이 잘 작동하고 원활하게 협업함을 보장함. 마이그레이션 프로그램의 실행에서 일부 프로그램이 호출되지 않거나, 충돌하거나, 잘못된 순서로 실행되면 이 에러로 인해 데이터가 훼손될 수 있음
• 마이그레이션 런 테스트는 아래의 2개 서브클래스로 구분됨
  – 전체 마이그레이션 런 테스트(Full migration run tests): 전체 데이터 셋을 가지고 모든 마이그레이션 프로그램을 실행. 이 테스트는 전체 데이터 마이그레이션의 실행 시간 측정을 허용(인프라구조가 바뀌지 않는 한 최종 cut-over의 실행 시간과 동일). 이 실행 시간은 업무를 중단시키는 애플리케이션 다운시간에 직접적인 영향을 줌. 예를 들어, 2시간이 걸리는 데이터 마이그레이션은 밤사이 수행될 수 있지만 24시간의 마이그레이션은 주말/연휴 기간이 필요함. 마이그레이션 시간을 개선하기 위해 데이터 마이그레이션 프로그램의 코드를 다시 손 보는 경우도 생김
  – 부분적 마이그레이션 런 테스트(Partial migration run tests): 적은 수의 비즈니스 오브젝트를 마이그레이션 하여 시험 마이그레이션(trial migration) 속도를 향상시킴. 이는 마이그레이션 개발 사이클의 순환 시간(round-time)이 빨라지게 함. 부정적 측면은 마이그레이션 된 데이터에 불일치가 존재하거나(예, 단지 1%의 고객 계정만이 마이그레이션 된 경우 이 고객 계정의 결산표와 내부 계정의 결산표가 불일치) 또는 희귀한 데이터 조합이 누락되거나 할 가능성이 높음
• 마이그레이션 런 테스트의 산출물은 모든 에러 메시지와 충돌(crashes)을 기록한 로그이며, 전체 마이그레이션 런 테스트의 경우는 여기에 실행 시간이 추가됨

8. 외양 테스트(Appearance tests)

• GUI(Graphical User Interface) 레벨의 오브젝트 외양에 중점. 테스터(비즈니스 도메인 전문가)가 소스와 타겟 애플리케이션의 GUI 상의 데이터를 살펴봄으로써 수작업으로 오브젝트를 비교함(예, 계정 잔액의 숫자나 통화 단위가 동일한지 비교). 또한 타겟 애플리케이션에 친숙하지 않은 데이터가 있는지도 확인
• 외양 테스트 계획 시에는 어떤 비즈니스 오브젝트와 데이터가 제일 중요한지 가장 잘 알고 있는 비즈니스 도메인 전문가가 테스팅을 위한 비즈니스 오브젝트의 구체적인 샘플 집합을 식별함. 이는 제한된 수의 비즈니스 오브젝트만 비교하면서도 높은 커버리지를 달성할 수 있게 함
• 산출물은 테스트 셋의 각 비즈니스 오브젝트가 정확하게 마이그레이션 되었는지 여부를 기술한 문서

9. 완전성 및 타입 일치 테스트(Completeness & type correspondence tests)

• 타겟 데이터베이스에서 소실된 비즈니스 오브젝트(소스에 존재하는 오브젝트가 제대로 마이그레이션이 안되었거나 또는 소스 애플리케이션에는 존재하지 않았지만 타겟에 존재해야 하는 새로운 오브젝트)를 식별하려는 노력
• 대개 수천 개의 비즈니스 오브젝트를 조사할 필요가 있어서 소스와 타겟 데이터베이스의 비즈니스 오브젝트 비교를 자동화하는 것이 요구됨. 예, 완전성을 체크하기 위해 스크립트가 자동으로 소스와 타겟의 기본키(식별자)를 매핑
• 이것이 모든 데이터를 커버하는 유일한 테스트이므로 비즈니스 오브젝트 타입이 변동 없이 그대로인지를 확인하는 것이 중요함
• 산출물은 타겟 애플리케이션에서 분실된 모든 비즈니스 오브젝트 목록과 타겟 애플리케이션에 있어서는 안되지만 실제 존재하는 모든 비즈니스 오브젝트 목록

10. 가공성 테스트(Processability test)

• ‘가짜 로드(mock-load)’라고도 불리며 타겟 비즈니스 애플리케이션과 새롭게 유입된(imported) 데이터 간의 조화롭고 성공적인 상호작용을 보장하는 테스트
• 외양 테스트가 소스와 타겟 애플리케이션 GUI에서 오브젝트를 조사하는 반면(즉, 시각적 비교) 이 테스트는 마이그레이션된 데이터를 실제 프로세싱하여 마이그레이션된 데이터와 타겟 애플리케이션 패러미터 간의 불일치성이나 비양립성을 식별함
• 예를 들면, 데이터베이스 테이블에 직접 데이터를 써서 마이그레이션이 이루어졌고 데이터베이스 스키마가 통화(currency) 설정에 대한 제제를 가하지 않은 경우 GUI에서 마이그레이션된 오브젝트를 체킹할 때는 모든 것이 완벽해 보이지만 실제 이 데이터를 프로세싱하면 애플리케이션이 충돌함. 이런 에러들은 비즈니스 프로세스로부터 도출된 구체적인 테스트 케이스를 타겟 애플리케이션에서 실행할 때만 발견됨
• 수작업 테스팅 뿐만 아니라 애플리케이션에 특정적인 배치 프로세스도 준비되고 실행되어야 함. 예, 코어 뱅킹 시스템의 경우 일일/년말 프로세싱이나 중요 비즈니스 이벤트(개시잔고, 결산, 보험률 계산)를 위한 호스트 잡(host jobs)

11. 통합 테스트(Integration tests)

• 대부분의 회사에서 비즈니스 프로세스가 하나의 단일 애플리케이션에 의해 지원되기보다는 여러 애플리케이션에 걸쳐 있으므로 엔드투엔드(end-to-end) 테스트 또는 통합 테스트가 요구됨
• 하나의 애플리케이션이 변화하면 이것과 타 애플리케이션들과의 상호작용이 반드시 테스트되어야 함(소스 애플리케이션을 데이터 마이그레이션을 동반한 타겟 애플리케이션으로 교체하는 것은 이런 변화를 의미). 즉, 상호연결된 애플리케이션들의 맥락(context)에서 타겟 애플리케이션이 마이그레이션된 데이터를 가지고 적절하게 기능을 수행할 수 있는지를 테스트 함
• 원래 소스 애플리케이션에 저장되었던 비즈니스 오브젝트가 다른 애플리케이션의 비즈니스 오브젝트를 참조하거나 또는 연결된 타 애플리케이션이 소스 애플리케이션에 저장된 여러 비즈니스 오브젝트에 액세스하는 상태였을 수도 있음. 통합 테스트는 여러 애플리케이션에 걸친 비즈니스 프로세스를 실행하여 이런 애플리케이션들간의 참조(references)가 여전히 양방향으로 잘 동작하는지 체크함

12. 최종 리허설(The final rehearsal)

• 7단계부터 11단계까지의 모든 테스트를 응축된 형태로 커버함
• 최종 마이그레이션이(최종 테스트가) 프로세스 모델의 모든 세부 단계들을 반복해가면서 이 최종 리허설 단계에서 시행됨

D. 이전(Cut-Over)

마이그레이션 프로그램을 실행하여 최종적으로 타겟 애플리케이션으로 전환하는 단계. 이 단계가 완료되면 데이터 마이그레이션 프로젝트가 종결되고 신규 애플리케이션의 생산적 운영 단계(productive operation phase)가 시작됨

13. 생산적 마이그레이션(Productive migration)

• 데이터 변환 프로그램을 최종 실행하기 전에 소스 애플리케이션에 있는 데이터가 동결됨
• 모든 프로젝트 팀 구성원이 타겟 데이터베이스로 데이터를 올리는데 찬성/반대를 결정하는 최종 승인 회의가 열림. 찬성으로 결정되면 타겟 스테이징 영역의 데이터를 타겟 데이터베이스에 로딩하는 작업을 포함한 데이터 마이그레이션 프로그램이 실행됨
• 앞 단계의 최종 리허설에서 했던 것과 동일한 테스트가 재실행됨. 모든 데이터가 타겟 애플리케이션으로 마이그레이션 되었을 때 프로젝트 팀은 모든 테스트(외양, 가공성, 통합, 완전성/타입 일치)를 재수행함. 전체 마이그레이션 프로그램 런 테스트에서와 마찬가지로 추가적인 문제를 찾기 위해 로그를 체크함. 모든 테스트가 성공하면 소스 애플리케이션을 해제하고 일일 업무 비즈니스를 위하여 타겟 애플리케이션으로 전환함
• 타겟 데이터베이스가 생산 릴리즈되면 더 이상 되돌리기가 불가능(즉, 소스로 후퇴하는 것이 불가능하거나 아니면 아주 많은 비용이 요구됨)

14. 종결(Finalizing)

• 타겟 애플리케이션이 마이그레이션된 데이터와 실제 최종사용자에 의해 생산에 들어가는 시점에 종결 단계가 시작됨. 이런 “완료”에 대한 명확한 정의가 마이그레이션 팀으로부터 IT부서로의 원활한 책임 전이를 허용함
• 향후 데이터 마이그레이션 프로젝트를 용이하게 하고 개선할 수 있는 경험 및 교훈(lessons learned)이 간단한 보고서로 작성됨

14.a 타겟 데이터 클린징(Target data cleansing)

• 선택적인(optional) 작업. 소스 애플리케이션에서 또는 언로딩과 변환 과정에서 데이터가 정제되지 않은 경우(예, 마이그레이션 프로세스 속도를 높이기 위해 클린징을 뒤로 미룬 상황) 타겟 애플리케이션이 생산에 있는 시점에 데이터 클린징이 수행되어야 함

데이터 마이그레이션 프로젝트의 리스크

데이터 마이그레이션 프로젝트에서 자주 나타나는 리스크를 아래와 같이 3개 계층으로 분류함

[데이터 마이그레이션 리스크]

1) 비즈니스 리스크

• 수익성(Profitability): 비용과 수입에 대한 리스크. 직접 비용(즉, 데이터 마이그레이션 프로젝트 자체의 비용)이 반드시 프로젝트 예산을 준수해야 함. 잘못된 데이터 변환으로 인한 간접 비용(indirect costs)이 발생할 수 있음. 예, 차 제조업체에서 500대의 빨간 차와 20,000대의 검정 차 주문이 마이그레이션 후에 20,000대의 빨간 차와 500대의 검정 차 주문으로 바뀌어 수 많은 차가 잘못 조립됨. 시스템 교체 프로젝트의 한 부분인 데이터 마이그레이션이 또 다른 신규 사업, 낮은 운영비, 높은 수입 등을 위한 사전 조건이 되면서 후속 영향(follow-up effects)이 있을 수 있음
• 평판(Reputation): 어떤 은행이 마이그레이션에서 20개의 저축 계정을 누락했을 때 해당 실수를 바로잡는데 큰 비용이 들지는 않지만 이 문제가 미디어에서 부정적으로 다루어지면 은행 평판에 타격을 입을 수 있음
• 규제(Regulation): 특정 분야(예, 금융 산업)에서 감독 기관에게 IT 시스템이 제대로 관리되지 않는다는 인상을 주는 경우 벌금을 포함한 심각한 처벌을 받을 수 있음

2) IT 관리 리스크

• 데이터/정보 손실(Data or information loss): 데이터 마이그레이션은 모든 관련 데이터를 그 의미의 변경 없이 소스 애플리케이션으로부터 타겟 애플리케이션으로 이전해야 함
• 타겟 애플리케이션 안정성(Target application stability): 모든 관련 데이터가 타겟 애플리케이션으로 옮겨졌다 하더라고 마이그레이션 된 데이터가 타겟 애플리케이션의 안전성을 해칠 수 있음(예, 데이터 구조에 대한 암묵적인 가정을 준수하지 못하는 경우)
• 이전 중단(Cut-over aborts): 데이터 마이그레이션 에러로 인해 이전이 성공하지 못함. 데이터 마이그레이션 프로그램의 실행이 중단(aborts)되거나 또는 프로그램은 성공적으로 실행되었지만 데이터가 타겟 애플리케이션으로 전환을 허용하지 않음
• 연장된 다운시간(Extended downtime): 이전이 계획보다 더 많은 시간을 필요로 함. 예, 생산 라인 또는 핵심 은행 시스템이 예상보다 오래 동안 가용하지 않아서 생산 라인이 차를 생산하지 못하고 은행도 서비스를 제공할 수 없게 됨
• 프로젝트 예산 초과(Project budget overruns): 실제 프로젝트 비용이 IT 부서의 예산보다 높아짐
• 지연(Delays): 추가적인 비용이 없는 단순 프로젝트 지연도 리스크가 될 수 있음. 예를 들면, 지연으로 인해 데이터 이전의 핵심 인력이 더 이상 가용하지 않게 되거나, 오래된 애플리케이션의 라이센스가 만료되거나, 세무당국이나 증권거래소가 구 인터페이스를 셧다운 하는 경우 인터페이스 비양립성(incompatibilities)이 발생

3) 데이터 마이그레이션 프로젝트 리스크

• 데이터 마이그레이션 프로그램 리스크: 데이터 마이그레이션 프로그램과 연관된 모든 리스크를 커버함
  – 완전성 리스크: 데이터 마이그레이션 동안에 하나 또는 여러 비즈니스 오브젝트를 분실함. 소스 애플리케이션에는 존재하지 않았던 비즈니스 오브젝트가 타겟 애플리케이션에서 등장함
  – 의미 리스크: 비즈니스 오브젝트가 마이그레이션 되었지만 그 의미가 변경됨(예, 주문된 차는 파란색이었지만 빨간색으로 둔갑). 값은 동일하지만 단위가 변경된 경우도 발생 가능(예, 소스 애플리케이션의 500 USD가 타겟에서는 500 EUR로 간주됨)
  – 데이터 훼손 리스크: 마이그레이션된 데이터가 타겟 애플리케이션의 데이터 모델을 반영하지 않음. 애플리케이션 레벨의 제약(constraints)이 있는 경우 발생. 예를 들면, 저축예금계정에서 마이너스 잔액이 허용되지 않지만 데이터베이스가 이런 제한을 가하지 않음. 즉, 데이터베이스는 훼손된 데이터의 로딩을 막지 않으며 나중에 애플리케이션이 이런 데이터로 인해 다운될 수 있음
  – 안전성 리스크: 코딩 에러로 인해 데이터 마이그레이션 프로그램이 다운되거나 의도치 않게 중단됨
• 마이그레이션 런 리스크: 완전한 데이터 마이그레이션 프로그램 집합의 실행과 관련
  – 실행 시간 리스크: 데이터 마이그레이션 프로그램이 예상 보다 오래 실행됨. 데이터 서브셋으로 테스트 시 10%의 데이터가 마이그레이션 되는데 1시간이 필요했다고 해서 10시간만에 100%가 완료된다는 의미는 아님. 예를 들어, sorting이나 join이 관련된 경우 이런 선형성 가정(linearity assumption)이 맞지 않을 수 있음. 또한 데이터베이스가 디스크 액세스 없이 메인 메모리에서 10%의 데이터를 처리할 수 있다고 해서 100%의 데이터를 마찬가지로 메인 메모리에서 처리할 수 있는 것은 아님
  – 지휘 리스크: 모든 데이터 마이그레이션 프로그램을 조정하고 정확한 순서로 호출하는데 있어서의 어려움. 소규모나 중간 규모 회사의 마이그레이션 프로젝트에서도 수백 개의 데이터 마이그레이션 프로그램이 존재할 수 있으며, 이중 어떤 것도 누락되면 안되고 비즈니스 오브젝트 간의 의존성 때문에 순서가 쉽게 변동 될 수도 없음
• 인프라구조 리스크: 기술적 인프라구조와 연관된 리스크(데이터 마이그레이션 프로그램과 지휘 컴포넌트가 인프라구조에 의존함)
  – 디멘져닝 리스크: 네트워크 층, 스토리지, 또는 데이터베이스 층의 높은 로드(load) 하에서 신뢰성에 문제가 생김. 예를 들면, 마이그레이션 프로그램이 일반 애플리케이션과 성격이 달라서 undo log가 오버플로우 될 수 있음
  – 간섭 리스크: 데이터 마이그레이션 팀뿐만 아니라 사용자, 개발자, 배치 프로세스 등이 이전(cut-over) 동안에 소스 애플리케이션에서 활동(active)할 때 발생. 예를 들어, 사용자가 모든 고객(customers)을 저장한 테이블에 액세스하는 것이 테이블 잠금(table lock)을 유발할 수 있고, 이는 cut-over 동안의 고객 데이터의 마이그레이션을 방해함(즉, 완전한 데이터 마이그레이션이 무산됨)
• 타겟 애플리케이션 리스크: 타겟 애플리케이션에서 기원하는 리스크
  – 패러미터 리스크: 타겟 애플리케이션의 변화로 인해 데이터 마이그레이션 프로그램과 호환할 수 없게 됨. 예, 타겟 애플리케이션 패러미터가 최신 규정에 따라 적절한 ID가 없는 고객의 추가를 허용하지 않도록 변경됨. 하지만 소스 애플리케이션에 존재하는 고객(customer)과 계정(account)이 모두 마이그레이션 되어야만 하며, 따라서 데이터 마이그레이션과 타겟 애플리케이션 패러미터 간의 상호작용이 문제가 될 수 있음