문제를 일으키지 않고 레거시 데이터 마이그레이션

레거시 데이터를 마이그레이션하는 것은 어렵습니다.

많은 조직에는 오래되고 복잡한 온프레미스 비즈니스 CRM 시스템이 있습니다. 오늘날 많은 이점이 있는 클라우드 SaaS 대안이 많이 있습니다. 사용한 만큼만 지불하고 사용한 만큼만 지불합니다. 따라서 그들은 새로운 시스템으로 이동하기로 결정합니다.

아무도 고객에 대한 귀중한 데이터를 기존 시스템에 남겨두고 비어 있는 새 시스템으로 시작하기를 원하지 않으므로 이 데이터를 마이그레이션해야 합니다. 불행히도 데이터 마이그레이션은 배포 노력의 약 50%가 데이터 마이그레이션 활동에 사용되기 때문에 쉬운 작업이 아닙니다. Gartner에 따르면 Salesforce는 클라우드 CRM 솔루션의 선두 주자입니다. 따라서 데이터 마이그레이션은 Salesforce 배포의 주요 주제입니다.

그렇다면 레거시 데이터를 빛나는 새 시스템으로 성공적으로 전환하고 모든 기록을 보존하려면 어떻게 해야 할까요? 이 기사에서는 성공적인 데이터 마이그레이션을 위한 10가지 팁을 제공합니다. 처음 5가지 팁은 사용된 기술에 관계없이 모든 데이터 마이그레이션에 적용됩니다.

일반적인 데이터 마이그레이션

1. 마이그레이션을 별도의 프로젝트로 만들기

소프트웨어 배포 체크리스트에서 데이터 마이그레이션은 대상 시스템에 대해 미리 정의된 매핑이 있는 영리한 "원 버튼" 데이터 마이그레이션 도구로 처리되는 "내보내기 및 가져오기" 항목이 아닙니다.

데이터 마이그레이션은 별도의 프로젝트, 계획, 접근 방식, 예산 및 팀이 필요한 복잡한 활동입니다. 엔터티 수준 범위 및 계획은 프로젝트 시작 시 생성되어야 하며, "오, 우리는 그 고객의 방문 보고서를 로드하는 것을 잊었습니다. 누가 그것을 할 것입니까?"와 같은 놀라움이 없도록 해야 합니다. 마감 2주 전.

데이터 마이그레이션 접근 방식은 데이터를 한 번에 로드할지( 빅뱅 이라고도 함) 또는 매주 작은 배치를 로드할지 여부를 정의합니다.

그러나 이것은 쉬운 결정이 아닙니다. 접근 방식은 동의해야 하며 모든 비즈니스 및 기술 이해 관계자에게 전달되어 모든 사람이 새 시스템에 언제 어떤 데이터가 나타날지 알 수 있도록 해야 합니다. 이는 시스템 중단에도 적용됩니다.

2. 현실적으로 추정

데이터 마이그레이션의 복잡성을 과소평가하지 마십시오. 이 프로세스에는 많은 시간이 소요되는 작업이 수반되며 프로젝트 초기에는 보이지 않을 수 있습니다.

예를 들어, 실제 데이터의 무리와 함께 훈련 목적으로 특정 데이터 세트를 로드하지만 민감한 항목은 난독화하여 훈련 활동이 클라이언트에 대한 이메일 알림을 생성하지 않도록 합니다.

추정의 기본 요소는 소스 시스템에서 대상 시스템으로 전송할 필드의 수입니다.

필드 이해, 소스 필드를 대상 필드에 매핑, 변환 구성 또는 빌드, 테스트 수행, 필드에 대한 데이터 품질 측정 등을 포함하여 모든 필드에 대해 프로젝트의 여러 단계에서 어느 정도의 시간이 필요합니다.

Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas 등과 같은 영리한 도구를 사용하면 특히 빌드 단계에서 이 시간을 줄일 수 있습니다.

특히 모든 마이그레이션 프로젝트에서 가장 중요한 작업인 소스 데이터를 이해하는 것은 도구로 자동화할 수 없지만 분석가는 시간을 들여 필드 목록을 하나씩 검토해야 합니다.

전체 노력에 대한 가장 간단한 추정은 레거시 시스템에서 전송된 모든 필드에 대해 1인일입니다.

