CloudM Migrate: ako opraviť nesprávne dátumy

Problém s dátumami v CloudM Migrate, na ktorý vás nikto neupozorní

CloudM Migrate dokončil úlohu. Ovládací panel ukazuje 100 % dokončené, všetci používatelia migrovaní, nula chýb. Uzavriete projektový tiket a prejdete na ďalšieho klienta.

Potom o týždeň neskôr zavolá IT riaditeľ. "Prečo každý e-mail v mojej schránke ukazuje 2. apríl?"

Nie niektoré e-maily. Všetky. Päť rokov klientskej korešpondencie, právne dokumenty, HR záznamy, objednávky z roku 2020, všetko zobrazuje dátum, kedy CloudM spustil migráciu. Správy sú na mieste, obsah je neporušený, prílohy v poriadku. Ale dátumy sú nesprávne na každom jednom e-maile.

Toto nie je chyba CloudM. Vlastná dokumentácia podpory CloudM to otvorene uznáva. Problém leží na priesečníku spôsobu, akým migračné nástroje prenášajú správy, a spôsobu, akým cieľové poštové servery spracúvajú metadáta prichádzajúcej e-pošty. Ale vedieť to nepomôže vášmu klientovi, ktorého schránka je teraz netriediteľná.

Ako CloudM v skutočnosti prenáša e-mailové správy

CloudM Migrate sa pripája k zdrojovej a cieľovej platforme cez ich API. Pre Google Workspace to znamená servisný účet s delegáciou na úrovni domény (konfigurovaný v Google Admin Console v časti Zabezpečenie > Ovládacie prvky API). Pre Microsoft 365 používa buď Exchange Web Services, alebo Microsoft Graph API, v závislosti od migračnej cesty.

Keď CloudM prečíta správu zo zdroja, získa kompletný obsah RFC 2822 vrátane všetkých pôvodných hlavičiek a tela správy. Pôvodná hlavička Date: (tá, ktorú poštový server odosielateľa označil pri prvom odoslaní e-mailu) prichádza nedotknutá. Rovnako všetky pôvodné hlavičky Received:, ktoré sledujú doručovaciu cestu správy.

Problém nastáva na cieľovej strane. Keď CloudM zapíše túto správu do cieľovej schránky, cieľový server ju považuje za novú doručenú správu. Pridá novú hlavičku Received: s aktuálnym dátumom a časom a nastaví INTERNALDATE (časová pečiatka, ktorú IMAP používa na triedenie) na okamih vloženia.

Takto vyzerá reťazec hlavičiek po migrácii CloudM do Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Hlavička z roku 2019 je priamo tam. Pôvodná hlavička Date: stále hovorí 23. september 2019. Ale Outlook číta najnovšiu hlavičku Received: na určenie poradia zobrazenia a tá teraz hovorí 2. apríl 2026.

Nastavenie "Strip Received Headers" v CloudM

CloudM ponúka nastavenie na riešenie tohto problému. V rozšírených nastaveniach cieľovej platformy, v časti Možnosti správ, sa nachádza prepínač "Strip Received Headers". Po aktivácii CloudM odstráni hlavičky received pred vložením správy a nahradí ich jednou hlavičkou zodpovedajúcou hlavičke Date: e-mailu.

Znie to, ako keby to vyriešilo všetko, však? Nie celkom.

Po prvé, o tomto nastavení musíte vedieť pred spustením migrácie. Väčšina administrátorov objaví problém s dátumami až po dokončení migrácie. V tom okamihu správy už sedia na cieli s nesprávnymi dátumami. Opätovné spustenie CloudM s aktivovaným nastavením len vytvára duplikáty, neopravuje to, čo tam už je.

Po druhé, toto nastavenie má závažné obmedzenie, keď je cieľom Google Workspace. Vlastná dokumentácia Google to potvrdzuje: Gmail vždy prepisuje hlavičky Received: na správach vložených cez API a označuje ich časovou pečiatkou vloženia. Ide o obmedzenie na úrovni platformy, ktoré CloudM nemôže obísť. Aj s aktivovaným "Strip Received Headers" Google Workspace pridáva vlastnú hlavičku Received: s dátumom migrácie.

