Salesforce 데이터 마이그레이션의 성패는 첫 적재 전에 갈립니다. 적재 도구는 이미 있고 제 역할을 합니다. 대개 빠져 있는 쪽은 결정입니다. 객체마다 누가 책임지는지, 어떤 건수 대조로 누락이 없음을 입증하는지, 실제 컷오버 전에 리허설을 몇 번 하는지, 진행과 롤백을 누가 선언하는지가 정해지지 않은 채 일정이 시작됩니다.
‘데이터 손실 제로’는 많은 요구사항 문서에 들어갑니다. 이 표현이 무엇을 포함하고 누가 확인하는지 문서로 정하기 전에는 인수 기준으로 쓸 수 없습니다.
세 가지 손실, 세 가지 증거
물리적 손실이 가장 단순합니다. 소스에 있는 레코드가 타깃에 없는 경우입니다. 객체별로 소스와 타깃 건수를 대조하면 드러납니다.
의미 손실은 건수 대조를 통과합니다. 레코드는 있지만 뜻이 바뀐 경우입니다. Status 값이 잘못 매핑되거나, 부모-자식 관계가 뒤집히거나, 통화가 잘못 환산됩니다. 업무를 아는 사람이 경계 사례 위주로 고른 샘플을 봐야 찾아낼 수 있습니다.
맥락 손실은 두 검사를 모두 통과합니다. 값은 맞지만 원래 소유자, 생성일, 변경 이력이 적재 과정에서 덮어써진 경우입니다. 개인정보라면 데이터 품질만으로 판단할 수 없는 규제 문제이기도 합니다.
손실마다 필요한 증거와 서명자가 다릅니다. 건수 대조만 내놓는 프로그램은 첫 번째 손실만 다루고 나머지 둘은 운영 환경으로 넘긴 셈입니다.
첫 적재 전에 객체마다 책임자를 정합니다
책임 소재가 다른 모든 결정보다 먼저입니다. 이관 대상 객체(Account, Contact, Opportunity, Case, 커스텀 객체)마다 현업 담당자 한 명이 변환 규칙, 고아 레코드 처리, 레코드를 확실하게 식별하는 키를 책임집니다.
변환 규칙은 프로젝트 팀이 제안할 수 있습니다. 승인은 상태 값이나 계정 유형이 업무에서 무슨 뜻인지 아는 사람이 해야 합니다. 규칙이 컨설턴트 한 명의 머릿속이나 아무도 검토하지 않은 스크립트에만 있으면 의미 손실이 생기기 쉽습니다.
고아 레코드(계정 없는 연락처, 담당자가 퇴사한 영업 기회, 삭제된 레코드에 연결된 작업)는 그대로 이관할 수 없습니다. 보관할지, 삭제할지, 공용 레코드에 연결할지는 업무 결정이고 시간이 걸립니다. 적재 도중에 결정하려 하면 일정이 멈춥니다.
Salesforce 레코드 ID는 org 사이에서 그대로 옮겨지지 않습니다. 레코드 간 관계는 고객 번호, 제품 코드, 계약 번호 같은 업무 키로 다시 연결합니다. 소스에 이런 키가 없거나 믿기 어렵다면 정제 작업이 먼저이고, 어떤 키를 기준으로 삼을지는 객체 책임자가 정합니다.
Sanofi 프로그램(Cognizant 고객사, 2021-2022)에서는 여섯 개 시스템을 하나의 Salesforce org로 이관했습니다. 통제 모델은 명시적인 소스-타깃 매핑, 매핑과 검사에 쓰는 재사용 템플릿, 정합성 통제, 인수 전에 차이를 드러내는 중단 조건으로 이루어졌습니다. 소스가 여섯 개이면 ‘이 고객은 어느 소스를 기준으로 삼는가’라는 질문에 적재 전에 답해야 합니다. 도구가 대신 답해 주지 않습니다.
정합성 보고서에는 서명이 필요합니다
아무도 서명하지 않은 정합성 보고서는 기술 문서에 그칩니다. 프로그램은 배치마다 객체별 소스·타깃 건수, 거부 건과 사유, 승인된 예외를 보고합니다. 이 보고서에 서명하는 사람은 데이터를 적재한 팀이 아니라 해당 객체의 현업 책임자입니다.
허용 오류 기준은 프로젝트 시작 전에 객체별로 정하고, 비율이 아닌 레코드 건수로 적습니다. 대량 데이터에서는 작아 보이는 비율도 수천 건이 되고, 한 건마다 고객이나 계약이 걸려 있습니다.
의미 검사에는 기준 데이터 세트가 필요합니다. 복잡한 관계, 다중 선택 필드, 긴 이력 같은 경계 사례가 들어가도록 현업과 함께 고른 대표 레코드입니다. 리허설이 끝날 때마다 현업 검토자가 직접 확인합니다. 의미 손실만큼은 자동 통제가 이 확인을 대신하지 못합니다.
데이터만 문제가 되지도 않습니다. 정상 적재된 Account가, 타깃에서 이름이 바뀐 레코드 유형 때문에 실패하는 Flow를 실행할 수 있습니다. 이관 객체를 건드리는 자동화, 유효성 규칙, 프로필, 연동도 테스트 범위에 넣어야 합니다. 이런 의존성이 쌓이는 과정은 Salesforce 기술 부채 노트에서 다룹니다.
리허설, 동결, 결정
컷오버는 리허설합니다. 실제에 가까운 데이터 양으로 운영과 비슷한 환경에서 전체 리허설을 하면, 계획서로는 알 수 없는 실제 적재 시간과 현업 검토자의 확인 시간을 얻습니다. 이 소요 시간으로 컷오버 시간대를 정합니다.
이관 기간에는 소스를 읽기 전용으로 두거나, 모든 변경을 기록해 두었다가 타깃에 다시 반영합니다. 동결도 델타 반영도 없으면 이관한 데이터는 다음 날 아침에 이미 낡은 데이터가 됩니다. 입력을 멈추는 쪽이 현업이므로 동결 날짜도 현업이 정합니다.
롤백은 미리 정합니다. 적재가 중간에 실패하면 원래 상태로 어떻게 돌아가는지 계획에 적고, sandbox에서 시험해 둡니다. 결정 시점도 함께 정합니다. 컷오버 시간대 안에서 롤백이 더 이상 불가능해지는 시각과, 그 시각 전에 롤백을 강제하는 기준입니다.
남는 문제는 진행 결정입니다. 서명된 보고서를 근거로 스폰서나 프로그램 책임자가 결정하며, 일정표를 근거로 SI가 결정하지 않습니다. 최종 리허설 전까지 그 이름이 문서에 없으면, 결정은 새벽 두 시에 회의실에서 가장 지친 사람이 내리게 됩니다.
확인할 항목
- 이관 객체마다 변환 규칙과 고아 레코드 처리를 승인하는 현업 책임자가 지정되어 있습니다.
- ‘데이터 손실 제로’의 범위가 문서로 정해져 있습니다. 고아 레코드, 활동 이력, 첨부 파일, 암호화 필드의 포함 여부까지 적혀 있습니다.
- 오류 기준을 첫 적재 전에 객체별로, 레코드 건수로 정했습니다.
- 전체 리허설을 마쳤고, 그 소요 시간으로 컷오버 시간대를 정했습니다.
- 롤백 계획을 시험했고, 롤백 마감 시각이 컷오버 계획에 들어 있습니다.
- 진행을 선언할 사람의 이름이 문서에 있습니다.