Redate.io

BitTitan MigrationWiz: 이메일 날짜 오류 수정

5 min

BitTitan MigrationWiz가 이메일 날짜에 미치는 영향

금요일에 마이그레이션이 완료되었어요. 47개의 메일함이 온프레미스 Exchange에서 Microsoft 365로 이전되었고, MigrationWiz 대시보드에서는 모두 녹색이에요. 그런데 월요일 아침, 첫 번째 티켓이 들어와요. "모든 이메일이 2026년 3월 28일로 표시돼요."

모든 메시지가 그래요. 수년간의 업무 서신, 2019년 고객 제안서, 2021년 청구서까지 전부 마이그레이션 날짜로 표시돼요. MigrationWiz 로그에는 모든 항목이 성공적으로 전송되었다고 나와요 (기술적으로는 맞아요). 하지만 날짜가 사라졌어요.

BitTitan MigrationWiz는 클라우드 간 이메일 마이그레이션에 가장 널리 사용되는 도구 중 하나예요. Exchange에서 Microsoft 365로, Google Workspace에서 Exchange로, 테넌트 간 이동까지 다양한 마이그레이션을 처리해요. 도구 자체는 설계된 목적대로 잘 작동해요. 날짜 문제는 MigrationWiz의 버그가 아니에요. IMAP 프로토콜 수준에서 마이그레이션이 작동하는 방식의 결과이며, MigrationWiz가 이를 특정 방식으로 트리거하는 거예요.

MigrationWiz의 Received 헤더 처리 방식

MigrationWiz가 소스에서 대상으로 이메일을 전송할 때 IMAP 프로토콜(또는 엔드포인트 유형에 따라 Exchange Web Services)을 사용해요. 이 과정에서 대상 메일 서버는 현재 타임스탬프가 포함된 새로운 Received: 헤더를 메시지에 추가해요. 수신 이메일에 대해 수행하는 것과 동일한 처리예요.

MigrationWiz 마이그레이션 이후의 일반적인 Received 헤더 체인은 다음과 같아요.

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

2019년의 원본 Received: 헤더는 여전히 남아 있어요. 원본 Date: 헤더도 마찬가지예요. 하지만 Outlook 같은 이메일 클라이언트는 이것들을 사용하지 않아요. Outlook은 메시지 표시 시점을 결정하기 위해 가장 최근의 Received: 헤더를 읽는데, 그 헤더는 이제 2026년 3월 28일을 가리키고 있어요.

INTERNALDATE 값(IMAP 서버가 정렬에 사용하는 타임스탬프)도 전송 중에 덮어씌워져요. MigrationWiz는 대상 서버가 지원할 때 날짜를 보존하려고 시도하지만, 결과는 대상 서버의 동작에 크게 좌우돼요. 사실 Microsoft 365의 전송 파이프라인은 MigrationWiz의 요청과 관계없이 INTERNALDATE를 자체 배달 타임스탬프로 덮어씌워요.

MigrationWiz 날짜 매핑이 작동하지 않는 이유

BitTitan은 MigrationWiz 고급 옵션에서 "Date Mapping" 기능을 제공해요. 문서상으로는 해결책처럼 보여요. 그런데 실제로는? 마이그레이션할 메시지의 날짜 범위를 제어하는 것이지, 대상에서 날짜가 어떻게 보존되는지를 제어하는 게 아니에요.

혼동은 이해할 수 있어요. 설정 이름에 "날짜"라고 적혀 있으니까요. 하지만 실제로 하는 일은 마이그레이션 전에 소스 메시지를 날짜 범위로 필터링하는 거예요. 2018년 메시지도 마이그레이션 타임스탬프로 대상에 도착해요.

IMAP 대 Exchange 엔드포인트 문제도 있어요. MigrationWiz가 EWS(Exchange Web Services)를 사용하여 두 Exchange 서버 간에 마이그레이션할 때는 EWS가 메시지 메타데이터에 대한 제어가 더 크기 때문에 날짜 보존이 더 잘 작동해요. 하지만 소스든 대상이든 어느 쪽이든 IMAP이 관여하는 순간, IMAP APPEND 작업이 인계받고 대상 서버가 어떤 타임스탬프를 사용할지 결정해요.

