BitTitan MigrationWiz: исправление дат писем

Что BitTitan MigrationWiz делает с датами писем

Миграция завершилась в пятницу. 47 почтовых ящиков перенесены с локального Exchange на Microsoft 365, в панели MigrationWiz все зеленое. А в понедельник утром приходит первая заявка: "Все мои письма показывают 28 марта 2026 года".

Каждое письмо. Годы переписки, клиентские предложения 2019 года, счета 2021 года, на всех стоит дата миграции. Лог MigrationWiz говорит, что все перенесено успешно (технически так и есть). Но даты пропали.

BitTitan MigrationWiz - один из самых распространенных инструментов для облачной миграции электронной почты. Он работает с Exchange на Microsoft 365, Google Workspace на Exchange, межтенантными переносами и другими сценариями. Сам инструмент хорошо справляется со своей задачей. Проблема с датами - это не баг MigrationWiz. Это следствие того, как работает миграция по протоколу IMAP, и MigrationWiz запускает этот механизм определенным образом.

Проблема обнаруживается не сразу. Во время миграции никаких предупреждений нет, все статусы зеленые. И только когда пользователи начинают жаловаться на сортировку писем или не могут найти нужную переписку по дате, масштаб становится очевиден.

Как MigrationWiz обрабатывает заголовки Received

Когда MigrationWiz переносит письмо с источника на приемник, используется протокол IMAP (или Exchange Web Services, в зависимости от типа конечной точки). В процессе целевой почтовый сервер ставит на сообщение новый заголовок Received: с текущей меткой времени, точно так же, как он поступил бы с любым входящим письмом.

Типичная цепочка заголовков Received после миграции MigrationWiz выглядит так:

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

Оригинальный заголовок Received: от 2019 года на месте. Оригинальный заголовок Date: тоже. Но почтовые клиенты вроде Outlook их не используют. Outlook читает самый свежий заголовок Received:, чтобы определить дату отображения сообщения, а он теперь говорит: 28 марта 2026 года.

Значение INTERNALDATE (метка времени, которую IMAP-серверы используют для сортировки) тоже перезаписывается при переносе. MigrationWiz пытается сохранить даты, когда целевой сервер это поддерживает, но результат сильно зависит от поведения целевого сервера. Транспортный конвейер Microsoft 365, к примеру, перезаписывает INTERNALDATE собственной меткой доставки независимо от того, что запрашивает MigrationWiz.

Почему Date Mapping в MigrationWiz не спасает

BitTitan предлагает функцию "Date Mapping" в расширенных настройках MigrationWiz. На бумаге звучит как решение. На самом деле? Эта настройка контролирует, за какой диапазон дат мигрировать сообщения, а не как даты сохраняются на приемнике.

Путаница понятна. В названии настройки есть слово "date". Но фактически она фильтрует исходные сообщения по диапазону дат перед миграцией. Письмо 2018 года все равно попадает на приемник с меткой времени миграции.

Есть ещё вопрос IMAP против Exchange. Когда MigrationWiz мигрирует между двумя серверами Exchange через EWS (Exchange Web Services), сохранение дат работает лучше, потому что 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: Даты ломаются. Реализация IMAP от Google добавляет заголовок Received с меткой времени вставки.
• Межтенантный Microsoft 365: Зависит от метода. IMAP-путь ломает даты. Прямой EWS может сохранить.

Панель MigrationWiz не отмечает проблемы с датами. Все отображается как "Completed", потому что сообщения действительно перенесены успешно. Содержимое цело, вложения на месте, структура папок сохранена. Изменились только даты, и MigrationWiz не отслеживает это как ошибку миграции.

Реальная цена неправильных дат после MigrationWiz

Неправильные даты писем - это не просто неудобство. Для организаций, мигрировавших с BitTitan, последствия выходят далеко за рамки беспорядка во входящих.

Юридические отделы не могут использовать письма в качестве доказательств, когда каждое сообщение показывает дату миграции вместо реальной даты отправки. Налоговые проверки требуют хронологического подтверждения переписки. Регуляторные рамки вроде Федерального закона о персональных данных и GDPR обязывают вести точный учет записей, а письма с поддельными метками времени этому требованию не соответствуют.

