CloudM Migrate: cum corectați datele e-mailurilor

Problema datelor CloudM Migrate despre care nimeni nu avertizeaza

CloudM Migrate și-a terminat treaba. Dashboard-ul arata 100% finalizat, toți utilizatorii migrați, zero erori. Inchideți tichetul proiectului și treceți la urmatorul client.

O saptamana mai tarziu, suna directorul IT. "De ce fiecare e-mail din inbox-ul meu arata 2 aprilie?"

Nu cateva e-mailuri. Toate. Cinci ani de corespondența cu clienții, documente juridice, dosare HR, comenzi de achiziție din 2020, toate afișeaza data la care CloudM a rulat migrarea. Mesajele sunt acolo, conținutul intact, atașamentele in ordine. Dar datele sunt greșite pe fiecare.

Nu este un bug CloudM. Documentația de suport a CloudM recunoaște deschis acest lucru. Problema se afla la intersecția dintre modul in care instrumentele de migrare transfera mesajele și modul in care serverele de e-mail destinație gestioneaza metadatele e-mailurilor primite. Dar cunoașterea acestui lucru nu ajuta clientul dumneavoastra al carui inbox a devenit imposibil de sortat.

Cum transfera CloudM de fapt mesajele e-mail

CloudM Migrate se conecteaza la platformele sursa și destinație prin API-urile lor. Pentru Google Workspace, aceasta inseamna un cont de serviciu cu delegare la nivel de domeniu (configurat in Google Admin Console la Security > API Controls). Pentru Microsoft 365, folosește Exchange Web Services sau Microsoft Graph API, in funcție de traseul migrarii.

Cand CloudM citește un mesaj din sursa, obține conținutul RFC 2822 complet, inclusiv toate headerele originale și corpul mesajului. Headerul original Date: (cel pe care serverul de e-mail al expeditorului l-a aplicat cand e-mailul a fost trimis prima data) vine intact. La fel și toate headerele originale Received: care urmaresc traseul de livrare al mesajului.

Problema apare la destinație. Cand CloudM scrie mesajul in casuta poștala destinație, serverul destinație il trateaza ca pe o livrare noua. Aplica un header Received: proaspat cu data și ora curenta și seteaza INTERNALDATE (marca temporala pe care IMAP o folosește pentru sortare) la momentul inserarii.

Iata cum arata lanțul de headere dupa o migrare CloudM catre 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

Headerul din 2019 este chiar acolo. Headerul original Date: inca spune 23 septembrie 2019. Dar Outlook citește cel mai recent header Received: pentru ordinea de afișare, iar acela spune 2 aprilie 2026.

Setarea "Strip Received Headers" a CloudM

CloudM ofera o setare pentru aceasta. In Advanced Settings ale platformei destinație, sub Message Options, exista un comutator "Strip Received Headers". Cand este activat, CloudM elimina headerele received inainte de inserarea mesajului și le inlocuiește cu un singur header care corespunde headerului Date: al e-mailului.

Pare sa rezolve totul, nu? Nu chiar.

In primul rand, trebuie sa știți despre aceasta setare inainte de a rula migrarea. Majoritatea administratorilor descopera problema datelor dupa finalizarea migrarii. In acel moment, mesajele sunt deja in destinație cu date greșite. Rerularea CloudM cu setarea activata doar creeaza duplicate, nu repara ce exista deja.

In al doilea rand, aceasta setare are o limitare serioasa cand destinația este Google Workspace. Documentația Google confirma: Gmail rescrie intotdeauna headerele Received: pe mesajele inserate prin API, aplicand marca temporala de inserare. Aceasta este o restricție la nivel de platforma pe care CloudM nu o poate depași. Chiar și cu "Strip Received Headers" activat, Google Workspace adauga propriul header Received: cu data migrarii.

Pentru destinații Microsoft 365, setarea funcționeaza mai bine in teorie, dar pipeline-ul de transport M365 are propriul comportament. Exchange Online poate seta INTERNALDATE pe baza propriei procesari de livrare, in funcție de modul in care mesajul intra in sistem.

Care migrari CloudM strica datele (și care nu)

Nu fiecare migrare CloudM produce date greșite. Rezultatul depinde de combinația sursa-destinație și de traseul API specific pe care il folosește CloudM:

• Google Workspace catre Microsoft 365: Datele se strica. CloudM citește prin Gmail API și scrie in Exchange. Stratul de transport M365 aplica noi headere Received.
• Microsoft 365 catre Google Workspace: Datele se strica. Chiar și cu Strip Received Headers, API-ul Google rescrie headerul Received cu data inserarii. Documentația de suport CloudM numește aceasta "restricție stricta de platforma".
• Google Workspace catre Google Workspace: Datele se strica. Schimbari de domeniu, consolidari de tenanți, fuziuni dupa achiziții, tenantul Google destinație aplica intotdeauna data migrarii pe mesajele primite.
• Exchange on-premises catre Microsoft 365: De obicei se strica prin traseul IMAP. Daca CloudM folosește EWS pe ambele parți, pastrarea datelor este mai fiabila dar nu garantata.
• Sursa IMAP generica catre orice destinație: Datele se strica. Cand CloudM se conecteaza la un server IMAP generic ca sursa, destinația tot adauga propriile headere de livrare.

Partea dificila? Dashboard-ul de migrare CloudM nu semnaleaza nimic din toate acestea. Bara de progres se umple, coloana de status spune "Completed", numaratorile de elemente se potrivesc. Din perspectiva CloudM, migrarea a reușit. Tehnic, da. Mesajele s-au transferat. Doar datele nu au supraviețuit calatoriei.

