다음을 통해 공유

복잡한 데이터 마이그레이션을 위한 제안된 워크플로

이 문서에서는 대량의 데이터를 마이그레이션하기 위한 단계별 프로세스를 제안합니다. 강력한 클라우드 기반 CRM에서 데이터를 전송하는 경우 사용자 지정 개체, 데이터 간 링크 및 고유한 레코드 ID와 같은 복잡한 설정 때문에 신중하게 계획해야 합니다. 기술적 단계와 마이그레이션이 실제로 작동하는 방식을 모두 고려해야 합니다.

  • 기술 접근 방식: 무결성을 보장하고 관계를 유지하며 유효성 검사 및 오류 처리를 통해 성능을 최적화하면서 데이터를 추출, 변환 및 Dataverse로 로드하는 주요 마이그레이션 단계를 다룹니다.
  • 기능적 접근 방식: 데이터 세분화 및 보관과 같은 기능적 마이그레이션 작업을 다루며, 데이터가 요구 사항을 충족하는지 확인하기 위해 비즈니스 이해 관계자가 참여해야 할 필요성을 강조합니다.

데이터 마이그레이션을 위한 기술 접근 방식

무결성을 유지하고 중단을 최소화하면서 데이터를 추출, 변환 및 로드하는 구조화된 접근 방식에 따라 원활한 마이그레이션을 보장합니다.

6개의 상호 연결된 원을 단계로 사용하는 데이터 마이그레이션 워크플로를 보여 주는 다이어그램

원본에서 준비 데이터베이스로 데이터 추출

복잡한 데이터 마이그레이션의 경우 별도의 데이터베이스(예: SQL Server)에서 데이터를 준비하는 것이 좋습니다. 이 스테이징 영역은 진행 중인 비즈니스 작업을 방해하지 않고 원본 시스템의 스냅샷을 캡처합니다.

주요 고려 사항:

  • 전체 및 델타 로드: 데이터를 전체 또는 증분(델타) 로드로 구성합니다. 자동 생성된 타임스탬프를 사용하여 데이터 도착을 추적하고 향후 로드에 대한 변경 내용을 식별합니다.
  • 장애 조치 처리: 마이그레이션을 중단하지 않고 실패한 레코드(예: 필드 길이, 잘못된 조회로 인해)를 건너뛰도록 프로세스를 디자인합니다. 다시 처리하기 전에 문제를 기록하고 해결합니다.
  • 필드 매핑: 데이터를 Dataverse로 마이그레이션하기 전에 스테이징 계층의 대상 형식 및 준비 데이터베이스의 값 범위와 일치하도록 원본 값을 변환하여 효율성을 향상시킵니다.
  • 데이터 유효성 검사: 무결성 검사를 실행하여 누락된 참조와 같은 문제를 catch합니다. 데이터 추출은 몇 시간 또는 며칠에 걸쳐 진행될 수 있으므로 준비 계층을 사용하여 불완전한 레코드를 필터링하고 일관성을 보장합니다.
  • 데이터 시각화: 최종 마이그레이션 전에 준비 데이터베이스를 사용하여 데이터(예: 레코드 개수 또는 재무 필드 합계)를 감사하고 분석합니다.

데이터를 대상 준비 데이터베이스로 변환

원본 시스템에서 데이터를 추출한 후 Dataverse 스키마를 미러링하고 직접 삽입 또는 업데이트할 준비가 된 값을 포함하는 대상 준비 데이터베이스로 변환합니다.

키 변환 단계:

  • 필드 매핑: 원본 열을 대상 Dataverse 열에 매핑합니다. 스크립트를 사용하여 필요한 경우 테이블을 조인하고 병합합니다.

  • 옵션 집합 변환: 매핑 테이블(예: OptionSetMapping) 및 대량 업데이트 쿼리를 사용하여 텍스트 기반 옵션 집합 값을 Dataverse 정수로 변환합니다. 원본 시스템에서 대상 시스템으로 옵션 집합 값의 변환을 표준화하고 자동화하는 테이블을 만듭니다.

    표: OptionSetMapping

    열 이름 데이터 형식
    원본 테이블 이름 문자열
    대상 테이블 이름 문자열
    원본 텍스트 문자열
    대상 텍스트 문자열
    대상 값 문자열

    OptionSetMapping 테이블을 사용하여 옵션 집합 값을 대량으로 효율적으로 변환하고 업데이트할 수 있습니다. 예를 들어 일치하는 텍스트 값을 기반으로 연락처 테이블의 모든 옵션 집합 값을 업데이트하려면 다음을 수행합니다.

    Update C.\<OptionsetValue\> = M.\<TargetValue\> 