예외는 복사할 테이블 수를 기준으로 추정할 수 있는 추가 변환 없이 동일한 소스 스키마와 대상 스키마 간의 데이터 복제(1:1 마이그레이션이라고도 함)입니다.

자세한 견적은 그 자체로 예술입니다.

3. 데이터 품질 확인

레거시 시스템에서 보고된 데이터 품질 문제가 없더라도 원본 데이터의 품질을 과대평가하지 마십시오.

새 시스템에는 기존 데이터로 위반될 수 있는 새 규칙이 있습니다. 다음은 간단한 예입니다. 연락처 이메일은 새 시스템에서 필수일 수 있지만 20년 된 레거시 시스템은 다른 관점을 가질 수 있습니다.

오랫동안 건드리지 않았지만 새로운 시스템으로 이전할 때 활성화될 수 있는 과거 데이터에 숨겨진 광산이 있을 수 있습니다. 예를 들어, 더 이상 존재하지 않는 유럽 통화를 사용하는 이전 데이터는 유로로 변환해야 합니다. 그렇지 않으면 새 시스템에 통화를 추가해야 합니다.

데이터 품질은 노력에 큰 영향을 미치며 간단한 규칙은 다음과 같습니다. 역사에서 더 멀리 갈수록 더 큰 혼란을 발견하게 될 것입니다. 따라서 새 시스템으로 이전할 기록의 양 을 조기에 결정하는 것이 중요합니다.

4. 비즈니스맨 참여

비즈니스 사람들은 데이터를 진정으로 이해하고 따라서 버릴 수 있는 데이터와 유지할 데이터를 결정할 수 있는 유일한 사람입니다.

매핑 연습 중에 비즈니스 팀의 누군가가 참여하는 것이 중요하며 향후 역추적을 위해 매핑 결정과 그 이유를 기록하는 것이 유용합니다.

그림은 천 단어보다 더 가치가 있으므로 테스트 배치를 새 시스템에 로드하고 비즈니스 팀이 이를 가지고 놀게 하십시오.

비즈니스 팀에서 데이터 마이그레이션 매핑을 검토하고 승인하더라도 데이터가 새 시스템의 UI에 표시되면 깜짝 놀랄 수 있습니다.

"아, 이제 알겠습니다. 우리는 그것을 조금 바꿔야 합니다."는 일반적인 문구가 됩니다.

일반적으로 매우 바쁜 사람들인 주제별 전문가의 참여에 실패하는 것은 새 시스템이 가동된 후 문제가 발생하는 가장 일반적인 원인입니다.

5. 자동화된 마이그레이션 솔루션을 목표로

데이터 마이그레이션은 종종 일회성 활동으로 간주되며 개발자는 솔루션을 한 번만 실행하기를 희망하는 수동 작업으로 가득 찬 솔루션으로 끝나는 경향이 있습니다. 그러나 그러한 접근 방식을 피해야 할 많은 이유가 있습니다.

• 마이그레이션이 여러 웨이브로 분할되는 경우 동일한 작업을 여러 번 반복해야 합니다.
• 일반적으로 모든 웨이브에 대해 최소 3번의 마이그레이션 실행이 있습니다. 데이터 마이그레이션의 성능과 기능을 테스트하기 위한 테스트 실행, 전체 데이터 세트를 테스트하고 비즈니스 테스트를 수행하기 위한 전체 데이터 유효성 검사 부하, 그리고 물론 프로덕션 부하입니다. 데이터 품질이 좋지 않으면 실행 횟수가 늘어납니다. 데이터 품질 개선은 반복적인 프로세스이므로 원하는 성공률에 도달하려면 여러 번 반복해야 합니다.

따라서 마이그레이션이 본질적으로 일회성 작업이더라도 수동 작업을 수행하면 작업 속도가 크게 느려질 수 있습니다.

Salesforce 데이터 마이그레이션

다음으로 성공적인 Salesforce 마이그레이션을 위한 5가지 팁을 다룰 것입니다. 이 팁은 다른 클라우드 솔루션에도 적용될 수 있습니다.

6. 긴 부하에 대비하기

성능은 온프레미스에서 클라우드 솔루션으로 이동할 때 가장 큰 절충안 중 하나입니다. Salesforce는 제외되지 않습니다.

