Proč je checklist migrace nezbytný
Migrace e-mailů je jednou z nejrizikovějších IT operací, kterou může organizace podniknout. Přesunují se roky profesní komunikace mezi platformami a jediné opomenutí může poškodit metadata všech schránek. Nejčastější obětí jsou datumy e-mailů. Po migraci hrozí, že každý e-mail zobrazí datum migrace místo původního data odeslání nebo přijetí.
Tento checklist pokrývá každou fázi migračního procesu. Postupujte podle těchto kroků, abyste minimalizovali riziko poškození datumů a dalších problémů s metadaty. A pokud už je migrace dokončena a problémy s datumy se objevily, čtěte dál.
Fáze 1: plánování před migrací
Inventura schránek
Než se dotknete jakéhokoli migračního nástroje, zdokumentujte každou schránku, která bude migrována. Zaznamenejte celkový počet schránek, přibližný počet e-mailů na schránku, rozsah dat nejstarších e-mailů a sdílené schránky nebo distribuční skupiny. Tento inventář určuje, jaký migrační nástroj použít, jak dlouho migrace potrvá a jaký tarif se uplatní pro případné opravy po migraci.
Výběr správného migračního nástroje
Ne všechny migrační nástroje zacházejí s datumy stejně. Zjistěte si, jak každý nástroj zachází s uchováním IMAP INTERNALDATE a zda přidává hlavičky "Received" během procesu APPEND. Mezi oblíbené nástroje patří BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO a nativní import z Centra pro správu Exchange. Každý z těchto nástrojů může způsobit problémy s datumy, protože samotný protokol IMAP vyžaduje, aby cílový server přidal hlavičku "Received" při vkládání. Některé nástroje ale uchovávají INTERNALDATE lépe než jiné. Pro lepší pochopení fungování INTERNALDATE viz IMAP INTERNALDATE: proč se datumy pokazí.
Zálohujte vše
Vytvořte kompletní zálohu každé schránky před migrací. Tato záloha slouží jako bezpečnostní síť i jako referenční bod pro ověření datumů po migraci. Pro Google Workspace použijte Google Takeout nebo zálohovací nástroj třetí strany. Pro Microsoft 365 použijte zálohu Exchange Online nebo export do PST. Pro servery IMAP použijte imapsync k vytvoření lokální kopie.
Zálohy uchovávejte na zcela odděleném místě od zdrojových i cílových serverů.
Zdokumentujte původní datumy
Vyberte 10 až 20 e-mailů na schránku rozložených přes různé časové rozsahy (nejstarší, nejnovější a několik uprostřed). Zaznamenejte datum "Přijetí", datum "Odeslání" a surové hlavičky každého e-mailu. Tyto referenční e-maily se stanou Vaší verifikační základnou po migraci. Udělejte snímek obrazovky schránky seřazené podle data, abyste vizuálně zdokumentovali původní chronologické pořadí.
Fáze 2: testovací migrace
Nejprve migrujte testovací schránku
Nikdy nespouštějte kompletní migraci bez předchozího testování.
Vytvořte testovací schránku s reprezentativním vzorkem e-mailů (alespoň 100, pokrývající několik let). Spusťte migraci pouze na této schránce a důkladně prozkoumejte výsledky, než budete pokračovat. Tento test odhalí problémy s datumy, chyby kódování, chyby při zpracování příloh a nesrovnalosti ve struktuře složek, ještě než postihnou produkční schránky.
Ověřte datumy na testovací schránce
Po migraci testovací schránky okamžitě ověřte datumy. Otevřte schránku v e-mailovém klientovi, který budou koncový uživatelé skutečně používat (Outlook, Apple Mail, Thunderbird nebo webové rozhraní). Porovnejte zobrazené datumy s referenčními e-maily zdokumentovanými ve Fázi 1. Ověřte data "Přijetí" i "Odeslání". Otevřete surové hlavičky několika e-mailů a hledejte nově přidané hlavičky "Received" s časovým razítkem migrace.
Pokud jsou datumy na testovací schránce špatné, budou špatné na všech schránkách. Zastavte vše a vyřešte problém, než přistoupíte ke kompletní migraci.
Testujte s více e-mailovými klienty
Různí e-mailoví klienti zobrazují datumy odlišně. Webové rozhraní Gmailu může ukazovat správné datumy (používá hlavičku "Date"), zatímco Outlook zobrazí datum migrace (upřednostňuje hlavičku "Received"). Testujte s každým klientem, který uživatelé organizace používají, zejména Outlook Desktop, Outlook na webu, Apple Mail, Thunderbird a jakékoli mobilní e-mailové aplikace.
Fáze 3: provedení migrace
Konfigurace migračního nástroje
Nakonfigurujte migrační nástroj tak, aby co nejvíce zachoval INTERNALDATE. V imapsync použijte příslušné parametry pro nastavení INTERNALDATE na cílovém serveru. V BitTitan MigrationWiz zkontrolujte pokročilé nastavení a možnosti správy datumů. Tato nastavení zcela nezabrání problémům s hlavičkou "Received", ale zmírní závažnost problémů s datumy v některých klientech. Zdokumentujte každé použité nastavení konfigurace, abyste mohli migraci v případě potřeby zopakovat.
Migrujte po dávkách
Nemigrujte všechny schránky současně. Migrujte po dávkách 10 až 20 schránek a po každé dávce ověřte datumy. Pokud dávka vykazuje problémy s datumy, odhalíte to dříve, než bude postižena celá organizace. Mimochodem, migrace po dávkách také snižuje zátěž zdrojových i cílových serverů a tím i riziko timeoutů nebo chyb připojení, které mohou způsobit neúplné migrace.
Sledujte průběh
Sledujte průběh migrace každé schránky. Zaznamenejte čas zahájení, čas dokončení, počet migrovaných e-mailů a případné chyby. Migrační nástroje obvykle poskytují logy - uchovejte je pro každou schránku. Pokud se problémy s datumy objeví později, logy pomohou přesně určit, která migrační dávka a jaká nastavení byly použity.
Fáze 4: ověření po migraci
Okamžitě ověřte datumy
Ověřte datumy e-mailů do 24 hodin po migraci. Pro každou dávku otevřete 5 až 10 schránek a porovnejte datumy s referenčními údaji před migrací. Pokud jsou datumy špatné, zdokumentujte rozsah problému (kolik schránek je postiženo, kolik e-mailů na schránku), dokud jsou informace čerstvé.
Zkontrolujte všechny typy složek
Problémy s datumy mohou postihovat některé složky odlišně. Zkontrolujte datumy v Doručené poště, Odeslaných položkách, Konceptech a ve všech vlastních složkách nebo štítcích. Některé migrační nástroje zpracovávají složky postupně a chyby v jedné složce nutně neznamenají chyby v ostatních.
Ověřte vyhledávání a řazení
Otevřte migrovanou schránku, seřaďte podle data a potvrďte, že chronologické pořadí odpovídá originálu. Vyhledejte e-maily podle rozsahu dat a ověřte, že výsledky jsou přesné. Otestujte jakékoli automatické pravidlo nebo filtr, který závisí na datu přijetí. Pokud organizace používá nástroje pro dodržování předpisů nebo eDiscovery, ověřte, že dotazy založené na datech vracejí správné výsledky.
Časté chyby způsobující problémy s datumy
Přeskočení testovací migrace
Nejčastější chybou je migrovat všechny schránky bez předchozího testování. Když se problémy s datumy objeví, jsou postiženy všechny schránky a zdrojový server už mohl být deaktivován. Třicetiminutová testovací migrace může zabránit týdnům nápravných prací. Proč si ji odpustit?
Ignorování přidaných hlaviček "Received"
Administrátoři se často soustředí na uchování INTERNALDATE a přehlížejí problém s hlavičkou "Received". I když je INTERNALDATE správně nastaven, migrační hlavička "Received" způsobí, že Outlook a další klienti zobrazují špatné datum. To je nejčastější příčina stížností po migraci. Přečtěte si článek proč e-maily zobrazují špatné datum po migraci pro kompletní technické vysvětlení.
Příliš brzká deaktivace zdrojového serveru
Pokud se problémy s datumy objeví po vypnutí zdrojového serveru, možnost opětovné migrace zmizí. Ponechte zdrojový server přístupný (třeba jen pro čtení) alespoň 30 dní po migraci. To poskytuje záchranné řešení, pokud se později objeví vážné problémy.
Co dělat, když jsou datumy již špatné
Pokud migrace již proběhla a datumy jsou nesprávné, problém je opravitelný. Původní hlavička "Date" je zachována v každém e-mailu, což znamená, že správná informace o datu stále existuje. Datumy e-mailů je možné opravit i po migraci, a to i měsíce nebo roky poté.
Proprietární opravný engine Redate.io se připojí ke schránce a vyhledá e-maily s poškozenými datovými metadaty. Vícestupňový analytický pipeline identifikuje migrační podpisy, aplikuje cílené opravy při zachování integrity zpráv (včetně podpisů S/MIME, multipart struktur a hlaviček s ne-ASCII znaky) a provede kontrolu integrity na každém opraveném e-mailu. Analýza je zdarma a ukáže přesně, kolik e-mailů je postiženo. Originály jsou uchovány v záložní složce viditelné po dobu 30 dní.
Pokoušet se o takovou opravu ručně nebo vlastním skriptem je lákavé, ale riskantní. Speciální případy jako PGP šifrované zprávy, poškozené MIME hranice, vnořené multipart struktury a nesrovnalosti v Content-Transfer-Encoding mohou tiše poškodit e-maily, aniž byste si toho všimli, než bude příliš pozdě. A jak ověříte, že 10 000 opravených e-mailů je všech neporušených?
Chcete zjistit, zda má Vaše schránka problémy s datumy? Spusťte bezplatnou analýzu pomocí Redate.io - žádná platba není potřeba k zobrazení počtu postižených e-mailů.