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 граници, е съвсем друго. Скрипт, който работи с 10 тестови съобщения в лаборатория, няма да се справи с крайните случаи на продуктивна пощенска кутия със 7 години кореспонденция, PGP-криптирани съобщения и RFC 2047 заглавия с не-ASCII символи.

Всъщност, как ще проверите, че всяко коригирано съобщение е непокътнато? Че нишките на разговори все още работят, че поканите за календар все още се разрешават, че прикаченият файл от 47 MB от онзи имейл от 2020 не се е повредил? Redate.io прави това автоматично, за всяко отделно съобщение. И ако нещо изглежда съмнително, оригиналът е точно там, в папката за резервно копие.

Безплатното сканиране отнема около две минути. Свързва се с пощенската кутия, идентифицира всеки имейл с печат на датата на миграцията с MigrationWiz и показва точния брой и цена, преди да платите каквото и да е. Без кредитна карта, без ангажимент.

Ръководства за поправка по платформи за BitTitan

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

• Поправка на дати от BitTitan в Outlook
• Поправка на дати от BitTitan в Microsoft 365
• Поправка на дати от BitTitan в Google Workspace
• Поправка на дати от BitTitan в Exchange Online

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

Мигрирахте с BitTitan MigrationWiz и останахте с грешни дати? Стартирайте безплатно сканиране, за да видите точно колко имейла са засегнати, преди да поемете какъвто и да е ангажимент.