온프레미스 시스템은 일반적으로 기본 데이터베이스에 대한 직접 데이터 로드를 허용하며 우수한 하드웨어를 사용하면 시간당 수백만 개의 레코드에 쉽게 도달할 수 있습니다.

그러나 클라우드에서는 그렇지 않습니다. 클라우드에서 우리는 몇 가지 요인에 의해 크게 제한됩니다.

• 네트워크 대기 시간 – 데이터는 인터넷을 통해 전송됩니다.
• Salesforce 응용 프로그램 계층 – 데이터가 Oracle 데이터베이스에 도착할 때까지 두꺼운 API 다중 테넌시 계층을 통해 데이터가 이동됩니다.
• Salesforce의 사용자 정의 코드 – 사용자 정의 유효성 검사, 트리거, 워크플로, 중복 감지 규칙 등 – 대부분이 병렬 또는 대량 로드를 비활성화합니다.

결과적으로 로드 성능은 시간당 수천 개의 계정이 될 수 있습니다.

필드 수, 유효성 검사 및 트리거와 같은 항목에 따라 더 적을 수도 있고 더 많을 수도 있습니다. 그러나 직접 데이터베이스 로드보다 몇 등급 더 느립니다.

Salesforce의 데이터 볼륨에 따라 달라지는 성능 저하도 고려해야 합니다.

외래 키, 고유 필드 및 복제 규칙 평가를 확인하는 데 사용되는 기본 RDBMS(Oracle)의 인덱스로 인해 발생합니다. 기본 공식은 정렬 및 B-트리 작업에서 O(logN) 시간 복잡도 부분으로 인해 10 등급마다 약 50% 느려집니다.

또한 Salesforce에는 많은 리소스 사용 제한이 있습니다.

그 중 하나는 24시간 롤링 창에서 일괄 API 제한이 5,000개로 설정되어 있으며 각 일괄 처리에 최대 10,000개의 레코드가 있습니다.

따라서 이론상 최대값은 24시간 동안 로드된 5천만 개의 레코드입니다.

실제 프로젝트에서는 예를 들어 사용자 지정 트리거를 사용할 때 제한된 배치 크기로 인해 최대값이 훨씬 더 낮습니다.

이는 데이터 마이그레이션 접근 방식에 큰 영향을 미칩니다.

중간 규모의 데이터 세트(100,000개에서 100만 개 계정)의 경우에도 빅뱅 접근 방식은 문제가 되지 않으므로 데이터를 더 작은 마이그레이션 웨이브로 분할해야 합니다.

물론 이는 전체 배포 프로세스에 영향을 미치고 사용자가 입력한 데이터와 이전 마이그레이션으로 이미 채워진 시스템에 데이터 증분을 추가하기 때문에 마이그레이션 복잡성을 증가시킵니다.

마이그레이션 변환 및 유효성 검사에서 이 기존 데이터도 고려해야 합니다.

또한 로드가 길면 시스템 중단 중에 마이그레이션을 수행할 수 없습니다.

모든 사용자가 한 국가에 있는 경우 야간에 8시간의 정전을 활용할 수 있습니다.

그러나 코카콜라와 같이 전 세계에 사업을 운영하는 회사의 경우에는 불가능합니다. 시스템에 미국, 일본 및 유럽이 있으면 모든 시간대에 걸쳐 있으므로 사용자에게 영향을 주지 않는 유일한 중단 옵션은 토요일입니다.

그리고 그것만으로는 충분하지 않을 수 있으므로 사용자가 시스템 작업을 할 때 온라인 상태 에서 로드해야 합니다.

7. 애플리케이션 개발 시 마이그레이션 요구 사항 존중

유효성 검사 및 트리거와 같은 응용 프로그램 구성 요소는 데이터 마이그레이션 활동을 처리할 수 있어야 합니다. 시스템이 온라인 상태여야 하는 경우 마이그레이션 로드 시 유효성 검사를 강제로 비활성화하는 것은 옵션이 아닙니다. 대신 데이터 마이그레이션 사용자가 수행한 변경 사항에 대한 유효성 검사에서 다른 논리를 구현해야 합니다.