FROM Contact C 
JOIN OptionsetMapping M 
  ON C.OptionsetText = M.TargetText 
  AND M.TargetTableName = 'Contact'

  • 사용자 지정 GUID를 사용하지 않도록 합니다. Dataverse가 조각화 및 성능 문제를 방지하기 위해 GUID를 생성하도록 합니다.

  • 문자열 길이 확인: 문자열 값이 Dataverse 제한에 맞는지 확인합니다. 필요에 따라 자르거나 조정합니다.

  • 계산 필드: 원본에 누락된 경우 파생 필드(예: 조회 이름)를 추가합니다.

  • 기타 고려 사항: Dataverse 스키마와 일치하도록 테이블을 디자인할 때 다음 키 열 및 지원 테이블을 고려합니다.

    • DataMigration_CreatedDateTime: 데이터 로드 일괄 처리를 추적하기 위한 자동 사용자 지정 타임스탬프입니다.
    • 작업 플래그: 삽입(I), 업데이트(U) 또는 삭제(D)를 나타냅니다.
    • 처리 플래그: 처리됨(P), 처리되지 않은(U), 오류(E) 또는 성공(S)을 추적합니다.
    • 고유 열: 고유 ID(예: 원본 시스템의 고유 ID)를 사용하여 레코드를 매핑합니다.
    • 성공/오류 테이블: 결과를 기록하고 재시도를 지원하기 위해 별도의 테이블(예: Contact_Success, Contact_Error)을 유지 관리합니다.

시퀀스 테이블 및 프리로드 조회

정적 변환 후에는 테이블이 서로를 참조하여 격리된 가져오기를 불가능하게 만드는 주기적 종속성을 줄이도록 테이블의 순서를 지정합니다. 다음 방법을 사용합니다.

  • 마이그레이션에 적합한 모든 테이블을 나열합니다.
  • 테이블당 고유한 조회 수를 계산합니다(마이그레이션하지 않는 경우 기본 제공 필드 Created By 및 기타 테이블 조회 무시).
  • 조회 횟수를 기준으로 테이블을 오름차순으로 정렬합니다.
  • 두 조회를 모두 계산하여 N:N 관계 테이블을 포함합니다.
  • 다중 테이블 조회(예: "관련" 필드)를 제외합니다.

이 방법은 데이터 마이그레이션 로드 시퀀스를 정의하며 대부분의 시나리오에서 잘 작동합니다. 더 복잡한 경우:

  • 고유 식별자(예: importsequencenumber)를 사용하여 삽입하는 동안 GUID가 생성될 때 스테이징과 Dataverse 간의 레코드를 일치시킬 수 있습니다.
  • 잠금 문제를 방지하고 성능을 향상시키기 위해 성공 및 오류 로그를 분리합니다.
  • 이미 마이그레이션된 테이블에서 조회할 GUID를 미리 로드하여 삽입 중 참조를 해결합니다.
  • 다음을 통해 순환 종속성을 처리합니다.
    • 종속 조회 없이 레코드 삽입
    • 관련 레코드가 로드된 후 이러한 조회를 업데이트합니다.

Dataverse에 데이터 로드