일부 관리자는 다른 엔드포인트 구성으로 마이그레이션을 다시 실행해 봤어요. IMAP에서 EWS로 전환하면 날짜가 소급 수정될 거라고 기대하면서요. 수정되지 않아요. 메시지는 이미 잘못된 날짜로 대상에 있어요. MigrationWiz를 다시 실행하면 중복만 생겨요.

날짜를 깨뜨리는 MigrationWiz 시나리오

모든 MigrationWiz 마이그레이션이 날짜 문제를 일으키는 건 아니에요. 문제는 엔드포인트 조합에 따라 달라요.

  • Exchange(온프레미스)에서 Microsoft 365로 IMAP 경유: 날짜가 깨져요. M365 전송 파이프라인이 새 Received 헤더를 추가하고 INTERNALDATE를 덮어씌워요.
  • Google Workspace에서 Microsoft 365로: 날짜가 깨져요. MigrationWiz가 Google에서 IMAP으로 읽고 전송 헤더를 추가하는 M365에 기록해요.
  • Exchange에서 Exchange로 (EWS에서 EWS): 날짜는 보통 보존돼요. EWS가 양쪽에서 전송 파이프라인을 우회해요.
  • 어디에서든 Google Workspace로 IMAP 경유: 날짜가 깨져요. Google의 IMAP 구현이 삽입 타임스탬프가 포함된 Received 헤더를 추가해요.
  • 테넌트 간 Microsoft 365 마이그레이션: 방법에 따라 달라요. IMAP 경로는 날짜를 깨뜨려요. 직접 EWS는 보존할 수 있어요.

MigrationWiz 대시보드는 날짜 문제를 표시하지 않아요. 메시지가 실제로 성공적으로 전송되었기 때문에 모든 항목이 "Completed"로 표시돼요. 콘텐츠는 온전하고, 첨부파일도 정상이고, 폴더 구조도 보존돼 있어요. 변경된 건 날짜뿐이고, MigrationWiz는 이것을 마이그레이션 오류로 추적하지 않아요.

MigrationWiz 이후 잘못된 날짜의 실제 비용

잘못된 이메일 날짜는 단순히 불편한 게 아니에요. BitTitan으로 마이그레이션한 조직에게 그 영향은 지저분한 받은편지함을 넘어서요.

법무팀은 모든 메시지가 실제 발송 날짜가 아닌 마이그레이션 날짜를 표시할 때 이메일을 증거로 사용할 수 없어요. 세무 감사에는 커뮤니케이션의 시간순 증거가 필요해요. SOX, HIPAA, GDPR 같은 컴플라이언스 프레임워크는 정확한 기록 관리를 의무화하고 있으며, 위조된 타임스탬프가 있는 이메일은 이 요건을 충족하지 못해요.

그리고 실무적인 문제도 있어요. 전체 메일함이 2026년 3월을 표시하는 상태에서 2022년 11월의 계약 관련 논의를 찾아보세요. 날짜순 정렬? 쓸모없어요. 날짜 범위 검색? 전부 나오거나 아무것도 안 나오거나 둘 중 하나예요.

클라이언트 환경에서 MigrationWiz를 사용한 MSP에게 이것은 책임 문제를 만들어요. 클라이언트는 마이그레이션 비용을 지불했어요. 마이그레이션은 완료되었지만, 이메일 아카이브는 날짜 기반 워크플로에 대해 사실상 사용할 수 없게 되었어요.

한 로펌의 메일함 약 380개를 마이그레이션한 MSP 사례를 들었어요. 3개월 후, 그 로펌의 소송팀이 문서 디스커버리 과정에서 날짜 문제를 발견했어요. 증거로 제출해야 하는 모든 이메일이 마이그레이션 날짜를 표시하고 있었어요. MSP는 6년치 타임스탬프가 찍힌 서신이 왜 모두 2025년 6월을 표시하는지 설명해야 했어요.

