Checklista migracji email: jak uniknąć błędów dat

Dlaczego checklista migracji jest niezbędna

Migracja poczty elektronicznej należy do najbardziej ryzykownych operacji IT, jakie może przeprowadzić organizacja. Przenosimy lata profesjonalnej komunikacji między platformami, a jeden pominięty krok może uszkodzić metadane wszystkich skrzynek pocztowych. Najczęstsza ofiara? Daty wiadomości. Po migracji każdy email może wyświetlać datę wykonania migracji zamiast oryginalnej daty wysłania lub odebrania.

Ta checklista obejmuje każdą fazę procesu migracji. Należy stosować się do tych kroków, aby zminimalizować ryzyko uszkodzenia dat i innych problemów z metadanymi. Jeśli migracja jest już zakończona i pojawiły się problemy z datami, warto czytać dalej.

Faza 1: planowanie przed migracją

Inwentaryzacja skrzynek pocztowych

Zanim sięgnie się po jakiekolwiek narzędzie migracyjne, należy udokumentować każdą skrzynkę, która ma zostać przeniesiona. Warto zapisać łączną liczbę skrzynek, przybliżoną liczbę wiadomości w każdej z nich, zakres dat najstarszych emaili oraz listę skrzynek współdzielonych i grup dystrybucyjnych. Ten inwentarz pozwala określić, które narzędzie migracyjne wybrać, ile czasu zajmie migracja, a także jakie będą koszty ewentualnych korekt po migracji.

Wybór właściwego narzędzia migracyjnego

Nie wszystkie narzędzia migracyjne obsługują daty w ten sam sposób. Trzeba sprawdzić, jak każde z nich radzi sobie z zachowaniem IMAP INTERNALDATE i czy dodaje nagłówki "Received" podczas procesu wstawiania wiadomości. Popularne narzędzia to BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO oraz natywny import w centrum administracyjnym Exchange. Każde z nich może powodować problemy z datami, bo sam protokół IMAP wymaga, żeby serwer docelowy dodał nagłówek "Received" przy wstawianiu wiadomości. Niektóre narzędzia lepiej zachowują jednak INTERNALDATE niż inne. Więcej o mechanizmie INTERNALDATE można przeczytać w artykule o tym, dlaczego IMAP INTERNALDATE psuje daty emaili.

Tworzenie kopii zapasowych

Przed migracją należy utworzyć pełną kopię zapasową każdej skrzynki pocztowej. Taka kopia służy zarówno jako siatka bezpieczeństwa, jak i punkt odniesienia do weryfikacji dat po migracji. W przypadku Google Workspace można użyć Google Takeout lub zewnętrznego narzędzia do backupu. Dla Microsoft 365 sprawdza się kopia zapasowa Exchange Online lub eksport do PST. W przypadku serwerów IMAP można użyć imapsync do stworzenia lokalnej kopii.

Kopie zapasowe powinny być przechowywane w lokalizacji całkowicie oddzielonej od serwerów źródłowego i docelowego.

Dokumentowanie oryginalnych dat

Warto wybrać od 10 do 20 wiadomości ze każdej skrzynki, rozłożonych na różne zakresy dat (najstarsze, najnowsze i kilka pośrednich). Należy zapisać datę "Odbioru", datę "Wysłania" oraz surowe nagłówki każdej z tych wiadomości. Te emaile referencyjne stają się podstawą weryfikacji po migracji. Warto też zrobić zrzut ekranu skrzynki posortowanej według daty, aby wizualnie udokumentować oryginalny porządek chronologiczny.

Faza 2: migracja testowa

Najpierw migracja skrzynki testowej

Nie należy nigdy uruchamiać pełnej migracji bez wcześniejszego testu.

Trzeba utworzyć skrzynkę testową z reprezentatywną próbką wiadomości (co najmniej 100, obejmujących kilka lat). Następnie uruchomić migrację tylko tej jednej skrzynki i dokładnie zbadać wyniki przed kontynuowaniem. Ten test ujawnia problemy z datami, błędy kodowania, błędy w obsłudze załączników i rozbieżności w strukturze folderów, zanim zdążą wpłynąć na skrzynki produkcyjne.

