아니요. 데이터 건수가 같아도 고객과 주문의 연결, 재고 수량, 취소 상태가 바뀌면 업무는 다르게 작동합니다. 이전 완료의 기준은 파일 업로드 성공이 아니라, 합의한 기준 시점의 데이터가 새 시스템에서도 같은 업무 의미로 쓰이는지입니다.
핵심 요약: 먼저 대상과 기준 시점을 고정하고, 건수·식별자·업무 합계·참조 관계·대표 흐름을 나눠 확인하세요. 차이는 별도 목록으로 관리하고, 승인자와 중단 조건을 정한 뒤 전환합니다. 아래 기준은 ERP 교체뿐 아니라 엑셀에서 CRM·재고 시스템으로 옮기는 작업에도 조정해 사용할 수 있습니다.
[01]무엇을 언제 기준으로 비교할지 정하세요
‘전체 데이터를 옮긴다’는 문장부터 구체화하세요. 고객 마스터, 미완료 주문, 재고 잔량, 과거 이력, 첨부파일의 포함 범위를 나눕니다. 고객명 대신 유지할 고유 ID를 정하고, 여러 원본을 합친다면 원본 시스템과 기존 ID를 함께 추적할 매핑표를 준비하세요.
- 비교 기준: 추출 시각, 시간대, 조회 조건, 포함·제외 상태를 기록합니다.
- 변환 규칙: 날짜·통화·단위, 빈 값과 0의 구분, 상태 코드, 반올림 위치를 정합니다.
- 비교 책임: 원본 추출자, 변환 담당자, 업무 검수자와 최종 승인자를 지정합니다.
원본은 계속 바뀌는데 대상은 어제 추출한 데이터라면 차이가 나도 원인을 판단하기 어렵습니다. AWS DMS도 전체 적재와 변경 데이터 검증을 구분하고, 검증 대기·실패·비교 불가 상태를 제공합니다. 검증은 별도 시간과 부하가 필요하므로 이전 일정에 포함해야 합니다.
[02]건수와 업무 의미를 나눠 검수하세요
다음 표는 보이드가 제안하는 검수표의 시작점입니다. 모든 테이블에 같은 합계를 적용하지 말고, 업무 담당자가 실제로 대조할 수 있는 기준을 선택하세요. 요약 합계가 같아도 개별 행의 차이가 상쇄될 수 있으므로 중요한 레코드는 식별자로 연결해 필드 수준까지 확인합니다.
| 검수 축 | 대조할 내용 | 차이가 날 때 확인할 것 |
|---|---|---|
| 범위·건수 | 상태·기간·사업장별 대상 건수 | 누락·중복·필터·제외 대상 |
| 식별자 | 기존 ID와 새 ID의 대응 및 필수 값 | 중복 코드·빈 키·매핑 누락 |
| 업무 합계 | 통화별 주문 금액·품목/창고별 재고 수량 | 단위·세금 포함 여부·취소·반올림 규칙 |
| 참조 관계 | 주문→고객·주문행→품목·이력→담당자 | 삭제된 마스터·바뀐 코드·누락된 연결 |
| 업무 흐름 | 조회·부분 출고·취소·승인·첨부 열기 | 화면 상태와 저장 데이터의 불일치 |
AWS DMS의 행 대조는 원본과 대상 레코드의 불일치를 찾는 기능입니다. 이것만으로 새 ERP의 할인 규칙, 승인 흐름, 화면 권한까지 검수되는 것은 아닙니다. 데이터 비교 결과와 업무 시나리오 결과를 별도 인도물로 요청하세요.
[03]관계와 예외를 숫자 뒤에 숨기지 마세요
PostgreSQL에서 기본 키는 행을 구별하며 고유하고 NULL일 수 없습니다. 외래 키는 다른 테이블에 대응 레코드가 있는지 확인해 참조 무결성을 유지합니다. 이런 제약은 중요한 방어선이지만 업무상 올바른 고객에 주문이 연결됐는지까지 자동으로 판단하지는 않습니다.
가상 예시입니다. 주문 두 건의 고객 ID를 서로 바꿔 넣으면 주문 건수와 총액은 그대로일 수 있습니다. 두 고객 ID가 모두 존재하면 외래 키 검사도 통과할 수 있습니다. 그래서 기존 주문 ID를 기준으로 고객·상태·금액을 함께 대조해야 합니다. 이는 설명용 예시이며 실제 고객 사고 사례가 아닙니다.
- 부분 출고·취소·반품·비활성 고객·이름이 같은 고객처럼 예외가 있는 샘플을 포함합니다.
- 차이 목록에는 원본 ID, 새 ID, 기대 값, 실제 값, 원인, 담당자와 재검증 결과를 남깁니다.
- 검증 대기·비교 불가 항목을 정상 처리로 묶지 말고 승인 전에 별도 판단합니다.
[04]전환 조건과 복귀 시 데이터 처리를 먼저 정하세요
AWS의 전환 사전 지침은 작업 순서·담당자·예정 시간을 실행 문서로 정리하고 전환을 리허설하도록 안내합니다. 실제 ERP 프로젝트에서는 여기에 기준 데이터 추출, 마지막 변경분 반영, 검수, 업무 책임자 승인, 새 시스템 입력 시작을 각각 적어 두는 방식을 제안합니다.
복귀는 주소만 예전으로 돌리는 문제가 아닙니다. AWS 지침도 전환 후 새 데이터가 생긴 경우 이를 어떻게 보존·반영할지 고려하도록 설명합니다. 새 시스템에서 접수한 주문과 수정한 재고를 누가 어떤 절차로 옛 시스템에 반영할지 정하지 않은 채 전환하면, 시스템은 돌아와도 업무 데이터는 어긋날 수 있습니다.
- 진행 조건: 합의한 검수 항목의 결과와 예외 처리를 승인자가 확인합니다.
- 중단 조건: 핵심 데이터 불일치·주요 업무 실패 등 멈출 조건과 판단 시한을 정합니다.
- 복귀 조건: 백업 위치만 적지 말고 복원 리허설, 변경 데이터 보존, 재대조 책임을 확인합니다.
[05]견적·검수 인도물에 포함할 체크리스트
‘데이터 이전 포함’이라는 견적 문구를 아래 결과물로 구체화하세요. 허용 오차는 모든 데이터에 일괄 적용하지 말고 실제 업무 규칙에 따라 근거와 승인자를 적습니다. 의도적으로 제외하거나 통합한 레코드는 실패를 숨기지 않도록 제외 사유와 매핑에 남깁니다.
- 대상·제외 범위, 기준 시점, 변환 규칙과 ID 매핑표
- 건수·업무 합계·필드·관계 검수 결과와 미해결 차이 목록
- 대표·예외 업무 시나리오의 기대 결과와 실제 결과
- 전환 순서·담당자·승인 기록·중단 및 복귀 절차
- 전환 후 문의 창구, 재검증 일정과 운영팀 인계 문서
첫 상담에서는 현재 엑셀·ERP의 비식별 샘플과 업무 흐름 하나를 준비하면 충분한 출발점이 됩니다. 먼저 어떤 데이터를 왜 옮길지 합의하고, 필요한 검수와 연동을 함께 범위에 넣으세요. 이 글의 체크리스트는 프로젝트에 맞게 조정하는 출발점이며 모든 시스템의 완전성을 보증하는 기준은 아닙니다.
- 데이터 이전
- ERP 검수
- 데이터 대조
- 전환 계획
