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 і застрягли з неправильними датами? Запустіть безкоштовне сканування, щоб побачити, скільки листів постраждало, перш ніж приймати будь-які рішення.