Pre ciele Microsoft 365 nastavenie funguje v teórii lepšie, ale transportný pipeline M365 má vlastné správanie. Exchange Online môže stále nastaviť INTERNALDATE na základe vlastného spracovania doručenia, v závislosti od toho, ako správa vstúpi do systému.

Ktoré migrácie CloudM poškodia dátumy (a ktoré nie)

Nie každá migrácia CloudM produkuje nesprávne dátumy. Výsledok závisí od kombinácie zdroj-cieľ a konkrétnej API cesty, ktorú CloudM používa:

• Google Workspace do Microsoft 365: Dátumy sa poškodia. CloudM číta cez Gmail API a zapisuje do Exchange. Transportná vrstva M365 pridáva nové hlavičky Received.
• Microsoft 365 do Google Workspace: Dátumy sa poškodia. Aj so Strip Received Headers API Google prepisuje hlavičku Received dátumom vloženia. Dokumentácia podpory CloudM to nazýva "prísnym obmedzením platformy".
• Google Workspace do Google Workspace: Dátumy sa poškodia. Zmeny domény, konsolidácie tenantov, akvizičné fúzie - cieľový tenant Google vždy označí migrovaný dátum na prichádzajúce správy.
• Lokálny Exchange do Microsoft 365: Zvyčajne sa poškodí cez IMAP cestu. Ak CloudM používa EWS na oboch stranách, zachovanie dátumov je spoľahlivejšie, ale nie garantované.
• Generický zdroj IMAP do akéhokoľvek cieľa: Dátumy sa poškodia. Keď sa CloudM pripojí na generický IMAP server ako zdroj, cieľ stále pridáva vlastné doručovacie hlavičky.

Záludná časť? Ovládací panel migrácie CloudM nič z toho neoznačí. Ukazovateľ priebehu sa naplní, stĺpec stavu hovorí "Dokončené", počty položiek sa zhodujú. Z pohľadu CloudM migrácia uspela. A technicky aj uspela. Správy sa preniesli. Len dátumy cestu neprežili.

CloudM spravovaný a self-service: rovnaký problém s dátumami

CloudM ponúka dva modely nasadenia. SaaS verzia (hostovaný CloudM Migrate) beží kompletne v infraštruktúre CloudM. Verzia na vlastnom hostingu umožňuje nasadiť primárne a sekundárne migračné servery na vlastnej sieti, Google Cloud, Azure alebo AWS.

Niektorí MSP predpokladajú, že možnosť vlastného hostingu dáva väčšiu kontrolu nad spracovaním dátumov, keďže priamo spravujete migračné servery. Nedáva. Problém s dátumami nastáva na cieľovom serveri, nie na spracovateľských uzloch CloudM. Či vaša migračná farma beží v cloude CloudM alebo na vašom vlastnom Azure VM, cieľový poštový server stále označí dátum migrácie na každú správu, ktorú prijme.

CloudM tiež ponúka plne spravovanú "Serviced Migration", kde ich tím riadi projekt od začiatku do konca. Rovnaký výsledok pre dátumy. Inžiniering je identický, len ruky na klávesnici sú iné.

Komplikácia s neplatnou hlavičkou Date

Existuje ďalšie správanie špecifické pre CloudM, ktoré zhoršuje situáciu. Keď CloudM narazí na zdrojový e-mail s hlavičkou Date:, ktorá nie je v súlade s RFC 822 (chybný formát časového pásma, chýbajúci deň v týždni, neštandardný formát), upraví hlavičku, aby zabezpečil migráciu správy.

To znamená, že niektoré e-maily stratia dokonca svoju pôvodnú referenciu dátumu. Upravená hlavička Date: nemusí vôbec zodpovedať skutočnému dátumu odoslania. Dokumentácia podpory CloudM to spomína ako známe správanie pod "Možné zmeny migrovaných položiek", ale nešpecifikuje, aký sa upravený dátum stane.

Pre schránku s 12 000 správami nahromadenými počas ôsmich rokov môžete mať stovky e-mailov s mierne neštandardnými hlavičkami Date (najmä správy zo starších poštových serverov, automatizovaných systémov alebo medzinárodných odosielateľov s odlišnosťami vo formátovaní časových pásiem). Po úprave CloudM plus prepísaní hlavičky Received cieľovým serverom tieto správy skončia s dátumami, ktoré nemajú nič spoločné s realitou.