• 날짜 필드는 실제 시스템 날짜와 비교하면 안 됩니다. 그렇게 하면 기록 데이터를 로드할 수 없기 때문입니다. 예를 들어 유효성 검사에서는 마이그레이션된 데이터에 대해 과거 계정 시작 날짜를 입력할 수 있어야 합니다.
• 기록 데이터로 채워지지 않을 수 있는 필수 필드는 필수가 아닌 것으로 구현되어야 하지만 사용자에게 민감한 유효성 검사를 통해 마이그레이션에서 오는 데이터에 대해 빈 값을 허용하지만 GUI를 통해 일반 사용자로부터 오는 빈 값은 거부합니다. .
• 트리거, 특히 새 레코드를 통합으로 보내는 트리거는 마이그레이션된 데이터로 통합이 플러딩되는 것을 방지하기 위해 데이터 마이그레이션 사용자에 대해 켜고 끌 수 있어야 합니다.

또 다른 트릭은 마이그레이션된 모든 개체에서 필드 레거시 ID 또는 마이그레이션 ID를 사용하는 것입니다. 여기에는 두 가지 이유가 있습니다. 첫 번째는 분명합니다. 역추적을 위해 이전 시스템의 ID를 유지하는 것입니다. 데이터가 새 시스템에 들어간 후에도 사람들은 이메일, 문서 및 버그 추적 시스템에서 찾을 수 있는 이전 ID를 사용하여 계정을 검색하기를 원할 수 있습니다. 나쁜 습관? 아마도. 그러나 사용자는 이전 ID를 유지하면 감사할 것입니다. 두 번째 이유는 기술적이며 Salesforce가 Microsoft Dynamics와 달리 새 레코드에 대해 명시적으로 제공된 ID를 허용하지 않지만 로드 중에 생성한다는 사실에서 비롯됩니다. 문제는 부모 개체의 ID를 할당해야 하기 때문에 자식 개체를 로드하려고 할 때 발생합니다. 로드한 후에만 해당 ID를 알 수 있으므로 이것은 무의미한 연습입니다.

예를 들어 계정 및 연락처를 사용하겠습니다.

1. 계정에 대한 데이터를 생성합니다.
2. Salesforce에 계정을 로드하고 생성된 ID를 받습니다.
3. 연락처 데이터에 새 계정 ID를 통합합니다.
4. 연락처에 대한 데이터를 생성합니다.
5. Salesforce에서 연락처를 로드합니다.

특별한 외부 필드에 저장된 레거시 ID가 있는 계정을 로드하여 이 작업을 더 간단하게 수행할 수 있습니다. 이 필드는 상위 참조로 사용할 수 있으므로 연락처를 로드할 때 계정 레거시 ID를 상위 계정에 대한 포인터로 사용하기만 하면 됩니다.

1. 레거시 ID를 포함하여 계정에 대한 데이터를 생성합니다.
2. 계정 레거시 ID를 포함하여 연락처에 대한 데이터를 생성합니다.
3. Salesforce에 계정을 로드합니다.
4. 계정 레거시 ID를 상위 참조로 사용하여 Salesforce에서 연락처를 로드합니다.

여기서 좋은 점은 더 나은 병렬 처리, 중단 시간 감소 등을 허용하는 생성 단계와 로딩 단계를 분리했다는 것입니다.

8. Salesforce의 특정 기능에 유의하십시오.

다른 시스템과 마찬가지로 Salesforce에는 데이터 마이그레이션 중 불쾌한 놀라움을 피하기 위해 알아야 하는 까다로운 부분이 많이 있습니다. 다음은 몇 가지 예입니다.