다음 단계는 Dataverse에 데이터를 로드하는 방법을 결정하고 구현하는 것입니다.

  1. 도구: 데이터 크기 및 복잡성에 따라 도구를 선택합니다.

    • SDK 구성 마이그레이션 도구
    • Azure Data Factory
    • KingswaySoft
    • 스크라이브
    • XrmToolBox의 데이터 전송자

  2. 주요 고려 사항(도구에 관계없는):

    • 순환 종속성 처리: 순환 조회를 최소화하기 위해 시퀀스 테이블이 로드됩니다. 종속 조회 없이 레코드를 삽입한 다음 나중에 업데이트합니다.

    • 레코드 ID 추적: 성공 테이블에서 Dataverse GUID를 캡처한 다음 고유 식별자(예: importsequencenumber)를 사용하여 주 테이블을 업데이트합니다.

    • 일괄 처리 크기 및 스레드 수 최적화: 대량 작업의 성능을 최적화하기 위한 지침을 검토합니다. 사용하는 애플리케이션은 특별한 수의 요청이 Dataverse로 전송되는 경우 발생하는 서비스 보호 오류를 관리해야 합니다. 사용자 고유의 코드를 작성하고 Dataverse Web API를 사용하는 경우 서비스 보호 API 제한에 설명된 대로 429 오류를 다시 시도해야 합니다. Dataverse SDK를 사용하는 경우 이러한 오류를 관리합니다.

      최적의 성능을 얻으려면 테이블 복잡성에 따라 일괄 처리 크기 및 스레드 수를 조정합니다.

      • OOB(기본 제공) 테이블( 예: 연락처, 계정, 잠재 고객): 기본 제공 플러그 인 및 작업으로 인해 이러한 테이블이 느려집니다. 권장: 일괄 처리 크기 200~300, 최대 30개 스레드(≤10개 조회 및 50~70개 열)
      • 간단한 테이블 (조회가 거의 또는 전혀 없음): 권장: 일괄 처리 크기 ≤10, 최대 50개의 스레드.
      • 적당히 복잡한 사용자 지정 테이블 (일부 조회): 권장: 일괄 처리 크기 ≤100, 최대 30개의 스레드.
      • 대형/복합 테이블 (>열 100개, >조회 20개): 오류를 줄이기 위해 일괄 처리 크기 10~20개, 최대 10~20개 스레드를 사용하는 것이 좋습니다.

  3. 인프라 팁: 데이터 마이그레이션 성능을 최대화하려면 Dataverse 환경과 동일한 지역에 있는 VM(가상 머신)에서 마이그레이션을 실행합니다. 이 방법은 대기 시간을 크게 줄이고 전체 프로세스의 속도를 향상시킵니다. Dataverse 환경의 지역을 확인하는 방법을 알아봅니다.

  4. 오류 처리: 오류를 무시하지 마세요. 오류를 해결하여 연속 오류를 방지합니다. 기본값(예: 빈 조회, 기본 옵션 집합 값)을 사용하여 자리 표시자 레코드를 삽입하고 GUID를 캡처합니다.

  5. 상태 업데이트: 초기 레코드를 삽입하는 동안에만 활성 상태를 설정합니다. 비활성 레코드 또는 사용자 지정 상태/상태 코드의 경우 데이터 유효성 검사 후에 업데이트합니다. 대부분의 사용자 지정 테이블의 경우 삽입 직후 상태 업데이트가 수행됩니다. 그러나 Case, Opportunity 또는 Lead와 같은 특수 테이블의 경우 마이그레이션이 끝날 때까지 상태 업데이트를 지연합니다. 이러한 레코드가 닫힌 후에는 데이터 무결성을 위험에 빠뜨리는 시간이 많이 걸리는 프로세스인 다시 열지 않는 한 수정할 수 없습니다.

  6. 소유권 및 보안: Dataverse의 사용자 수준 및 사업부 보안이 모두 소유자의 사업부에 연결되기 때문에 데이터 삽입 중에 올바른 레코드 소유자를 설정합니다. 만들 때 올바른 사업부를 할당합니다. 나중에 업데이트하면 모든 보안 역할이 제거됩니다.

    • 스텁 사용자를 사용하십시오:
      • Dataverse는 대규모 또는 기록 마이그레이션에 유용한 스텁 사용자(비면허)를 지원합니다. 스텁 사용자에게는 Salesperson 보안 역할이 자동으로 할당됩니다. 이 역할의 이름을 바꾸거나 수정하지 마세요. 스텁 사용자는 관련 테이블에 대한 사용자 수준 읽기 권한이 있는 경우 레코드를 소유할 수 있습니다.
    • 권장 사항:
      • 삽입 시 올바른 사업부를 설정하여 마이그레이션하는 동안 허가되지 않은 모든 사용자를 만듭니다.
      • 만든 후 사업부를 변경하지 마세요. 이렇게 하면 Salesperson을 비롯한 모든 역할이 제거됩니다.
      • Salesperson 역할에 모든 마이그레이션 적격 테이블에 대한 읽기 권한이 있는지 확인합니다.
      • 이 역할로 Dataverse 환경에서 사용하지 않도록 설정된 사용자도 레코드를 소유할 수 있습니다.

  7. 통화 처리: Dataverse는 과거 환율을 지원하지 않으므로, 사전 유효성 검사 플러그인을 사용하여 삽입 시 환율을 설정합니다.