Есть и практическая сторона. Попробуйте найти обсуждение договора от ноября 2022 года, когда весь почтовый ящик показывает март 2026. Сортировка по дате? Бесполезна. Поиск по диапазону дат? Возвращает все или ничего.

Для MSP, использовавших MigrationWiz в клиентских средах, это создает проблему ответственности. Клиент заплатил за миграцию. Он её получил, но его почтовый архив фактически сломан для рабочих процессов, зависящих от дат.

Один MSP, о котором нам стало известно, перенес около 380 почтовых ящиков для юридической фирмы. Через три месяца команда фирмы по судебным разбирательствам обнаружила проблему с датами во время раскрытия документов. Каждое письмо, которое нужно было представить как доказательство, показывало дату миграции. MSP пришлось объяснять, почему 6 лет переписки с метками времени теперь показывают июнь 2025 года. Кстати, подобные ситуации происходят не так редко, как может показаться: большинство администраторов обнаруживают проблему лишь спустя недели после миграции.

Исправление дат BitTitan MigrationWiz

Оригинальный заголовок Date: по-прежнему находится внутри каждого письма. MigrationWiz не трогает тело сообщения и оригинальные заголовки. Проблему отображения вызывают добавленный заголовок Received: и перезаписанное значение INTERNALDATE.

Redate.io подключается к почтовому ящику (Google Workspace, Microsoft 365 или IMAP), сканирует письма, затронутые миграцией MigrationWiz, и исправляет метаданные дат через проприетарный многоступенчатый аналитический конвейер. Исправление нацелено именно на слой метаданных, с сопоставлением паттернов известных сигнатур заголовков MigrationWiz, включая характерные идентификаторы mx.migrationwiz.com и bittitan.com в цепочке Received.

Каждое исправленное письмо индивидуально верифицируется в сравнении с оригиналом. Проверка охватывает целостность сообщения, сохранность вложений, размещение в папках и цепочки ответов. Оригинальные письма хранятся в видимой папке Redate.io - Originals в течение 30 дней на случай необходимости отката.

Понять проблему - это одно. Исправить 15 000 писем, не потеряв ни одного вложения, не сломав подписи S/MIME и не повредив multipart MIME boundaries - совсем другое. Скрипт, работающий на 10 тестовых сообщениях в лаборатории, не справится с крайними случаями рабочего почтового ящика с 7-летней перепиской, PGP-шифрованными сообщениями и заголовками RFC 2047 с не-ASCII символами.

Как Вы убедитесь, что каждое исправленное сообщение не повреждено? Что цепочки ответов работают, что приглашения в календарь по-прежнему распознаются, что вложение на 47 МБ из того письма 2020 года не испортилось? Redate.io делает это автоматически, для каждого отдельного сообщения. А если что-то выглядит подозрительно, оригинал находится прямо в папке резервных копий.

Бесплатное сканирование занимает около двух минут. Подключение к ящику, обнаружение каждого письма с меткой даты миграции MigrationWiz, точное количество и стоимость - до того, как Вы что-либо оплатите. Без кредитной карты, без обязательств.

Руководства по исправлению для конкретных платформ

Процесс исправления зависит от того, куда MigrationWiz перенес Вашу почту. Redate.io автоматически учитывает особенности каждой платформы, но если Вам нужны детали по Вашей конфигурации:

• Исправить даты BitTitan в Outlook
• Исправить даты BitTitan в Microsoft 365
• Исправить даты BitTitan в Google Workspace
• Исправить даты BitTitan в Exchange Online

Redate.io работает и для миграций, завершенных месяцы или годы назад. Оригинальный заголовок Date не имеет срока давности.

Выполнили миграцию с BitTitan MigrationWiz и застряли с неправильными датами? Запустите бесплатное сканирование, чтобы увидеть, сколько писем затронуто, прежде чем принимать какие-либо решения.