BitTitan MigrationWiz: oprava chybných dat e-mailů

Co BitTitan MigrationWiz dělá s daty e-mailů

Migrace skončila minulý pátek. 47 poštovních schránek přesunuto z lokálního Exchange na Microsoft 365, v panelu MigrationWiz je vše zelené. Pak přišlo pondělní ráno a dorazil první ticket: "Všechny moje e-maily ukazují 28. března 2026."

Každá jediná zpráva. Roky korespondence, nabídky klientům z roku 2019, faktury z roku 2021, vše opatřeno datem migrace. Log MigrationWiz říká, že vše bylo úspěšně přeneseno (a technicky vzato bylo). Ale data zmizela.

BitTitan MigrationWiz je jedním z nejpoužívanějších nástrojů pro migraci e-mailů mezi cloudovými služby. Zvládá Exchange na Microsoft 365, Google Workspace na Exchange, přesuny mezi tenanty, zkrátka všechno. Nástroj sám funguje dobře. Problém s daty není chyba MigrationWiz. Je to důsledek fungování migrace na úrovni IMAP protokolu a MigrationWiz tento mechanismus spouští specifickým způsobem.

Vlastně to zjistíte až zpětně. Během samotné migrace žádná upozornění nepřijdou, všechny statusy svítí zeleně. Uživatelé si to uvědomí teprve tehdy, když se pokusí vyhledat e-mail podle data nebo seřadit konverzaci chronologicky.

Jak MigrationWiz zachází s hlavičkami Received

Když MigrationWiz přenáší e-mail ze zdroje na cíl, používá protokol IMAP (nebo Exchange Web Services, podle typu koncového bodu). Během tohoto procesu cílový poštovní server opatří zprávu novou hlavičkou Received: s aktuálním časovým razítkem, přesně stejně jako by to udělal s jakýmkoli příchozím e-mailem.

Typický řetězec hlaviček Received po migraci MigrationWiz vypadá takto:

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

Původní hlavička Received: z roku 2019 tam stále je. Stejně tak původní hlavička Date:. Ale poštovní klienti jako Outlook je nepoužívají. Outlook čte nejnovější hlavičku Received: pro určení data zobrazení zprávy, a ta nyní říká 28. března 2026.

Hodnota INTERNALDATE (časové razítko, které IMAP servery používají k řazení) se při přenosu také přepíše. MigrationWiz se pokouší zachovat data, když to cíl podporuje, ale výsledek silně závisí na chování cílového serveru. Transportní pipeline Microsoft 365 například přepíše INTERNALDATE vlastním razítkem doručení bez ohledu na to, co MigrationWiz požaduje.

Proč Date Mapping v MigrationWiz nestačí

BitTitan nabízí funkci "Date Mapping" v Pokročilých Možnostech MigrationWiz. Na papíře to zní jako řešení. Vlastně? Tato funkce kontroluje, z jakého rozsahu dat se budou zprávy migrovat, nikoli jak se data uchovávají na cílovém serveru.

Nedorozumění je pochopitelné. Nastavení má v názvu "date". Ale ve skutečnosti filtruje zdrojové zprávy podle rozsahu dat před migrací. Zpráva z roku 2018 stejně dorazí na cíl s časovým razítkem migrace.

Je tu ještě otázka IMAP versus Exchange. Když MigrationWiz migruje mezi dvěma Exchange servery pomocí EWS (Exchange Web Services), zachování dat funguje lépe, protože EWS má větší kontrolu nad metadaty zpráv. Ale jakmile vstoupí do hry IMAP na kterékoli straně (zdroj nebo cíl), operace IMAP APPEND převezme kontrolu a cílový server rozhodne, jaké časové razítko použít.

Někteří správci zkusili spustit migraci znovu s jinými konfiguracemi koncových bodů v naději, že přepnutí z IMAP na EWS opraví data zpětně. Neopraví. Zprávy už jsou na cíli se špatnými daty. Opětovné spuštění MigrationWiz by jen vytvořilo duplikáty.

Konkrétní scénáře MigrationWiz, které kazí data

Ne každá migrace MigrationWiz způsobuje problémy s daty. Záleží na kombinaci koncových bodů:

• Exchange (lokální) do Microsoft 365 přes IMAP: Data se kazí. Transportní pipeline M365 přidává nové hlavičky Received a přepisuje INTERNALDATE.
• Google Workspace do Microsoft 365: Data se kazí. MigrationWiz čte z Googlu přes IMAP a zapisuje do M365, který přidává vlastní transportní hlavičky.
• Exchange do Exchange (EWS do EWS): Data se obvykle zachovají. EWS obchází transportní pipeline na obou stranách.
• Cokoli do Google Workspace přes IMAP: Data se kazí. Implementace IMAP od Googlu přidává hlavičku Received s razítkem vložení.
• Cross-tenant Microsoft 365: Závisí na metodě. IMAP cesta kazí data. Přímé EWS je může zachovat.

