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

Що BitTitan MigrationWiz робить із датами листів

Міграція завершилася минулої п'ятниці. 47 поштових скриньок перенесено з локального Exchange до Microsoft 365, у панелі MigrationWiz все зелене. А потім настав понеділок зранку, і надійшов перший тікет: "Усі мої листи показують 28 березня 2026 року."

Кожне повідомлення. Роки листування, пропозиції клієнтам з 2019-го, рахунки з 2021-го, на всіх стоїть дата міграції. Лог MigrationWiz каже, що все перенесено успішно (технічно так воно і є). Але дати зникли.

BitTitan MigrationWiz - один із найпоширеніших інструментів для хмарної міграції електронної пошти. Він працює з Exchange на Microsoft 365, Google Workspace на Exchange, міжтенантними переносами та іншими сценаріями. Сам інструмент добре виконує свою роботу. Проблема з датами - це не баг MigrationWiz. Усе залежить від одного: якої дати набуває кожна копія в момент запису у нову поштову скриньку.

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

Де насправді ховається неправильна дата

Коли MigrationWiz переносить лист із джерела на приймач, використовується протокол IMAP (або Exchange Web Services, залежно від типу кінцевої точки). Сервер призначення зберігає ту дату, яку йому передають: Microsoft 365, Outlook.com і Gmail зберігають оригінальну дату, якщо копія її несе. Тож якщо всі листи показують дату міграції, питання в тому, яку дату передав, або не передав, MigrationWiz.

Ось що досі містять заголовки одного з цих листів після міграції MigrationWiz:

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

Оригінальний заголовок Date: з 2019 року залишається на місці, так само як і оригінальний ланцюжок Received:. А в Microsoft 365 дата, яку Outlook показує як дату отримання, - це власний запис поштової скриньки про час надходження кожного листа: якщо MigrationWiz не передав оригінальну дату, цей запис показує 28 березня 2026 року.

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

Чому Date Mapping у MigrationWiz не рятує

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

Плутанина зрозуміла. У назві налаштування є слово "date". Але фактично вона фільтрує вихідні повідомлення за діапазоном дат перед міграцією. Лист 2018 року все одно потрапляє на приймач із міткою часу міграції.

Є ще питання IMAP проти Exchange. Коли MigrationWiz мігрує між двома серверами Exchange через EWS (Exchange Web Services), збереження дат працює краще, бо EWS має більше контролю над метаданими повідомлень. Але і через IMAP сервер призначення зберігає ту дату, яку йому передають: важливо лише, чи передається оригінальна дата.

Деякі адміністратори пробували перезапустити міграцію з іншими налаштуваннями кінцевих точок, сподіваючись, що переключення з IMAP на EWS виправить дати заднім числом. Не виправить. Повідомлення вже на приймачі з неправильними датами. Повторний запуск MigrationWiz лише створить дублікати.

Конкретні сценарії MigrationWiz, що ламають дати

Не кожна міграція MigrationWiz спричиняє проблеми з датами. Залежить від комбінації кінцевих точок:

• Exchange (локальний) до Microsoft 365 через IMAP: Дати ламаються. Кожен лист отримує дату копії.
• Google Workspace до Microsoft 365: Дати ламаються. MigrationWiz зчитує з Google по IMAP і записує в M365 без оригінальної дати.
• Exchange до Exchange (EWS до EWS): Дати зазвичай зберігаються. Через EWS оригінальна дата подорожує разом із листом.
• Будь-що до Google Workspace через IMAP: Дати ламаються. Через IMAP Gmail зберігає ту дату, яку передає інструмент, і нічого не додає. Дати ламаються лише тоді, коли ця дата не є оригінальною, або коли копія проходить через API імпорту Gmail, який додає рядок Received: із датою дня копіювання.
• Міжтенантний Microsoft 365: Усе залежить від дати, яку передає метод.

Панель MigrationWiz не позначає проблеми з датами. Все відображається як "Completed", бо повідомлення дійсно перенесені успішно. Вміст цілий, вкладення на місці, структура папок збережена. Змінилися лише дати, і MigrationWiz це не відстежує як помилку міграції.

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

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

Юридичні відділи не можуть використовувати листи як докази, коли кожне повідомлення показує дату міграції замість реальної дати відправлення. Податкові перевірки вимагають хронологічного підтвердження листування. Регуляторні рамки, як-от GDPR, зобов'язують вести точний облік записів, а листи з підробленими мітками часу цій вимозі не відповідають.

І є практичний бік. Спробуйте знайти обговорення договору з листопада 2022 року, коли вся поштова скринька показує березень 2026. Сортування за датою? Марне. Пошук за діапазоном дат? Повертає все або нічого.

Для MSP, що використовували MigrationWiz у клієнтських середовищах, це створює проблему відповідальності. Клієнт заплатив за міграцію. Він її отримав, але його поштовий архів фактично зламаний для робочих процесів, що залежать від дат.

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

Виправлення дат BitTitan MigrationWiz

Оригінальний заголовок Date: досі знаходиться всередині кожного листа. MigrationWiz не чіпає тіло повідомлення і оригінальні заголовки. Проблему відображення спричиняє дата, яку поштова скринька записала для кожної копії.

Redate.io підключається до поштової скриньки (Google Workspace, Microsoft 365 або IMAP), сканує листи, що постраждали від міграції MigrationWiz, і виправляє метадані дат через пропрієтарний багатоступеневий аналітичний конвеєр. Виправлення спрямоване саме на шар метаданих, і йому не потрібно знати, який інструмент виконував міграцію: він знаходить листи, чия відображена дата не відповідає оригінальній даті.

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

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