• 활성 사용자에 대한 일부 변경 사항은 자동으로 사용자 이메일에 대한 이메일 알림을 생성합니다. 따라서 사용자 데이터로 플레이하려면 먼저 사용자를 비활성화하고 변경이 완료된 후 활성화해야 합니다. 테스트 환경에서는 알림이 전혀 실행되지 않도록 사용자 이메일을 스크램블합니다. 활성 사용자는 값비싼 라이선스를 소비하기 때문에 모든 테스트 환경에서 모든 사용자를 활성 상태로 만들 수는 없습니다. 예를 들어 교육 환경에 있는 사용자만 활성화하려면 활성 사용자의 하위 집합을 관리해야 합니다.
• 계정 또는 사례와 같은 일부 표준 개체의 비활성 사용자는 "비활성 소유자로 레코드 업데이트" 시스템 권한을 부여한 후에만 할당할 수 있지만 예를 들어 연락처 및 모든 사용자 정의 개체에 할당할 수 있습니다.
• 연락처가 비활성화되면 모든 옵트아웃 필드가 자동으로 켜집니다.
• 중복 계정 팀 구성원 또는 계정 공유 개체를 로드할 때 기존 레코드를 자동으로 덮어씁니다. 그러나 중복 Opportunity Partner를 로드할 때 레코드가 단순히 추가되어 중복이 됩니다.
• Created Date , Created By ID , Last Modified Date , Last Modified By ID 와 같은 시스템 필드는 "레코드 생성 시 감사 필드 설정"이라는 새 시스템 권한을 부여한 후에만 명시적으로 작성할 수 있습니다.
• 필드 기록 값 변경 사항은 전혀 마이그레이션할 수 없습니다.
• 지식 문서의 소유자는 로드 중에 지정할 수 없지만 나중에 업데이트할 수 있습니다.
• 까다로운 부분은 콘텐츠(문서, 첨부 파일)를 Salesforce에 저장하는 것입니다. 이를 수행하는 방법에는 여러 가지가 있으며(첨부 파일, 피드 첨부 파일, 문서 사용), 각 방법에는 서로 다른 파일 크기 제한을 포함하여 장단점이 있습니다.
• 선택 목록 필드는 사용자가 계정 유형과 같은 허용된 값 중 하나를 선택하도록 합니다. 그러나 Salesforce API(또는 Apex Data Loader 또는 Informatica Salesforce 커넥터와 같은 기반 도구)를 사용하여 데이터를 로드하면 모든 값이 전달됩니다.

목록은 계속 진행되지만 결론은 다음과 같습니다. 시스템에 익숙해지고 가정을 하기 전에 시스템이 할 수 있는 것과 할 수 없는 것을 배우십시오. 특히 핵심 개체에 대해 표준 동작을 가정하지 마십시오. 항상 연구하고 테스트합니다.

9. Salesforce를 데이터 마이그레이션 플랫폼으로 사용하지 마십시오.

특히 Salesforce 개발자를 위한 데이터 마이그레이션 솔루션을 구축하기 위한 플랫폼으로 Salesforce를 사용하고 싶은 유혹이 많습니다. Salesforce 애플리케이션 사용자 정의, 동일한 GUI, 동일한 Apex 프로그래밍 언어, 동일한 인프라와 같은 데이터 마이그레이션 솔루션에 대한 동일한 기술입니다. Salesforce에는 테이블 역할을 할 수 있는 개체와 일종의 SQL 언어인 SOQL(Salesforce Object Query Language)이 있습니다. 그러나 사용하지 마십시오. 그것은 근본적인 아키텍처 결함이 될 것입니다.

Salesforce는 고급 협업 및 풍부한 사용자 정의와 같은 멋진 기능이 많이 있는 우수한 SaaS 응용 프로그램이지만 데이터의 대량 처리는 그 중 하나가 아닙니다. 가장 중요한 세 가지 이유는 다음과 같습니다.

• 성능 – Salesforce의 데이터 처리는 RDBMS보다 몇 등급 느립니다.
• 분석 기능 부족 – Salesforce SOQL은 Apex 언어에서 지원해야 하는 복잡한 쿼리 및 분석 기능을 지원하지 않으며 성능이 훨씬 더 저하됩니다.
• 아키텍처 * – 데이터 마이그레이션 플랫폼을 특정 Salesforce 환경에 넣는 것은 그리 편리하지 않습니다. 일반적으로 특정 목적을 위한 여러 환경이 있으며 코드 동기화에 많은 시간을 할애할 수 있도록 임시로 생성하는 경우가 많습니다. 또한 특정 Salesforce 환경의 연결성과 가용성에 의존하게 될 것입니다.

대신 RDBMS 또는 ETL 플랫폼을 사용하여 별도의 인스턴스(클라우드 또는 온프레미스일 수 있음)에서 데이터 마이그레이션 솔루션을 구축하십시오. 이를 소스 시스템과 연결하고 원하는 Salesforce 환경을 대상으로 지정하고 필요한 데이터를 준비 영역으로 이동하고 그곳에서 처리합니다. 이를 통해 다음을 수행할 수 있습니다.

