BitTitan MigrationWiz: korjaa väärät päivämäärät

Mitä BitTitan MigrationWiz tekee sähköpostien päivämäärille

Siirto valmistui viime perjantaina. 47 postilaatikkoa siirretty on-prem Exchangesta Microsoft 365:een, kaikki vihreällä MigrationWiz-hallintapaneelissa. Sitten tulee maanantaiaamu ja ensimmäinen tiketti saapuu: "Kaikki sähköpostini näyttävät 28. maaliskuuta 2026."

Jokainen yksittäinen viesti. Vuosien kirjeenvaihto, asiakastarjoukset vuodelta 2019, laskut vuodelta 2021, kaikki leimattu siirtopäivämäärällä. MigrationWiz-loki kertoo, että kaikki siirtyi onnistuneesti (ja teknisesti se pitää paikkansa). Mutta päivämäärät ovat kadonneet.

BitTitan MigrationWiz on yksi käytetyimmistä työkaluista cloud-to-cloud-sähköpostisiirtoon. Se hoitaa Exchangen Microsoft 365:een, Google Workspacen Exchangeen, cross-tenant-siirrot ja paljon muuta. Työkalu itsessään toimii hyvin siihen, mihin se on tarkoitettu. Päivämääräongelma ei ole MigrationWizin bugi. Se on seuraus siitä, miten IMAP-protokolla toimii kuljetustasolla, ja MigrationWiz laukaisee sen tietyllä tavalla.

Miten MigrationWiz käsittelee Received-otsakkeita

Kun MigrationWiz siirtää sähköpostin lähteestä kohteeseen, se käyttää IMAP-protokollaa (tai Exchange Web Servicesiä, riippuen päätepisteen tyypistä). Tämän prosessin aikana kohteen sähköpostipalvelin leimaa viestin uudella Received:-otsakkeella, joka sisältää nykyisen aikaleiman, täsmälleen samalla tavalla kuin se tekisi mille tahansa saapuvalle sähköpostille.

Näin tyypillinen Received-otsakeketju näyttää MigrationWiz-siirron jälkeen:

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

Alkuperäinen Received:-otsake vuodelta 2019 on yhä tallessa. Samoin alkuperäinen Date:-otsake. Mutta sähköpostiohjelmat kuten Outlook eivät käytä niitä. Outlook lukee uusimman Received:-otsakkeen määrittääkseen, milloin viesti näytetään, ja se otsake sanoo nyt 28. maaliskuuta 2026.

INTERNALDATE-arvo (aikaleima, jota IMAP-palvelimet käyttävät lajitteluun) ylikirjoitetaan myös siirron aikana. MigrationWiz yrittää säilyttää päivämäärät, kun kohde tukee sitä, mutta tulos riippuu vahvasti kohdepalvelimen käyttäytymisestä. Microsoft 365:n kuljetusputki esimerkiksi ylikirjoittaa INTERNALDATE-arvon omalla toimitusaikaleimallaan riippumatta siitä, mitä MigrationWiz pyytää.

Miksi MigrationWizin "Date Mapping" ei riitä

BitTitan tarjoaa "Date Mapping" -toiminnon MigrationWizin Lisäasetuksissa. Paperilla se kuulostaa ratkaisulta. Käytännössä se hallitsee, minkä päivämäärävälin viestit siirretään, ei sitä, miten päivämäärät säilyvät kohteessa.

Sekaannus on ymmärrettävä. Asetus sisältää sanan "date". Mutta mitä se oikeastaan tekee, on suodattaa lähdeviestejä päivämäärävälin mukaan ennen siirtoa. Vuoden 2018 viesti saapuu silti kohteeseen siirron aikaleimalla.