CloudM Managed vs. Self-Service: aceeași problema cu datele

CloudM ofera doua modele de implementare. Versiunea SaaS (CloudM Migrate gazduit) ruleaza in intregime in infrastructura CloudM. Versiunea self-hosted permite implementarea serverelor de migrare primare și secundare in propria rețea, Google Cloud, Azure sau AWS.

Unii MSP presupun ca opțiunea self-hosted ofera mai mult control asupra gestionarii datelor, deoarece serverele de migrare sunt administrate direct. Nu ofera. Problema datelor apare la serverul destinație, nu pe nodurile de procesare CloudM. Indiferent daca ferma de migrare ruleaza in cloudul CloudM sau pe propria VM Azure, serverul de e-mail destinație aplica data migrarii pe fiecare mesaj primit.

CloudM ofera și "Serviced Migration" complet administrata, unde echipa lor gestioneaza proiectul de la inceput pana la sfarsit. Același rezultat pentru date. Ingineria este identica, doar mainile de pe tastatura sunt diferite.

Complicația headerului Date invalid

Exista inca un comportament specific CloudM care inrautațește lucrurile. Cand CloudM intalnește un e-mail sursa cu un header Date: care nu respecta RFC 822 (fus orar malformat, zi a saptamanii lipsa, format nestandardizat), modifica headerul pentru a asigura posibilitatea migrarii mesajului.

Aceasta inseamna ca unele e-mailuri pierd chiar și referința originala a datei. Headerul Date: modificat poate sa nu corespunda deloc datei reale de trimitere. Documentația de suport CloudM menționeaza aceasta ca un comportament cunoscut sub "Possible Changes to Migrated Items", dar nu specifica ce devine data modificata.

Pentru o casuta poștala cu 12.000 de mesaje acumulate pe parcursul a opt ani, pot exista sute de e-mailuri cu headere Date ușor nestandardizate. Dupa modificarea CloudM plus rescrierea headerului Received de catre serverul destinație, aceste mesaje ajung cu date care nu au nicio legatura cu realitatea.

De ce reparațiile manuale nu scaleaza dupa CloudM

Puteți repara singuri? Tehnic, headerul original Date: este inca incorporat in majoritatea mesajelor (cu excepția celor pe care CloudM le-a modificat pentru conformitate RFC). Unii administratori au incercat sa scrie scripturi pentru corectarea datelor dupa o migrare CloudM.

Realitatea acestei abordari: trebuie sa va conectați la potențial mii de casuțe poștale, fiecare cu mii de mesaje. Pentru fiecare e-mail, trebuie sa analizați lanțul complet de headere, sa identificați care headere Received: au fost adaugate de CloudM sau de serverul destinație, sa gestionați cazurile limita (mesaje semnate S/MIME unde modificarea headerului sparge semnatura, conținut criptat PGP, structuri MIME multipart cu limite imbricate, headere non-ASCII codate RFC 2047 de la expeditori japonezi sau coreeni), și sa faceți toate acestea fara a pierde un singur atașament sau a strica threadurile de e-mail.

Un script care funcționeaza pe 50 de e-mailuri de test nu va supraviețui contactului cu un mediu de producție de 40.000 de mesaje pe un deceniu. Ce se intampla cand intalnește un e-mail de 47 MB cu șase atașamente imbricate? Dar limitele API (250 unitați de cota Google per utilizator pe secunda, throttling-ul Microsoft la aproximativ 10.000 de cereri pe 10 minute)? Care este planul de rollback cand ceva merge prost la mesajul numarul 8.347?

Corectarea datelor migrarii CloudM cu Redate.io

Redate.io se conecteaza direct la casuțele poștale afectate (Google Workspace, Microsoft 365 sau IMAP) și scaneaza e-mailurile care poarta semnatura datei de migrare CloudM. Scanarea este gratuita și dureaza cateva minute per casuta poștala, aratand numarul exact de mesaje afectate inainte de orice angajament.

Corectarea folosește un motor proprietar de analiza a lanțului de headere care identifica modele de migrare specifice CloudM in lanțul de headere Received. Redate.io efectueaza corecție țintita de metadate fara a altera conținutul mesajelor, pastrind atașamentele, threadurile, etichetele, folderele și semnaturile digitale. Fiecare mesaj corectat trece prin verificare individuala, verificand integritatea mesajului fața de original.

E-mailurile originale sunt pastrate intr-un folder de backup vizibil Redate.io - Originals timp de 30 de zile. Daca ceva trebuie restaurat, originalele sunt chiar acolo in casuta poștala.

Pentru MSP-urile care au folosit CloudM in mediile clienților, Redate.io gestioneaza corecții pe casuțe poștale multiple la scara, cu aceeași verificare per mesaj indiferent daca reparați 1 casuta sau 500.

Ghiduri specifice platformei pentru migrari CloudM

Procesul de corecție se adapteaza la platforma destinație. Redate.io gestioneaza automat specificul fiecarei platforme, dar pentru detalii despre configurația dumneavoastra:

• Corectarea datelor migrarii CloudM in Gmail
• Corectarea datelor migrarii CloudM in Outlook
• Corectarea datelor migrarii CloudM in Google Workspace
• Corectarea datelor migrarii CloudM in Microsoft 365

Pentru o explicație mai aprofundata a motivului pentru care se intampla cu toate instrumentele de migrare (nu doar CloudM), consultați de ce e-mailurile afișeaza date greșite dupa migrare.

Ați migrat cu CloudM și ați ramas cu date greșite pe fiecare e-mail? Rulați o scanare gratuita pentru a vedea cate mesaje sunt afectate și cat costa corectarea.