Panel MigrationWiz problémy s daty nehlásí. Vše se zobrazuje jako "Completed", protože zprávy se skutečně přenesly úspěšně. Obsah je neporušený, přílohy v pořádku, struktura složek zachovaná. Změnila se jen data a MigrationWiz to nesleduje jako chybu migrace.

Skutečná cena špatných dat po MigrationWiz

Špatná data e-mailů nejsou jen nepříjemnost. Pro organizace, které migrovaly s BitTitan, sahají důsledky daleko za nepořádek v doručené poště.

Právní oddělení nemohou e-maily používat jako důkazy, když každá zpráva ukazuje datum migrace místo skutečného data odeslání. Daňové kontroly vyžadují chronologický důkaz komunikace. Regulační rámce jako GDPR vyžadují přesné vedení záznamů a e-maily s falešnými časovými razítky tento požadavek nesplňují.

A pak je tu praktická stránka. Zkuste najít diskuzi o smlouvě z listopadu 2022, když celá Vaše schránka ukazuje březen 2026. Seřadit podle data? Nepoužitelné. Hledat podle rozsahu dat? Vrátí buď všechno, nebo nic.

Pro MSP, kteří použili MigrationWiz v klientských prostředích, to vytváří problém odpovědnosti. Klient zaplatil za migraci. Dostal ji, ale jeho e-mailový archiv je prakticky nepoužitelný pro pracovní postupy závislé na datech.

Jeden MSP, o kterém víme, přesunul asi 380 poštovních schránek pro advokátní kancelář. O tři měsíce později litgační tým kanceláře objevil problém s daty během procesu discovery. Každý e-mail, který potřebovali předložit jako důkaz, ukazoval datum migrace. MSP musel vysvětlovat, proč 6 let korespondence s časovými razítky nyní ukazuje červen 2025.

Oprava dat BitTitan MigrationWiz

Původní hlavička Date: se stále nachází uvnitř každého e-mailu. MigrationWiz nesahá na tělo zprávy ani na původní hlavičky. Problém se zobrazením způsobuje přidaná hlavička Received: a přepsaná hodnota INTERNALDATE.

Redate.io se připojí k poštovní schránce (Google Workspace, Microsoft 365 nebo IMAP), prohledá e-maily zasažené migrací MigrationWiz a opraví metadata dat prostřednictvím proprietárního vícestupňového analytického procesu. Oprava cílí konkrétně na vrstvu metadat s porovnáváním vzorů známých signatur hlaviček MigrationWiz, včetně charakteristických identifikátorů mx.migrationwiz.com a bittitan.com v řetězci Received.

Každý opravený e-mail se individuálně ověřuje oproti originálu. Ověření kontroluje integritu zprávy, zachování příloh, umístění ve složkách a vlákna konverzací. Originální e-maily zůstávají ve viditelné složce Redate.io - Originals po dobu 30 dní pro případ potřeby vrácení změn.

Pochopit problém je jedna věc. Opravit 15 000 e-mailů bez ztráty jediné přílohy, poškození podpisů S/MIME nebo narušení multipart MIME hranic, to je věc zcela jiná. Skript, který funguje na 10 testovacích zprávách v laboratoři, nezvládne okrajové případy produkční schránky se 7 lety korespondence, PGP šifrovanými zprávami a hlavičkami RFC 2047 s ne-ASCII znaky.

Mimochodem, jak ověříte, že je každá opravená zpráva neporušená? Že vlákna konverzací stále fungují, že pozvánky do kalendáře se stále správně interpretují, že ten 47MB příloha z e-mailu z roku 2020 se nepoškodila? Redate.io toto dělá automaticky, pro každou jednotlivou zprávu. A pokud něco vypadá podezřele, originál je přímo ve složce zálohy.

Bezplatný sken trvá přibližně dvě minuty. Připojí se ke schránce, identifikuje každý e-mail s razítkem data migrace MigrationWiz a ukáže přesný počet a cenu, než cokoli zaplatíte. Bez platební karty, bez závazků.

Návody k opravě pro konkrétní platformy

Proces opravy se liší podle toho, kam MigrationWiz přesunul Vaše e-maily. Redate.io zpracovává specifika každé platformy automaticky, ale pokud chcete podrobnosti ke své konfiguraci:

• Opravit data BitTitan v Outlooku
• Opravit data BitTitan v Microsoft 365
• Opravit data BitTitan v Google Workspace
• Opravit data BitTitan v Exchange Online

Redate.io funguje i pro migrace dokončené před měsíci nebo lety. Původní hlavička Date nemá datum expirace. I když od migrace uplynuly dva roky, oprava funguje se stejnou přesností, protože zdrojová data zůstávají uvnitř každého e-mailu.

Migrovali jste s BitTitan MigrationWiz a zůstala Vám špatná data? Spusťte bezplatný sken a zjistěte, kolik e-mailů je zasaženo, než se k čemukoli zavážete.