BitTitan MigrationWiz: corectarea datelor greșite

Ce face BitTitan MigrationWiz cu datele emailurilor

Migrația s-a terminat vinerea trecută. 47 de căsuțe poștale mutate de pe Exchange local pe Microsoft 365, totul verde în panoul MigrationWiz. Apoi a venit lunea dimineața și a apărut primul ticket: "Toate emailurile mele arată 28 martie 2026."

Fiecare mesaj. Ani de corespondență, propuneri pentru clienți din 2019, facturi din 2021, toate ștampilate cu data migrației. Jurnalul MigrationWiz spune că totul s-a transferat cu succes (și tehnic chiar s-a transferat). Dar datele au dispărut.

BitTitan MigrationWiz este unul dintre cele mai utilizate instrumente pentru migrarea emailurilor între servicii cloud. Gestionează Exchange către Microsoft 365, Google Workspace către Exchange, mutări între tenanți, practic orice. Instrumentul în sine funcționează bine. Problema cu datele nu este un bug al MigrationWiz. Este o consecință a modului în care funcționează migrația IMAP la nivel de protocol, iar MigrationWiz declanșează acest mecanism într-un mod specific.

Cum gestionează MigrationWiz headerele Received

Când MigrationWiz transferă un email de la sursă la destinație, folosește protocolul IMAP (sau Exchange Web Services, în funcție de tipul endpointului). În timpul acestui proces, serverul de destinație aplică mesajului un nou header Received: cu marca temporală curentă, exact așa cum ar face cu orice email primit.

Un lanț tipic de headere Received după o migrație MigrationWiz arată așa:

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

Headerul original Received: din 2019 este încă acolo. La fel și headerul original Date:. Dar clienții de email precum Outlook nu le folosesc. Outlook citește cel mai recent header Received: pentru a determina când să afișeze mesajul, iar acesta spune acum 28 martie 2026.

Valoarea INTERNALDATE (marca temporală pe care serverele IMAP o folosesc pentru sortare) este de asemenea suprascrisă în timpul transferului. MigrationWiz încearcă să păstreze datele când destinația suportă acest lucru, dar rezultatul depinde în mare măsură de comportamentul serverului de destinație. Pipeline-ul de transport al Microsoft 365, de exemplu, suprascrie INTERNALDATE cu propria marcă temporală de livrare, indiferent de ce solicită MigrationWiz.

De ce Date Mapping din MigrationWiz nu este suficient

BitTitan oferă o funcție "Date Mapping" în Opțiunile Avansate ale MigrationWiz. Pe hârtie, pare soluția. În practică? Controlează ce interval de date al mesajelor se migrează, nu cum sunt păstrate datele la destinație.

Confuzia este de înțeles. Setarea conține cuvântul "date" în nume. Dar de fapt ceea ce face este să filtreze mesajele sursă după interval de date înainte de migrație. Un mesaj din 2018 ajunge tot cu marca temporală a migrației la destinație.

Mai există și chestiunea IMAP versus Exchange. Când MigrationWiz migrează între două servere Exchange folosind EWS (Exchange Web Services), păstrarea datelor funcționează mai bine deoarece EWS are mai mult control asupra metadatelor mesajelor. Dar în momentul în care IMAP intervine pe oricare parte (sursă sau destinație), operațiunea IMAP APPEND preia controlul și serverul de destinație decide ce marcă temporală să folosească.

Unii administratori au încercat să reexecute migrația cu configurații diferite ale endpointurilor, sperând că trecerea de la IMAP la EWS va corecta datele retroactiv. Nu corectează. Mesajele sunt deja la destinație cu date greșite. Rularea din nou a MigrationWiz ar crea doar duplicate.

Scenarii specifice MigrationWiz care strică datele

Nu fiecare migrație MigrationWiz cauzează probleme cu datele. Problema depinde de combinația de endpointuri:

• Exchange (local) către Microsoft 365 prin IMAP: Datele se strică. Pipeline-ul de transport M365 adaugă noi headere Received și suprascrie INTERNALDATE.
• Google Workspace către Microsoft 365: Datele se strică. MigrationWiz folosește IMAP pentru a citi din Google și scrie în M365, care adaugă propriile headere de transport.
• Exchange către Exchange (EWS către EWS): Datele sunt de obicei păstrate. EWS ocolește pipeline-ul de transport pe ambele părți.
• Orice către Google Workspace prin IMAP: Datele se strică. Implementarea IMAP a Google adaugă un header Received cu marca temporală de inserare.
• Cross-tenant Microsoft 365: Depinde de metodă. Calea IMAP strică datele. EWS direct le poate păstra.