Prečo manuálne opravy po CloudM nefungujú vo veľkom

Mohli by ste to opraviť sami? Technicky je pôvodná hlavička Date: stále vložená vo väčšine správ (okrem tých, ktoré CloudM upravil pre súlad s RFC). Niektorí administrátori skúšali písať skripty na opravu dátumov po migrácii CloudM.

Realita tohto prístupu je nasledovná. Potrebujete sa pripojiť k potenciálne tisícom schránok, každá s tisíckami správ. Pre každý e-mail musíte analyzovať kompletný reťazec hlavičiek, identifikovať, ktoré hlavičky Received: pridal CloudM alebo cieľový server, spracovať okrajové prípady (S/MIME podpísané správy, kde úprava hlavičiek poškodí podpis, PGP šifrovaný obsah, viacčasťové MIME štruktúry s vnorenými hranicami, RFC 2047 kódované ne-ASCII hlavičky od japonských alebo kórejských odosielateľov) a to všetko bez straty jedinej prílohy alebo poškodenia vlákna e-mailu.

Skript, ktorý funguje na 50 testovacích e-mailoch z čistej schránky, neprežije kontakt s produkčným prostredím so 40 000 správami pokrývajúcimi desaťročie. Čo sa stane, keď narazíte na 47 MB e-mail so šiestimi vnorenými prílohami? Čo s API limitmi rýchlosti (Google-ových 250 kvótových jednotiek na používateľa za sekundu, Microsoft-ovo obmedzovanie na približne 10 000 požiadaviek za 10 minút)? Aký je váš plán na návrat, keď sa niečo pokazí na správe číslo 8 347?

A skutočná otázka, ktorú väčšina administrátorov nepoloží, kým nie je neskoro: ako overíte, že každá opravená správa je skutočne neporušená?

Oprava dátumov migrácie CloudM pomocou Redate.io

Redate.io sa priamo pripája k postihnutým schránkam (Google Workspace, Microsoft 365 alebo IMAP) a skenuje e-maily nesúce podpis dátumu migrácie CloudM. Skenovanie je bezplatné a trvá pár minút na schránku, zobrazujúc presný počet postihnutých správ pred akýmkoľvek záväzkom.

Oprava používa proprietárny motor na analýzu reťazca hlavičiek, ktorý identifikuje vzory migrácie špecifické pre CloudM v reťazci hlavičiek Received. Redate.io vykonáva cielenú opravu metadát bez zmeny obsahu správy, zachovávajúc prílohy, vlákna, štítky, priečinky a digitálne podpisy. Každá opravená správa prechádza individuálnou verifikáciou, kontrolujúc integritu správy oproti originálu pred pokračovaním procesu.

Pôvodné e-maily sa uchovávajú v viditeľnom záložnom priečinku Redate.io - Originals po dobu 30 dní. Ak je potrebné niečo vrátiť, originály sú priamo tam v schránke, nie zahrábané v nejakom externom archíve.

Pre MSP, ktorí používali CloudM v klientskych prostrediach, Redate.io zvláda opravy viacerých schránok súčasne, s rovnakou verifikáciou na správu či opravujete 1 schránku alebo 500. Problém s dátumami, ktorý CloudM zanechal, nemusí byť trvalou vlastnosťou poštového prostredia vášho klienta.

Návody pre konkrétne platformy pre migrácie CloudM

Proces opravy sa prispôsobuje cieľovej platforme. Redate.io automaticky spracúva špecifiká každej platformy, ale pre podrobnosti o vašom nastavení:

• Opravte dátumy migrácie CloudM v Gmaile
• Opravte dátumy migrácie CloudM v Outlooku
• Opravte dátumy migrácie CloudM v Google Workspace
• Opravte dátumy migrácie CloudM v Microsoft 365

Pre hlbšie vysvetlenie, prečo sa to deje naprieč všetkými migračnými nástrojmi, nielen CloudM, pozrite prečo e-maily zobrazujú nesprávne dátumy po migrácii.

Migrovali ste s CloudM a zostali s nesprávnymi dátumami na každom e-maile? Spustite bezplatné skenovanie a zistite presne, koľko správ je postihnutých a koľko stojí ich oprava.