Почему чек-лист миграции необходим
Миграция почты - одна из самых рискованных IT-операций для организации. Перемещаются годы деловой переписки между платформами, и одно упущение может повредить метаданные всех ящиков. Самая частая жертва? Даты писем. После миграции каждое письмо рискует показывать дату миграции вместо исходной даты.
Этот чек-лист покрывает каждую фазу процесса миграции. Следуйте этим шагам для минимизации риска искажения дат и других проблем с метаданными. А если миграция уже завершена и проблемы с датами обнаружены, продолжайте чтение.
Фаза 1: планирование
Инвентаризация ящиков
Прежде чем трогать инструмент миграции, задокументируйте каждый ящик. Запишите общее число ящиков, примерное количество писем, диапазон дат самых старых писем и общие ящики/группы рассылки. Эта инвентаризация определяет выбор инструмента, время миграции и стоимость возможной пост-миграционной коррекции.
Выбор правильного инструмента
Не все инструменты одинаково обрабатывают даты. Изучите, как каждый инструмент сохраняет IMAP INTERNALDATE и добавляет ли заголовки "Received" при APPEND. Популярные инструменты: BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO и встроенный импорт Exchange. Каждый может вызвать проблемы с датами, так как сам протокол IMAP требует от целевого сервера добавления "Received" при вставке. Но некоторые инструменты лучше сохраняют INTERNALDATE. Для понимания работы INTERNALDATE см. IMAP INTERNALDATE: почему ломаются даты.
Полное резервное копирование
Создайте полную резервную копию каждого ящика перед миграцией. Она служит и страховкой, и точкой отсчёта для проверки дат. Для Google Workspace используйте Google Takeout или сторонний инструмент. Для Microsoft 365 - бэкап Exchange Online или экспорт PST. Для IMAP-серверов используйте imapsync для создания локальной копии.
Храните бэкапы полностью отдельно от серверов источника и назначения.
Документирование исходных дат
Выберите 10-20 писем на ящик из разных периодов (самые старые, самые новые, промежуточные). Запишите дату "Получения", дату "Отправки" и сырые заголовки каждого. Эти эталоны станут базой для пост-миграционной проверки. Сделайте скриншот ящика, отсортированного по дате, для визуальной документации исходного хронологического порядка.
Фаза 2: тестовая миграция
Сначала тестовый ящик
Никогда не запускайте полную миграцию без предварительного теста.
Создайте тестовый ящик с репрезентативной выборкой (минимум 100 писем за несколько лет). Мигрируйте только его и тщательно изучите результаты перед продолжением. Тест выявит проблемы с датами, ошибки кодировки, проблемы вложений и расхождения в структуре папок до того, как они затронут продуктивные ящики.
Проверка дат на тестовом ящике
После миграции тестового ящика немедленно проверьте даты. Откройте его в клиенте, который будут использовать пользователи (Outlook, Apple Mail, Thunderbird или веб-почта). Сравните отображаемые даты с документированными эталонами. Проверьте и "Получено", и "Отправлено". Откройте сырые заголовки нескольких писем и ищите новые "Received" с меткой миграции.
Если даты неправильны на тестовом ящике, они будут неправильны на всех. Остановитесь и решите проблему перед полной миграцией.
Тестирование в нескольких клиентах
Разные клиенты отображают даты по-разному. Gmail веб может показать правильные даты (использует заголовок "Date"), тогда как Outlook показывает дату миграции (приоритизирует "Received"). Тестируйте в каждом клиенте организации: Outlook Desktop, OWA, Apple Mail, Thunderbird и мобильные приложения.
Фаза 3: выполнение миграции
Настройка инструмента
Настройте инструмент на максимальное сохранение INTERNALDATE. В imapsync используйте соответствующие флаги. В BitTitan проверьте расширенные параметры для опций обработки дат. Эти настройки не полностью предотвратят проблему с "Received", но снизят тяжесть проблем с датами в некоторых клиентах. Документируйте каждую настройку для воспроизводимости.
Миграция пакетами
Не мигрируйте все ящики одновременно. Мигрируйте пакетами по 10-20, проверяя даты после каждого. Если пакет показывает проблемы, Вы обнаружите это до того, как вся организация будет затронута. Кстати, пакетная миграция также снижает нагрузку на серверы, уменьшая риск таймаутов или ошибок подключения.
Мониторинг прогресса
Отслеживайте прогресс каждого ящика. Записывайте время начала, окончания, число мигрированных писем и ошибки. Инструменты миграции обычно предоставляют логи - сохраняйте их для каждого ящика. Если проблемы с датами обнаружатся позже, логи помогут определить, какой пакет и какие настройки были использованы.
Фаза 4: пост-миграционная проверка
Немедленная проверка дат
Проверяйте даты в течение 24 часов после миграции. Для каждого пакета откройте 5-10 ящиков и сравните даты с пре-миграционными эталонами. Если даты неправильны, задокументируйте масштаб (сколько ящиков, сколько писем), пока информация свежа.
Проверка всех типов папок
Проблемы с датами могут затрагивать папки по-разному. Проверяйте во Входящих, Отправленных, Черновиках и пользовательских папках. Некоторые инструменты обрабатывают папки последовательно, и ошибки в одной не обязательно означают ошибки в других.
Проверка поиска и сортировки
Откройте мигрированный ящик, отсортируйте по дате и подтвердите соответствие оригиналу. Поищите письма по диапазону дат и проверьте точность результатов. Протестируйте автоматические правила и фильтры, зависящие от даты получения. Если используются инструменты комплаенса или eDiscovery, проверьте корректность запросов по датам.
Распространённые ошибки, вызывающие проблемы с датами
Пропуск тестовой миграции
Самая частая ошибка - миграция всех ящиков без предварительного теста. Когда проблемы обнаруживаются, все ящики уже затронуты, а сервер-источник, возможно, уже отключён. 30-минутный тест может предотвратить недели работы по исправлению. Зачем его пропускать?
Игнорирование добавления заголовков "Received"
Администраторы часто сосредотачиваются на сохранении INTERNALDATE и упускают проблему с "Received". Даже при корректной INTERNALDATE заголовок "Received" миграции приводит к неправильным датам в Outlook и других клиентах. Это самая частая причина пост-миграционных жалоб. Читайте почему письма показывают неправильные даты для полного объяснения.
Слишком ранний вывод сервера-источника
Если проблемы с датами обнаружены после отключения сервера-источника, вариант повторной миграции исчезает. Сохраняйте сервер-источник доступным (хотя бы в режиме чтения) минимум 30 дней после миграции. Это обеспечит запасной вариант при обнаружении серьёзных проблем.
Что делать, если даты уже сломаны
Если миграция завершена и даты неправильны, проблема решаема. Оригинальный заголовок "Date" сохранён в каждом письме, а значит, правильная информация о дате существует. Даты можно исправить после миграции, даже через месяцы или годы.
Проприетарный движок коррекции Redate.io подключается к ящику и ищет письма с повреждёнными метаданными дат. Многоступенчатый конвейер выявляет сигнатуры миграции, применяет точечные корректировки с сохранением целостности сообщений (подписи S/MIME, multipart-структуры, не-ASCII заголовки) и выполняет проверку целостности каждого письма. Анализ бесплатный. Оригиналы хранятся в видимой папке 30 дней.
Ручная коррекция или скрипт - искушение, но опасное. Краевые случаи (зашифрованные PGP, повреждённые MIME-границы, вложенные multipart, Content-Transfer-Encoding) могут бесшумно повредить письма без возможности это обнаружить, пока не будет слишком поздно. А как верифицировать, что 10 000 исправленных писем все целы?
Хотите проверить, есть ли в Вашем ящике проблемы с датами? Запустите бесплатный анализ с Redate.io - никакой оплаты для просмотра числа затронутых писем.