Защо чеклистът за миграция е незаменим
Имейл миграцията е една от най-рисковите IT операции, които една организация може да предприеме. Премествате години бизнес комуникация между платформи и един единствен пропуск може да повреди метаданните на всички пощенски кутии. Най-честата жертва? Датите на имейлите. След миграция всеки имейл рискува да покаже датата на миграцията вместо оригиналната дата на изпращане или получаване.
Този чеклист покрива всяка фаза от процеса на миграция. Следвайте тези стъпки, за да минимизирате риска от повреда на датите и други проблеми с метаданните. А ако миграцията вече е завършена и проблеми с датите са се появили, продължете да четете.
Фаза 1: планиране преди миграцията
Инвентаризирайте пощенските кутии
Преди да пипнете инструмент за миграция, документирайте всяка кутия, която ще бъде мигрирана. Запишете общия брой кутии, приблизителния брой имейли на кутия, диапазона от дати на най-старите имейли и споделените кутии или групи за разпространение. Тази инвентаризация определя кой инструмент за миграция да използвате, колко време ще отнеме миграцията и каква цена се прилага за евентуална корекция след миграцията.
Изберете правилния инструмент за миграция
Не всички инструменти за миграция обработват датите по един и същ начин. Проучете как всеки инструмент обработва запазването на IMAP INTERNALDATE и дали добавя "Received" хедъри по време на процеса на APPEND. Популярните инструменти включват BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO и вградения импорт на Exchange Admin Center. Всеки от тези инструменти може да причини проблеми с датите, тъй като самият IMAP протокол изисква целевият сървър да добави "Received" хедър при вмъкване. Но някои инструменти запазват INTERNALDATE по-добре от други. За да разберете по-добре как работи INTERNALDATE, вижте IMAP INTERNALDATE: защо датите се развалят.
Архивирайте всичко
Създайте пълен архив на всяка пощенска кутия преди миграцията. Този архив служи както като предпазна мрежа, така и като точка за сравнение за верификация на датите впоследствие. За Google Workspace използвайте Google Takeout или инструмент за архивиране от трети страни. За Microsoft 365 използвайте Exchange Online архивиране или PST експорт. За IMAP сървъри използвайте imapsync за създаване на локално копие.
Съхранявайте архивите на напълно отделно място от изходните и целевите сървъри.
Документирайте оригиналните дати
Изберете 10 до 20 имейла на кутия, разпределени в различни диапазони от дати (най-старите, най-скорошните и няколко междинни). Запишете датата на "Получаване", датата на "Изпращане" и суровите хедъри на всеки имейл. Тези референтни имейли стават базата за верификация след миграцията. Направете скрийншот на кутията, сортирана по дата, за визуално документиране на оригиналния хронологичен ред.
Фаза 2: тестова миграция
Мигрирайте първо тестова кутия
Никога не стартирайте пълна миграция без предварителен тест.
Създайте тестова кутия с представителна извадка от имейли (поне 100, обхващащи няколко години). Стартирайте миграцията само на тази кутия и прегледайте резултатите в дълбочина преди да продължите. Този тест разкрива проблеми с дати, грешки в кодирането, бъгове в обработката на прикачени файлове и разлики в структурата на папките преди те да засегнат продуктивните кутии.
Проверете датите на тестовата кутия
След мигриране на тестовата кутия проверете датите незабавно. Отворете кутията в пощенския клиент, който крайните потребители реално ще използват (Outlook, Apple Mail, Thunderbird или уебмейл интерфейса). Сравнете показваните дати с референтните имейли, документирани във Фаза 1. Проверете и датата на "Получаване", и датата на "Изпращане". Отворете суровите хедъри на няколко имейла и потърсете новодобавени "Received" хедъри с времеви печат на миграцията.
Ако датите са грешни на тестовата кутия, ще бъдат грешни на всички кутии. Спрете и решете проблема преди да продължите с пълната миграция.
Тествайте с множество пощенски клиенти
Различните пощенски клиенти показват датите по различен начин. Уеб интерфейсът на Gmail може да показва правилни дати (използва "Date" хедъра), докато Outlook показва датата на миграцията (дава приоритет на "Received" хедъра). Тествайте с всеки клиент, който потребителите на организацията използват, включително Outlook Desktop, Outlook в уеб, Apple Mail, Thunderbird и всякакви мобилни приложения за поща.
Фаза 3: изпълнение на миграцията
Конфигурация на инструмента за миграция
Конфигурирайте инструмента за миграция да запазва INTERNALDATE, доколкото е възможно. В imapsync използвайте подходящите флагове за задаване на INTERNALDATE на дестинацията. В BitTitan MigrationWiz проверете разширените настройки за опции за обработка на дати. Тези настройки няма да предотвратят напълно проблемите с "Received" хедъра, но намаляват тежестта на проблемите с датите в някои клиенти. Документирайте всяка използвана конфигурационна настройка, за да можете да възпроизведете миграцията, ако е необходимо.
Мигрирайте на партиди
Не мигрирайте всички кутии едновременно. Мигрирайте на партиди от 10 до 20 кутии, като проверявате датите след всяка партида. Ако партида покаже проблеми с дати, откривате го преди цялата организация да бъде засегната. Между другото, миграцията на партиди намалява и натоварването на изходните и целевите сървъри, намалявайки риска от таймаути или грешки в свързването, които могат да причинят частични миграции.
Следете прогреса
Проследявайте прогреса на миграцията за всяка кутия. Записвайте час на старт, час на завършване, брой мигрирани имейли и евентуални грешки. Инструментите за миграция обикновено предоставят логове - запазвайте ги за всяка кутия. Ако проблеми с дати бъдат открити по-късно, логовете помагат да се идентифицира точно коя миграционна партида и какви настройки са използвани.
Фаза 4: верификация след миграцията
Проверете датите незабавно
Проверете имейл датите в рамките на 24 часа след миграцията. За всяка партида отворете 5 до 10 кутии и сравнете датите с референциите от преди миграцията. Ако датите са грешни, документирайте обхвата на проблема (колко кутии са засегнати, колко имейла на кутия), докато информацията е свежа.
Проверете всички типове папки
Проблемите с дати могат да засегнат някои папки по различен начин. Проверете датите във Входяща поща, Изпратени, Чернови и всяка персонализирана папка или етикет. Някои инструменти за миграция обработват папките последователно и грешки в една папка не означават непременно грешки в другите.
Проверете търсенето и сортирането
Отворете мигрирана кутия, сортирайте по дата и потвърдете, че хронологичният ред съответства на оригинала. Потърсете имейли по диапазон от дати и проверете, че резултатите са точни. Тествайте всяко автоматизирано правило или филтър, зависещ от дати на получаване. Ако организацията използва инструменти за съответствие или eDiscovery, проверете, че заявките, базирани на дати, връщат правилни резултати.
Чести грешки, които причиняват проблеми с датите
Пропускане на тестовата миграция
Най-честата грешка е мигрирането на всички кутии без предварителен тест. Когато проблемите с дати бъдат открити, всички кутии са засегнати и изходният сървър може вече да е деактивиран. 30-минутна тестова миграция може да спести седмици ремедиация. Защо да я пропускате?
Игнориране на добавянето на "Received" хедъри
Администраторите често се фокусират върху запазването на INTERNALDATE и пренебрегват проблема с "Received" хедъра. Дори когато INTERNALDATE е правилно зададена, миграционният "Received" хедър кара Outlook и други клиенти да показват грешна дата. Това е най-честият източник на оплаквания след миграцията. Вижте защо имейлите показват грешни дати след миграция за пълно техническо обяснение.
Преждевременно деактивиране на изходния сървър
Ако проблеми с дати бъдат открити след спирането на изходния сървър, опцията за повторна миграция изчезва. Дръжте изходния сървър достъпен (дори само за четене) поне 30 дни след миграцията. Това осигурява резервен вариант, ако сериозни проблеми се появят по-късно.
Какво да направите, ако датите вече са грешни
Ако миграцията вече е извършена и датите са неправилни, проблемът е поправим. Оригиналният "Date" хедър е запазен във всеки имейл, което означава, че правилната информация за дата все още съществува. Имейл датите могат да бъдат коригирани след миграция, дори месеци или години по-късно.
Собственият коригиращ двигател на Redate.io се свързва с пощенската кутия и търси имейли с повредени метаданни за дата. Многоетапният процес на анализ идентифицира миграционните сигнатури, прилага целенасочени корекции, като запазва целостта на съобщенията (включително S/MIME подписи, multipart структури и не-ASCII хедъри), и изпълнява проверка на целостта на всеки коригиран имейл. Анализът е безплатен и показва точно колко имейла са засегнати. Оригиналите се съхраняват във видима резервна папка за 30 дни.
Опитът за такава корекция ръчно или с персонализиран скрипт е изкушаващ, но рискован. Специалните случаи като PGP криптирани съобщения, повредени MIME граници, вложени multipart структури и отклонения в Content-Transfer-Encoding могат безшумно да повредят имейли, без да осъзнаете, преди да е станало твърде късно. А как да проверите, че 10000 коригирани имейла са всички непокътнати?
Готови ли сте да проверите дали кутията ви има проблеми с датите? Стартирайте безплатен анализ с Redate.io - не се изисква плащане, за да видите колко имейла са засегнати.