Dataverse에 데이터 로드 게시

Dataverse에 데이터를 로드한 후 다음 단계에 따라 데이터 무결성을 보장하고 다운스트림 문제를 최소화합니다.

  1. 기본 테이블을 GUID로 업데이트합니다.

    • 로드가 성공하면 다음과 같은 importsequencenumber고유 식별자를 사용하여 성공 테이블에서 주 테이블로 Dataverse 레코드 GUID를 복사합니다.
    • 레코드를 다음과 같이 표시하도록 처리 플래그를 업데이트합니다.
      • P – 처리됨
      • E – 오류 발생
      • U – 처리되지 않은 이 전략은 이미 처리된 레코드를 건너뛰어 효율적인 재실행을 가능하게 하고 후속 로드에서 조회 확인을 지원합니다.

  2. 실패한 레코드 다시 시도: 재작업을 줄이고 참조 무결성을 유지하려면 다음 작업을 고려합니다.

    • 허용되는 길이를 초과하는 경우 문자열 값을 트리밍합니다.
    • 매핑이 누락된 경우 기본 옵션 집합 값을 적용합니다.
    • 원래 소유자를 사용할 수 없는 경우(스텁 사용자로도) 대체 소유자를 할당합니다.
    • 해결되지 않은 조회에는 빈 값 또는 기본값을 사용합니다.
    • 자리 표시자 레코드도 관련 테이블의 조회에 필요한 GUID를 생성하는 데 도움이 될 수 있습니다.

데이터 마이그레이션에 탄력적 테이블 사용

탄력적 테이블 은 대량의 데이터를 실시간으로 처리하도록 설계되었습니다. 탄력적 테이블을 사용하면 확장성, 대기 시간 또는 성능 문제 없이 대량의 데이터를 가져오고 저장하고 분석할 수 있습니다.

탄력적 테이블은 특정 기간 후에 유연한 스키마, 수평 크기 조정 및 데이터 자동 제거를 위한 고유한 기능을 제공합니다.

탄력적 테이블은 Azure Cosmos DB에 저장되며 다음을 지원합니다.

  • JSON 열을 통한 스키마 없는 데이터
  • 자동 가로 크기 조정
  • 부실 데이터의 자동 삭제를 위한 TTL(Time to Live)
  • 성능 최적화를 위한 분할

탄력적 테이블은 변수 스키마가 있는 대량 가져오기에 가장 적합합니다.

탄력적 테이블은 특정 데이터 형식에 적합합니다.