Weryfikacja dat w skrzynce testowej

Po migracji skrzynki testowej należy natychmiast sprawdzić daty. Skrzynkę trzeba otworzyć w kliencie pocztowym, którego faktycznie będą używać końcowi użytkownicy (Outlook, Apple Mail, Thunderbird lub interfejs webmail). Następnie porównać wyświetlane daty z wiadomościami referencyjnymi udokumentowanymi w Fazie 1. Weryfikacja powinna obejmować zarówno daty "Odbioru", jak i "Wysłania". Warto też otworzyć surowe nagłówki kilku wiadomości i poszukać świeżo dodanych nagłówków "Received" ze znacznikiem czasu migracji.

Jeśli daty są błędne w skrzynce testowej, będą błędne we wszystkich skrzynkach. Trzeba zatrzymać wszystko i rozwiązać problem przed przystąpieniem do pełnej migracji.

Testy w wielu klientach pocztowych

Różne klienty pocztowe wyświetlają daty w różny sposób. Webowy interfejs Gmaila może pokazywać poprawne daty (korzysta z nagłówka "Date"), podczas gdy Outlook wyświetla datę migracji (priorytetowo traktuje nagłówek "Received"). Testy należy przeprowadzić we wszystkich klientach używanych przez pracowników organizacji: Outlook dla pulpitu, Outlook w przeglądarce, Apple Mail, Thunderbird i wszelkie mobilne aplikacje pocztowe.

Faza 3: wykonanie migracji

Konfiguracja narzędzia migracyjnego

Narzędzie migracyjne należy skonfigurować tak, aby w miarę możliwości zachowywało INTERNALDATE. W imapsync trzeba użyć odpowiednich flag ustawiających INTERNALDATE na serwerze docelowym. W BitTitan MigrationWiz warto sprawdzić ustawienia zaawansowane pod kątem opcji zarządzania datami. Takie ustawienia nie wyeliminują całkowicie problemów z nagłówkami "Received", ale zmniejszają nasilenie błędów dat w niektórych klientach. Każdy użyty parametr konfiguracyjny powinien być udokumentowany, żeby w razie potrzeby móc odtworzyć migrację.

Migracja partiami

Nie należy migrować wszystkich skrzynek jednocześnie. Migracja powinna odbywać się partiami po 10 do 20 skrzynek, z weryfikacją dat po każdej partii. Jeśli w danej partii pojawią się problemy z datami, zostaną wykryte, zanim obejmą całą organizację. Migracja partiami zmniejsza też obciążenie serwerów źródłowego i docelowego, co ogranicza ryzyko timeoutów i błędów połączenia mogących powodować niekompletne migracje.

Monitorowanie postępów

Warto śledzić postęp migracji dla każdej skrzynki. Należy zapisywać godzinę rozpoczęcia, godzinę zakończenia, liczbę zmigrowanych wiadomości i ewentualne błędy. Narzędzia migracyjne zazwyczaj generują logi, które warto zachować dla każdej skrzynki. Jeśli problemy z datami zostaną odkryte później, logi pomogą ustalić, która partia migracji i jakie parametry były użyte.

Faza 4: weryfikacja po migracji

Natychmiastowa weryfikacja dat

Daty wiadomości należy sprawdzić w ciągu 24 godzin od zakończenia migracji. Dla każdej partii warto otworzyć 5 do 10 skrzynek i porównać daty z referencjami sprzed migracji. Jeśli daty są błędne, trzeba udokumentować zakres problemu (ile skrzynek dotyczy, ile wiadomości w każdej) dopóki informacje są świeże.

Weryfikacja wszystkich typów folderów

