Чеклист за имейл миграция: предотвратете проблемите с датите

Защо чеклистът за миграция е задължителен

Имейл миграцията е една от най-рисковите IT операции, които една организация може да предприеме. Преместват се години на професионална комуникация между платформи, и един-единствен пропуск може да повреди метаданните на всички пощенски кутии. Най-честата жертва? Датите на имейлите. След миграция всеки имейл рискува да показва датата на миграцията вместо оригиналната дата на изпращане или получаване.

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

Фаза 1: планиране преди миграцията

Инвентаризация на пощенските кутии

Преди да докоснете какъвто и да е инструмент за миграция, документирайте всяка кутия, която ще бъде мигрирана. Запишете общия брой кутии, приблизителния брой имейли на кутия, диапазона на датите на най-старите имейли, и споделените кутии или дистрибуционните групи. Тази инвентаризация определя кой инструмент за миграция да използвате, колко ще отнеме миграцията, и какво ценообразуване се прилага при евентуални корекции след миграцията.

Избор на правилния инструмент за миграция

Не всички инструменти за миграция обработват датите по един и същ начин. Проучете как всеки инструмент управлява запазването на IMAP INTERNALDATE и дали добавя заглавки "Received" по време на процеса на вмъкване. Популярните инструменти включват BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO и нативния импорт в Exchange Admin Center. Всеки от тях може да причини проблеми с датите, тъй като самият IMAP протокол изисква сървърът на дестинацията да добави заглавка "Received" при вмъкването. Но някои инструменти запазват INTERNALDATE по-добре от други. За по-добро разбиране как функционира INTERNALDATE, вижте IMAP INTERNALDATE: защо датите се развалят.

Резервно копиране на всичко

Създайте пълно резервно копие на всяка пощенска кутия преди миграцията. Това копие служи едновременно като предпазна мрежа и като референтна точка за проверка на датите след това. За Google Workspace използвайте Google Takeout или инструмент за резервно копиране на трета страна. За Microsoft 365 използвайте Exchange Online Backup или експорт в PST формат. За IMAP сървъри използвайте imapsync, за да създадете локално копие.

Съхранявайте резервните копия на напълно отделно място от изходните и целевите сървъри.

Документиране на оригиналните дати

Изберете 10 до 20 имейла на кутия, разпределени в различни диапазони от дати (най-старите, най-новите и няколко от средата). Запишете датата на "Получаване", датата на "Изпращане" и суровите заглавки на всеки имейл. Тези референтни имейли стават вашата база за проверка след миграцията. Направете снимка на екрана на кутията, наредена по дата, за да документирате визуално оригиналния хронологичен ред.

Фаза 2: тестова миграция

Първо мигрирайте тестова кутия

Никога не стартирайте пълна миграция, без да я тествате предварително.

Създайте тестова кутия с представителна извадка от имейли (поне 100, обхващащи няколко години). Стартирайте миграцията само за тази кутия и задълбочено разгледайте резултатите, преди да продължите. Този тест разкрива проблеми с датите, грешки в кодирането, бъгове при обработката на прикачени файлове и несъответствия в структурата на папките, преди да засегнат производствените кутии.

Проверка на датите в тестовата кутия

След като мигрирате тестовата кутия, проверете датите незабавно. Отворете кутията в имейл клиента, който крайните потребители реално ще използват (Outlook, Apple Mail, Thunderbird или уеб интерфейса). Сравнете показваните дати с референтните имейли, документирани във Фаза 1. Проверете и датите на "Получаване", и датите на "Изпращане". Отворете суровите заглавки на няколко имейла и потърсете новодобавените заглавки "Received" с времеви печат на миграцията.

Ако датите са грешни в тестовата кутия, те ще бъдат грешни и в останалите. Спрете всичко и решете проблема, преди да продължите с пълната миграция.

Тестване с различни имейл клиенти

Различните имейл клиенти показват датите по различен начин. Уеб интерфейсът на Gmail може да показва верни дати (използва заглавката "Date"), докато Outlook показва датата на миграцията (той дава приоритет на заглавката "Received"). Тествайте с всеки клиент, който потребителите в организацията използват: Outlook за десктоп, Outlook в браузъра, Apple Mail, Thunderbird и всяко мобилно приложение за имейл.

Фаза 3: изпълнение на миграцията

Конфигурация на инструмента за миграция

Конфигурирайте инструмента за миграция да запазва INTERNALDATE доколкото е възможно. В imapsync използвайте подходящите флагове за задаване на INTERNALDATE на дестинацията. В BitTitan MigrationWiz проверете разширените настройки за опции за управление на дати. Тези настройки няма да предотвратят напълно проблемите със заглавките "Received", но намаляват сериозността на проблемите с датите в определени клиенти. Документирайте всеки използван параметър на конфигурацията, за да можете да възпроизведете миграцията при необходимост.