Panoul MigrationWiz nu semnalează problemele cu datele. Totul apare ca "Completed" deoarece mesajele chiar s-au transferat cu succes. Conținutul este intact, atașamentele sunt în regulă, structura folderelor este păstrată. Doar datele s-au schimbat, iar MigrationWiz nu urmărește acest lucru ca o eroare de migrație.

Costul real al datelor greșite după MigrationWiz

Datele greșite ale emailurilor nu sunt doar o neplăcere. Pentru organizațiile care au migrat cu BitTitan, consecințele depășesc un inbox dezordonat.

Echipele juridice nu pot folosi emailurile ca probe când fiecare mesaj afișează data migrației în locul datei reale de trimitere. Auditurile fiscale necesită dovezi cronologice ale comunicărilor. Cadrele de conformitate precum GDPR impun păstrarea exactă a înregistrărilor, iar emailurile cu mărci temporale false nu îndeplinesc această cerință.

Apoi este și partea practică. Încercați să găsiți discuția despre contractul din noiembrie 2022 când întreaga căsuță poștală arată martie 2026. Sortare după dată? Inutilă. Căutare după interval de date? Returnează totul sau nimic.

Pentru MSP-urile care au folosit MigrationWiz în mediile clienților, aceasta creează o problemă de răspundere. Clientul a plătit pentru o migrație. A primit-o, dar arhiva de email este practic inutilizabilă pentru fluxurile de lucru bazate pe date.

Un MSP despre care am aflat migrase circa 380 de căsuțe poștale pentru o firmă de avocatură. Trei luni mai târziu, echipa de litigii a firmei a descoperit problema cu datele în timpul procesului de descoperire a documentelor. Fiecare email pe care trebuiau să-l prezinte ca probă arăta data migrației. MSP-ul a trebuit să explice de ce 6 ani de corespondență cu mărci temporale arătau acum iunie 2025.

Corectarea datelor BitTitan MigrationWiz

Headerul original Date: se află încă în interiorul fiecărui email. MigrationWiz nu atinge corpul mesajului sau headerele originale. Problema de afișare este cauzată de headerul Received: adăugat și de valoarea INTERNALDATE suprascrisă.

Redate.io se conectează la căsuța poștală (Google Workspace, Microsoft 365 sau IMAP), scanează emailurile afectate de migrația MigrationWiz și corectează metadatele de dată printr-un pipeline de analiză multi-etapă proprietar. Corecția vizează specific stratul de metadate, cu potrivire de tipare ale semnăturilor cunoscute ale headerelor MigrationWiz, inclusiv identificatorii caracteristici mx.migrationwiz.com și bittitan.com din lanțul Received.

Fiecare email corectat este verificat individual în raport cu originalul. Verificarea acoperă integritatea mesajului, păstrarea atașamentelor, plasarea în foldere și fire de conversație. Emailurile originale rămân într-un folder vizibil Redate.io - Originals timp de 30 de zile în cazul în care este necesară o revenire.

Să înțelegi problema este un lucru. Să corectezi 15.000 de emailuri fără a pierde un singur atașament, fără a deteriora semnăturile S/MIME sau a corupe limitele multipart MIME, este cu totul altceva. Un script care funcționează pe 10 mesaje de test în laborator nu va face față cazurilor limită ale unei căsuțe poștale de producție cu 7 ani de corespondență, mesaje criptate PGP și headere RFC 2047 cu caractere non-ASCII.

De fapt, cum verificați că fiecare mesaj corectat este intact? Că firele de conversație funcționează, că invitațiile din calendar se rezolvă, că atașamentul de 47 MB de la emailul din 2020 nu s-a corupt? Redate.io face aceasta automat, pentru fiecare mesaj în parte. Iar dacă ceva pare suspect, originalul se află chiar acolo, în folderul de backup.

Scanarea gratuită durează aproximativ două minute. Se conectează la căsuța poștală, identifică fiecare email marcat cu data migrației MigrationWiz și arată numărul exact și costul înainte de a plăti ceva. Fără card de credit, fără angajament.

Ghiduri de corectare specifice platformei pentru BitTitan

Procesul de corectare variază în funcție de unde a mutat MigrationWiz emailurile. Redate.io gestionează automat specificul fiecărei platforme, dar dacă doriți detalii despre configurația dumneavoastră:

• Corectare date BitTitan in Outlook
• Corectare date BitTitan in Microsoft 365
• Corectare date BitTitan in Google Workspace
• Corectare date BitTitan in Exchange Online

Redate.io funcționează și pentru migrații finalizate cu luni sau ani în urmă. Headerul original Date nu expiră.

Ați migrat cu BitTitan MigrationWiz și ați rămas cu date greșite? Rulați o scanare gratuită pentru a vedea exact câte emailuri sunt afectate, înainte de a vă angaja la ceva.