Sitten on kysymys IMAP- vastaan Exchange-päätepisteistä. Kun MigrationWiz siirtää kahden Exchange-palvelimen välillä EWS:n (Exchange Web Services) kautta, päivämäärien säilyminen toimii paremmin, koska EWS tarjoaa enemmän hallintaa viestien metatietoihin. Mutta heti kun IMAP on mukana kummalla tahansa puolella, IMAP APPEND -operaatio ottaa vallan ja kohdepalvelin päättää, mitä aikaleimaa käytetään.

Jotkut ylläpitäjät ovat yrittäneet ajaa siirron uudelleen eri päätepistekonfiguraatioilla toivoen, että vaihtaminen IMAP:sta EWS:ään korjaisi päivämäärät takautuvasti. Se ei toimi. Viestit ovat jo kohteessa väärillä päivämäärillä. MigrationWizin uudelleenajo loisi vain duplikaatteja.

MigrationWiz-skenaariot, jotka rikkovat päivämäärät

Kaikki MigrationWiz-siirrot eivät aiheuta päivämääräongelmia. Ongelma riippuu päätepisteyhdistelmästä:

• Exchange (on-prem) Microsoft 365:een IMAP:n kautta: Päivämäärät rikkoutuvat. M365:n kuljetusputki leimaa uudet Received-otsakkeet ja ylikirjoittaa INTERNALDATE:n.
• Google Workspace Microsoft 365:een: Päivämäärät rikkoutuvat. MigrationWiz lukee IMAP:lla Googlelta ja kirjoittaa M365:een, joka lisää omat kuljetusotsakkeet.
• Exchange Exchangeen (EWS EWS:ään): Päivämäärät säilyvät yleensä. EWS ohittaa kuljetusputken molemmilla puolilla.
• Mikä tahansa lähde Google Workspaceen IMAP:n kautta: Päivämäärät rikkoutuvat. Googlen IMAP-toteutus lisää Received-otsakkeen lisäysaikaleimalla.
• Cross-tenant Microsoft 365: Riippuu menetelmästä. IMAP-reitti rikkoo päivämäärät. Suora EWS voi säilyttää ne.

MigrationWiz-hallintapaneeli ei merkitse päivämääräongelmia. Kaikki näkyy tilassa "Completed", koska viestit siirtyivät onnistuneesti. Sisältö on ehä, liitteet ovat kunnossa, kansiorakenne on tallella. Vain päivämäärät muuttuivat, ja MigrationWiz ei kirjaa sitä siirtovirheeksi.

Väärien päivämäärien todellinen hinta MigrationWizin jälkeen

Väärät sähköpostin päivämäärät eivät ole pelkästään ärsyttäviä. Organisaatioille, jotka siirtyivät BitTitanilla, seuraukset ylittävät sotkuisen postilaatikon.

Lakitiimit eivät voi käyttää sähköposteja todisteina, kun jokainen viesti näyttää siirtopäivämäärän todellisen lähetyspäivämäärän sijaan. Verotarkastukset vaativat kronologista todistusta viestinnästä. Sääntelykehykset kuten GDPR edellyttävät tarkkaa kirjanpitoa, ja sähköpostit väärennetyillä aikaleimoilla eivät täytä tätä vaatimusta.

Ja sitten on käytännöllinen puoli. Yritä löytää se sopimusneuvottelu marraskuulta 2022, kun koko postilaatikkosi näyttää maaliskuuta 2026. Lajittele päivämäärän mukaan? Hyödytöntä. Hae päivämääräväliltä? Palauttaa kaiken tai ei mitään.

MSP:ille, jotka käyttivät MigrationWiziä asiakasympäristöissä, tämä luo vastuuongelman. Asiakas maksoi siirrosta. Hän sai sellaisen, mutta hänen sähköpostiarkistonsa on käytännössä rikki kaikille päivämääräpohjaisille työnkuluille.