데이터 형식 Description
원시 수집 데이터 레거시 시스템에서 출처 로그, 센서 데이터 스트림 또는 대량 데이터 내보내기 예를 들어 레거시 ERP의 고객 상호 작용 로그, 이전 전자 메일 스레드 및 이전 시스템의 지원 티켓이 있습니다.
반구조화된 레코드 고정 스키마에 맞지 않는 선택적 또는 진화하는 필드가 있는 데이터입니다. 예를 들어 선택적 필드가 있는 고객 피드백 양식 또는 사용자 지정 노트 또는 태그가 있는 이벤트 등록 양식이 있습니다.
유효성 검사를 위한 데이터 준비 데이터를 관계형 테이블에 동기화하기 전의 임시 보유 영역입니다. 예를 들어 주 잠재 고객 테이블에 추가되기 전에 중복 제거 및 유효성 검사를 기다리는 가져온 잠재 고객 데이터입니다.
시간이 중요한 데이터 또는 만료 데이터 임시 CRM 레코드의 자동 삭제에는 TTL(Time-to-Live)을 사용합니다. 예를 들어 캠페인, 고객 설문 조사 또는 온보딩 포털에 대한 일회성 액세스 링크, 임시 설문 조사 응답에 연결된 프로모션 할인 코드가 있습니다.
분할된 대량 데이터 ID 또는 범주별로 데이터를 분할하여 성능 및 확장성을 향상시킵니다. 예를 들어 대량 데이터 마이그레이션 중에 계정 ID 또는 지역 ID별로 분할하거나 분석을 위한 캠페인 ID별로 고객 활동 로그를 분할합니다.

탄력적 테이블에 적합하지 않은 데이터 형식

탄력적 테이블은 유연하고 대규모 시나리오에 최적화되어 있지만 모든 데이터 형식이 적합한 것은 아닙니다. 이 섹션에서는 성능, 비용 효율성 및 유지 관리를 보장하기 위해 다른 곳에 더 잘 저장되는 일반적인 CRM 데이터 패턴을 중점적으로 설명합니다. 탄력적 테이블에서 현재 지원되지 않는 기능에 대해 자세히 알아보기

데이터 형식 이유
고도의 관계형 데이터 탄력적 테이블은 조인 또는 조회를 지원하지 않습니다.
중요 비즈니스용 레코드 트랜잭션 무결성 또는 플러그 인 지원 없음
복잡한 유효성 검사가 필요한 데이터 비즈니스 규칙에 따라 표준 테이블에서 더 효과적으로 처리됩니다.

기능 데이터 세분화 및 보관 프레임워크

효과적인 기술 계획에는 올바른 도구 및 인프라 선택, 원본 및 대상 데이터 볼륨 조정, 감사 및 조정 프로세스 설정이 포함됩니다. 특히 이동해야 하는 데이터와 데이터가 속한 위치에 대한 사전 분석이 부족하여 많은 마이그레이션이 복잡해집니다. 이 섹션에서는 성공적인 마이그레이션을 지원하기 위한 데이터 분석의 핵심 원칙을 간략하게 설명합니다.

데이터 구분

데이터 구분은 한 CRM 시스템에서 Dataverse로 마이그레이션하는 핵심 단계입니다. 비즈니스 기능(예: 영업, 서비스 또는 마케팅)을 기준으로 데이터 테이블을 구성하여 마이그레이션 계획 및 실행을 간소화합니다.

테이블 구분

먼저 비즈니스 영역(예: 영업, 마케팅, 서비스)으로 그룹화된 마이그레이션에 적합한 모든 테이블을 나열합니다. 그러면:

  • Excel 또는 유사한 도구에서 스키마를 문서화합니다.
  • 원본 시스템에서 기본 쿼리를 실행하여 열 사용량을 확인합니다.
  • 사용 빈도가 낮은 열에 플래그를 설정합니다. 레코드의 5% 미만에 값이 포함되어 있는 경우, 비즈니스 이해 관계자들과 상의하여 이를 유지할지 또는 폐기할지를 결정합니다.

이 간단한 분석은 마이그레이션 범위를 크게 줄일 수 있습니다. 장기 실행 CRM 시스템에서는 일반적으로 30~40개의% 열과 최대 20개의% 테이블을 제거하여 프로세스를 간소화하고 성능을 향상합니다.

열 관련성

일부 원본 시스템 열은 Dataverse에 직접 매핑되고 다른 열은 계산 필드가 됩니다. 이러한 열을 분리하고 비즈니스 관련자와 협의하여 마이그레이션 작업이 필요한지 여부를 결정합니다.