• SQL 언어 또는 ETL 기능의 모든 기능과 기능을 활용하십시오.
• 모든 시스템에서 분석을 실행할 수 있도록 모든 코드와 데이터를 한 곳에 보관하십시오.
  • 예를 들어, 최신 테스트 Salesforce 환경의 최신 구성을 프로덕션 Salesforce 환경의 실제 데이터와 결합할 수 있습니다.
• 소스 및 대상 시스템의 기술에 크게 의존하지 않으며 다음 프로젝트를 위해 솔루션을 재사용할 수 있습니다.

10. Salesforce 메타데이터 감독

프로젝트를 시작할 때 일반적으로 Salesforce 필드 목록을 가져와 매핑 연습을 시작합니다. 프로젝트 중에 응용 프로그램 개발 팀이 Salesforce에 새 필드를 추가하거나 일부 필드 속성이 변경되는 경우가 종종 있습니다. 애플리케이션 팀에 모든 데이터 모델 변경 사항에 대해 데이터 마이그레이션 팀에 알리도록 요청할 수 있지만 항상 작동하지는 않습니다. 안전하려면 감독하에 모든 데이터 모델 변경 사항이 있어야 합니다.

이를 수행하는 일반적인 방법은 정기적으로 Salesforce에서 일부 메타데이터 저장소로 마이그레이션 관련 메타데이터를 다운로드하는 것입니다. 일단 이것이 있으면 데이터 모델의 변경 사항을 감지할 수 있을 뿐만 아니라 두 Salesforce 환경의 데이터 모델을 비교할 수도 있습니다.

다운로드할 메타데이터:

• 레이블, 기술 이름 및 속성(예: creatable 가능 또는 updatable )이 있는 개체 목록입니다.
• 속성이 있는 필드 목록(모두 가져오는 것이 좋습니다).
• 선택 목록 필드의 선택 목록 값 목록입니다. 올바른 값에 대한 입력 데이터를 매핑하거나 검증하는 데 필요합니다.
• 새 유효성 검사가 마이그레이션된 데이터에 문제를 일으키지 않는지 확인하기 위한 유효성 검사 목록입니다.

Salesforce에서 메타데이터를 다운로드하는 방법은 무엇입니까? 표준 메타데이터 방법은 없지만 여러 옵션이 있습니다.

• 엔터프라이즈 WSDL 생성 – Salesforce 웹 응용 프로그램에서 Setup / API 메뉴로 이동하고 Salesforce의 모든 개체와 필드를 설명하는 강력한 유형의 엔터프라이즈 WSDL을 다운로드합니다(선택 목록 값이나 유효성 검사 제외).
• 직접 또는 Java 또는 C# 래퍼를 사용하여 Salesforce describeSObjects 웹 서비스를 호출합니다(Salesforce API 참조). 이렇게 하면 필요한 것을 얻을 수 있으며 메타데이터를 내보내는 데 권장되는 방법입니다.
• 인터넷에서 사용할 수 있는 수많은 대체 도구를 사용하십시오.

다음 데이터 마이그레이션 준비

Salesforce와 같은 클라우드 솔루션은 즉시 준비됩니다. 내장된 기능에 만족하신다면 로그인하여 사용하시면 됩니다. 그러나 Salesforce는 다른 클라우드 CRM 솔루션과 마찬가지로 특히 성능 및 리소스 제한과 관련하여 인식해야 하는 데이터 마이그레이션 주제에 대한 특정 문제를 제공합니다.

레거시 데이터를 새 시스템으로 이동하는 것은 항상 여정이며 때로는 과거 데이터에 숨겨진 역사로의 여정입니다. 이 기사에서는 12개의 마이그레이션 프로젝트를 기반으로 레거시 데이터를 마이그레이션하고 대부분의 위험을 성공적으로 피하는 방법에 대한 10가지 팁을 제시했습니다.

핵심은 데이터가 나타내는 내용을 이해하는 것입니다. 따라서 데이터 마이그레이션을 시작하기 전에 Salesforce 개발 팀이 데이터에 있을 수 있는 잠재적인 문제에 대해 잘 준비되어 있는지 확인하십시오.