Миграция на партиди

Не мигрирайте всички кутии едновременно. Мигрирайте на партиди от 10 до 20 кутии, като проверявате датите след всяка партида. Ако дадена партида показва проблеми с датите, ще ги забележите, преди цялата организация да бъде засегната. Между другото, миграцията на партиди намалява и натоварването на изходния и целевия сървър, което снижава риска от timeouts или грешки при свързване, които могат да доведат до частични миграции.

Наблюдение на напредъка

Проследявайте напредъка на миграцията за всяка кутия. Записвайте началния час, крайния час, броя мигрирани имейли и евентуалните грешки. Инструментите за миграция обикновено предоставят логове, запазете ги за всяка кутия. Ако по-късно бъдат открити проблеми с датите, логовете помагат да се установи точно коя партида и кои параметри са използвани.

Фаза 4: проверка след миграцията

Незабавна проверка на датите

Проверете датите на имейлите в рамките на 24 часа след миграцията. За всяка партида отворете 5 до 10 кутии и сравнете датите с референтните данни отпреди миграцията. Ако датите са грешни, документирайте обхвата на проблема (колко кутии са засегнати, колко имейла на кутия), докато информацията е прясна.

Проверка на всички видове папки

Проблемите с датите могат да засягат различни папки по различен начин. Проверете датите в Входящата поща, Изпратени, Чернови и всяка персонализирана папка или етикет. Някои инструменти за миграция обработват папките последователно, и грешки в една папка не означават непременно грешки в другите.

Проверка на търсенето и сортирането

Отворете мигрирана кутия, наредете по дата и потвърдете, че хронологичният ред съответства на оригинала. Търсете имейли по диапазон от дати и проверете дали резултатите са точни. Тествайте всяко автоматизирано правило или филтър, зависещ от датите на получаване. Ако организацията използва инструменти за съответствие или eDiscovery, проверете дали заявките, базирани на дати, връщат правилни резултати.

Чести грешки, причиняващи проблеми с датите

Пропускане на тестовата миграция

Най-честата грешка е да мигрирате всички кутии без предварително тестване. Когато се открият проблеми с датите, всички кутии вече са засегнати и изходният сървър може вече да е деактивиран. Тестова миграция от 30 минути може да спести седмици на отстраняване на проблеми. Защо да се отказвате от нея?

Пренебрегване на добавените заглавки "Received"

Администраторите често се фокусират върху запазването на INTERNALDATE и пренебрегват проблема със заглавката "Received". Дори когато INTERNALDATE е зададен правилно, заглавката "Received" от миграцията кара Outlook и другите клиенти да показват грешна дата. Това е най-честият источник на оплаквания след миграция. Прочетете защо имейлите показват грешна дата след миграция за пълно техническо обяснение.

Деактивиране на изходния сървър твърде рано

Ако проблеми с датите се открият след изключването на изходния сървър, възможността за повторна миграция изчезва. Дръжте изходния сървър достъпен (дори само за четене) поне 30 дни след миграцията. Това осигурява резервен вариант, ако по-късно се появят сериозни проблеми.

Какво да направите, ако датите вече са грешни

Ако миграцията вече е извършена и датите са неверни, проблемът може да бъде отстранен. Оригиналната заглавка "Date" е запазена във всеки имейл, което означава, че правилната информация за датата все още съществува. Датите на имейлите могат да се коригират след миграция, дори месеци или години по-късно.

Proprietary correction engine на Redate.io се свързва с пощенската кутия и търси имейли с повредени метаданни за дати. Многоетапният pipeline за анализ идентифицира сигнатурите на миграцията, прилага целенасочени корекции, като запазва целостта на съобщенията (включително S/MIME подписи, multipart структури и non-ASCII заглавки), и извършва проверка на целостта за всеки коригиран имейл. Анализът е безплатен и показва точно колко имейла са засегнати. Оригиналите се запазват в видима папка за резервно копие в продължение на 30 дни.

Опитът да се направи подобна корекция ръчно или с персонализиран скрипт е изкушаващ, но рискован. Особени случаи като PGP криптирани съобщения, повредени MIME граници, вложени multipart структури и несъответствия в Content-Transfer-Encoding могат безшумно да повредят имейли, без да разберете преди да е станало твърде късно. И как да проверите, че 10000 коригирани имейла са всички непокътнати?

Готови ли сте да проверите дали пощенската ви кутия има проблеми с датите? Стартирайте безплатен анализ с Redate.io - не се изисква плащане, за да видите колко имейла са засегнати.