Toisaalta yksi MSP, josta kuultiin, oli siirtänyt noin 380 postilaatikkoa asianajotoimistolle. Kolme kuukautta myöhemmin toimiston prosessitiimi havaitsi päivämääräongelman todisteiden keräämisen aikana. Jokainen sähköposti, joka heidän piti esittää todisteena, näytti siirtopäivämäärän. MSP:n piti selittää, miksi 6 vuoden aikaleimattu kirjeenvaihto näytti kaikki kesäkuuta 2025.

Korjaa BitTitan MigrationWiz -päivämäärät

Alkuperäinen Date:-otsake on yhä jokaisessa sähköpostissa. MigrationWiz ei koske viestin sisältöön eikä alkuperäisiin otsakkeisiin. Ylimääräinen Received:-otsake ja ylikirjoitettu INTERNALDATE aiheuttavat näyttöongelman.

Redate.io yhdistää postilaatikkoon (Google Workspace, Microsoft 365 tai IMAP), skannaa MigrationWiz-siirrosta kärsineet sähköpostit ja korjaa päivämäärämetatiedot oman monivaiheisen analyysipipelinen kautta. Korjaus kohdistuu nimenomaan metatietokerrokseen käyttäen kuviotunnistusta tunnettuja MigrationWiz-otsakeallekirjoituksia vastaan, mukaan lukien tunnusomaiset tunnisteet mx.migrationwiz.com ja bittitan.com Received-ketjussa.

Jokainen korjattu sähköposti varmennetaan erikseen alkuperäistä vastaan. Varmennus tarkistaa viestin eheyden, liitteiden säilymisen, kansiosijoittelun ja ketjutuksen. Alkuperäiset sähköpostit säilytetään näkyvässä kansiossa Redate.io - Originals 30 päivää siltä varalta, että palautus on tarpeen.

Ongelman ymmärtäminen on yksi asia. 15 000 sähköpostin korjaaminen menettämättä yhtään ainoaa liitettä, rikkomatta S/MIME-allekirjoituksia tai korruptoimatta multipart MIME -rajoja on toinen. Skripti, joka toimii 10 testiviestillä laboratorio-olosuhteissa, ei käsittele tuotantopostilaatikon reunatapauksia, joissa on 7 vuotta kirjeenvaihtoa, PGP-salattuja viestejä ja RFC 2047 non-ASCII-otsakkeita.

Miten varmistat, että jokainen korjattu viesti on ehä? Että ketjutus toimii yhä, että kalenterikutsut ratkaistaan oikein, että 47 Mt:n liite vuoden 2020 sähköpostissa ei ole vahingoittunut? Redate.io tekee tämän automaattisesti jokaiselle yksittäiselle viestille. Ja jos jokin näyttää väärältä, alkuperäinen on siellä varmuuskopiokansiossa.

Ilmainen skannaus kestää noin kaksi minuuttia. Se yhdistää postilaatikkoon, tunnistaa jokaisen MigrationWiz-siirtopäivämäärällä leimatun sähköpostin ja näyttää tarkan määrän ja kustannuksen ennen kuin maksat mitään. Ei luottokorttia, ei sitoutumista.

Alustakohtaiset korjausoppaat BitTitanille

Korjausprosessi vaihtelee sen mukaan, minne MigrationWiz siirsi sähköpostisi. Redate.io käsittelee kunkin alustan erityispiirteet automaattisesti, mutta jos haluat lisätietoja tietystä kokoonpanosta:

• Korjaa BitTitan-päivämäärät Outlookissa
• Korjaa BitTitan-päivämäärät Microsoft 365:ssä
• Korjaa BitTitan-päivämäärät Google Workspacessa
• Korjaa BitTitan-päivämäärät Exchange Onlinessa

Redate.io toimii myös kuukausia tai vuosia sitten valmistuneille siirroille. Alkuperäinen Date-otsake ei vanhene.

Siirsit BitTitan MigrationWizillä ja päivämäärät menivät väärin? Suorita ilmainen skannaus nähdäksesi tarkalleen, kuinka monta sähköpostia on vaikuttunut, ennen kuin sitoudut mihinkään.