English
Français
Deutsch
Español
Português
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Türkçe
Ελληνικά
Русский
Polski
Čeština
Українська
Magyar
Română
Български
Hrvatski
Srpski
Slovenčina
Slovenščina
Lietuvių
Latviešu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
Какво прави 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 граници, е съвсем друго. Скрипт, който работи с 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 и останахте с грешни дати? Стартирайте безплатно сканиране, за да видите точно колко имейла са засегнати, преди да поемете какъвто и да е ангажимент.