Problemy z datami mogą dotyczyć poszczególnych folderów w różnym stopniu. Daty należy sprawdzić w Skrzynce odbiorczej, Elementach wysłanych, Wersjach roboczych oraz we wszystkich niestandardowych folderach i etykietach. Niektóre narzędzia migracyjne przetwarzają foldery sekwencyjnie, a błędy w jednym folderze nie muszą oznaczać błędów w pozostałych.

Weryfikacja wyszukiwania i sortowania

Należy otworzyć zmigrowaną skrzynkę, posortować wiadomości według daty i potwierdzić, że kolejność chronologiczna odpowiada oryginałowi. Warto wyszukać wiadomości według zakresu dat i sprawdzić, czy wyniki są prawidłowe. Trzeba też przetestować wszelkie automatyczne reguły i filtry zależące od dat odbioru. Jeśli organizacja korzysta z narzędzi do zapewnienia zgodności lub eDiscovery, należy sprawdzić, czy zapytania oparte na datach zwracają poprawne wyniki.

Typowe błędy powodujące problemy z datami

Pomijanie migracji testowej

Najczęstszy błąd to migracja wszystkich skrzynek bez wcześniejszego testu. Kiedy problemy z datami wychodzą na jaw, wszystkie skrzynki są już dotknięte, a serwer źródłowy mógł zostać już wyłączony. Trzydziestominutowa migracja testowa może oszczędzić tygodni naprawiania skutków. Po co ryzykować?

Ignorowanie dodanych nagłówków "Received"

Administratorzy często skupiają się na zachowaniu INTERNALDATE i pomijają problem nagłówka "Received". Nawet gdy INTERNALDATE jest ustawiony prawidłowo, nagłówek "Received" z procesu migracji powoduje, że Outlook i inne klienty wyświetlają błędną datę. To najczęstsze źródło zgłoszeń po migracji. Warto zapoznać się z artykułem wyjaśniającym, dlaczego emaile pokazują złą datę po migracji.

Zbyt wczesne wyłączenie serwera źródłowego

Jeśli problemy z datami zostaną odkryte po wyłączeniu serwera źródłowego, opcja ponownej migracji znika. Serwer źródłowy powinien pozostać dostępny (choćby tylko do odczytu) przez co najmniej 30 dni po migracji. Zapewnia to furtkę awaryjną, jeśli poważne problemy ujawnią się później.

Co zrobić, gdy daty są już błędne

Jeśli migracja została już przeprowadzona, a daty są nieprawidłowe, problem da się naprawić. Oryginalny nagłówek "Date" jest zachowany w każdej wiadomości, co oznacza, że prawidłowa informacja o dacie wciąż istnieje. Daty emaili można naprawić po migracji, nawet wiele miesięcy lub lat później.

Autorski mechanizm korekcji Redate.io łączy się ze skrzynką i wyszukuje wiadomości z uszkodzonymi metadanymi dat. Wieloetapowy potok analizy identyfikuje sygnatury narzędzi migracyjnych, stosuje ukierunkowane korekty przy jednoczesnym zachowaniu integralności wiadomości (w tym podpisów S/MIME, struktur multipart i nagłówków spoza ASCII), a następnie przeprowadza weryfikację integralności każdej poprawionej wiadomości. Analiza jest bezpłatna i pokazuje dokładnie, ile wiadomości jest dotkniętych problemem. Oryginały są przechowywane w widocznym folderze kopii zapasowej przez 30 dni.

Próba takiej korekty ręcznie lub za pomocą własnego skryptu kusi, ale jest ryzykowna. Przypadki szczególne, takie jak wiadomości zaszyfrowane PGP, uszkodzone granice MIME, zagnieżdżone struktury multipart czy rozbieżności Content-Transfer-Encoding, mogą po cichu uszkodzić emaile, zanim ktokolwiek to zauważy. I jak zweryfikować, że 10 000 poprawionych wiadomości jest w pełni nienaruszonych?

Gotowy sprawdzić, czy skrzynka ma problemy z datami? Uruchom bezpłatną analizę w Redate.io - żadna płatność nie jest wymagana, żeby zobaczyć, ile wiadomości jest dotkniętych problemem.