원본 시스템에서만 관련이 있거나 대상에서 의미가 없는 열을 무시합니다. 여기에는 마이그레이션에서 특정 목적을 제공하지 않는 한 만든 사람, 수정한 사람 또는 행 버전 번호와 같은 많은 기본 제공 필드가 포함됩니다.

파일 형식 데이터

원본 시스템에 파일 형식 데이터가 포함된 경우 이러한 필드에 일찍 플래그를 지정하고 별도의 마이그레이션 전략을 계획합니다. 다음 파일 형식을 고려합니다.

  • Office 문서(예: Word, Excel, PowerPoint): 최대 20,000개의 파일의 경우 SharePoint와 같은 공동 작업 플랫폼으로 마이그레이션하여 다중 사용자 액세스를 사용하도록 설정합니다.
  • 멀티미디어 파일(예: 이미지, 비디오): 재생을 지원하는 플랫폼을 선택합니다. 옵션에는 SharePoint, 스트리밍 서비스 또는 기타 미디어 친화적인 스토리지 솔루션이 포함됩니다.
  • 대용량 또는 파일 크기: 스토리지 비용이 우려되는 경우 Azure Blob Storage 또는 백그라운드에서 Azure Blob을 사용하는 Dataverse의 네이티브 파일 열을 사용합니다.
  • 맬웨어 보호: 마이그레이션 전에 맬웨어 검색 도구(예: Azure Advanced Threat Protection)를 통해 파일을 실행하여 보안을 보장합니다.

파일 관련성을 검토한 후에는 특히 장기 실행 CRM 시스템에서 총 데이터 볼륨이 크게 감소하여 마이그레이션의 효율성을 높이는 경우가 많습니다.

데이터 보관 전략

이전 전자 메일, 비공개 사례 또는 실격된 잠재 고객과 같은 일부 데이터는 여전히 중요하지만 거의 액세스하지 않습니다. 비즈니스 운영을 방해하지 않고 마이그레이션 볼륨을 줄이려면 스마트 보관 전략을 개발합니다.

1단계: 보관 가능한 데이터 식별

일반적인 후보는 다음과 같습니다.

  • 3년보다 오래된 전자 메일
  • 닫힌 사례
  • 잃어버린 기회
  • 비유량으로 선별된 잠재 고객
  • 마케팅 전자 메일, 게시물 및 감사 로그

시스템을 검토하여 보관할 수 있는 다른 테이블을 식별합니다.

2단계: 보관 방법 선택

  • 원본 시스템에 데이터를 유지합니다. 다른 사용자를 비활성화하여 비용을 절감하면서 액세스에 대한 몇 가지 관리자 라이선스를 유지합니다.
  • 외부 스토리지로 이동합니다. 로컬 데이터베이스, Azure Blob Storage 또는 Azure 테이블을 사용하여 보관된 레코드를 저장합니다. 이 방법은 스토리지 및 마이그레이션 비용을 줄이지만 별도의 마이그레이션 전략이 필요합니다.
  • 별도의 Dataverse 환경을 사용합니다. 이 옵션은 일반적이지 않지만 보관된 데이터를 격리하려는 경우에 유용합니다. 나중에 이 환경을 사용 중지하여 전환 계획을 간소화할 수 있습니다.

Dataverse로 빠르고 안정적인 데이터 마이그레이션을 보장하려면 다음을 수행합니다.

  • Dataverse 환경과 동일한 지역에 있는 VM(가상 머신)을 사용하여 대기 시간을 줄이고 마이그레이션 속도를 개선합니다.
  • 고성능 VM을 선택합니다. 최소한 8개의 코어, 28GB RAM 및 500GB 스토리지가 있는 D4 VM을 사용하여 대규모 데이터 볼륨을 효율적으로 처리합니다.
  • VM에서 로컬 데이터베이스를 선호합니다. 마이그레이션하는 동안 원격 연결을 방지합니다. Azure Data Factory를 사용하는 경우 최적의 성능을 위해 Dataverse 환경과 동일한 지역에 배포합니다.

다음 단계

아키텍처 우수성을 위해 Power Platform Well-Architected 따르기

  • Last updated on