BitTitan MigrationWiz 날짜 수정하기

원본 Date: 헤더는 여전히 모든 이메일 안에 있어요. MigrationWiz는 메시지 본문이나 원본 헤더를 건드리지 않아요. 추가된 Received: 헤더와 덮어씌워진 INTERNALDATE가 표시 문제를 일으키는 거예요.

Redate.io는 메일함(Google Workspace, Microsoft 365 또는 IMAP)에 연결하여 MigrationWiz 마이그레이션의 영향을 받은 이메일을 스캔하고, 독자적인 다단계 분석 파이프라인을 통해 날짜 메타데이터를 수정해요. 수정은 메타데이터 계층을 대상으로 하며, Received 체인 내의 mx.migrationwiz.com 및 bittitan.com 식별자를 포함한 알려진 MigrationWiz 헤더 시그니처와의 패턴 매칭을 수행해요.

수정된 모든 이메일은 원본과 개별적으로 검증돼요. 검증에서는 메시지 무결성, 첨부파일 보존, 폴더 배치, 스레드 동작을 확인해요. 원본 이메일은 롤백이 필요할 경우를 대비하여 Redate.io - Originals 폴더에 30일간 보관돼요.

문제를 이해하는 것과 15,000통의 이메일을 첨부파일 손실, S/MIME 서명 손상, 멀티파트 MIME 경계 훼손 없이 수정하는 것은 완전히 다른 문제예요. 실험실에서 10개의 테스트 메시지로 작동하는 스크립트로는 7년간의 서신, PGP 암호화 메시지, RFC 2047 비ASCII 헤더가 있는 운영 메일함의 엣지 케이스를 처리할 수 없어요.

수정된 각 메시지가 온전한지 어떻게 확인하나요? 스레드가 여전히 작동하는지, 캘린더 초대가 여전히 처리되는지, 2020년 그 이메일의 47MB 첨부파일이 손상되지 않았는지? Redate.io는 모든 메시지에 대해 이것을 자동으로 수행해요. 그리고 무언가 이상하면 원본이 백업 폴더에 바로 있어요.

무료 스캔은 약 2분 정도 걸려요. 메일함에 연결하여 MigrationWiz 마이그레이션 날짜 타임스탬프가 있는 모든 이메일을 식별하고, 결제 전에 정확한 수량과 비용을 보여줘요. 신용카드 불필요, 약정 없음.

BitTitan 사용자를 위한 플랫폼별 수정 가이드

수정 프로세스는 MigrationWiz가 이메일을 이전한 대상에 따라 달라요. Redate.io는 각 플랫폼의 특성을 자동으로 처리하지만, 특정 환경에 대한 세부 정보가 필요하면 아래를 참조하세요.

Redate.io는 몇 달 또는 몇 년 전에 완료된 마이그레이션에도 작동해요. 원본 Date 헤더에는 만료 기한이 없어요.

BitTitan MigrationWiz로 마이그레이션했는데 날짜가 잘못된 상태인가요? 무료 스캔을 실행해서 어떤 결정을 내리기 전에 영향받은 이메일이 정확히 몇 통인지 확인해 보세요.

관련 기사

Exchange Online 마이그레이션 후 이메일 날짜 오류

EAC를 통해 Exchange Online으로 IMAP 마이그레이션을 완료했는데 이메일 날짜가 전부 깨졌나요? 원인과 올바른 해결 방법을 알아보세요.

GSMMO 마이그레이션 후 이메일 날짜 오류 수정 방법

GSMMO는 PST와 Outlook 데이터를 Google Workspace로 마이그레이션할 때 이메일 날짜를 변경해요. 원인과 올바른 날짜 복원 방법을 알아보세요.

Exchange IMAP 가져오기: 이메일 날짜가 틀리는 이유

EAC나 PowerShell을 통한 Exchange IMAP 가져오기가 이메일 날짜를 덮어써요. Exchange 전송 파이프라인이 원인인 이유와 수정 방법을 알아보세요.