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. Kyse on yhdestä asiasta: siitä päivämäärästä, jonka jokainen kopio saa, kun se kirjoitetaan uuteen postilaatikkoon.

Missä väärä päivämäärä oikeasti sijaitsee

Kun MigrationWiz siirtää sähköpostin lähteestä kohteeseen, se käyttää IMAP-protokollaa (tai Exchange Web Servicesiä, riippuen päätepisteen tyypistä). Kohde säilyttää sille annetun päivämäärän: Microsoft 365, Outlook.com ja Gmail säilyttävät alkuperäisen päivämäärän, kun kopio kantaa sitä. Jos siis jokainen sähköposti näyttää siirron päivämäärän, kyse on siitä, välittikö MigrationWiz alkuperäisen päivämäärän vai ei.

Näin yhden tällaisen sähköpostin otsakkeet näyttävät yhä MigrationWiz-siirron jälkeen:

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

Alkuperäinen Date:-otsake vuodelta 2019 on yhä tallessa, ja samoin alkuperäinen Received:-ketju. Microsoft 365:ssä Outlookin näyttämä saapumispäivä on postilaatikon oma tieto siitä, milloin kukin sähköposti saapui: jos MigrationWiz ei välittänyt alkuperäistä päivämäärää, tämä tieto sanoo nyt 28. maaliskuuta 2026.

INTERNALDATE-arvo (aikaleima, jota IMAP-palvelimet käyttävät lajitteluun) on se päivämäärä, jonka kopio saa. MigrationWiz pyrkii säilyttämään päivämäärät, ja Microsoft 365 säilyttää sille annetun päivämäärän: kun päivämäärät näkyvät silti väärin, kyse on siitä, että jokaiselle sähköpostille välitetty päivämäärä ei ollut alkuperäinen.

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. Myös IMAP:n kautta kohde säilyttää sille annetun päivämäärän: ratkaisevaa on, välitetäänkö alkuperäinen päivämäärä.

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. Jokainen sähköposti saa kopion päivämäärän.
• Google Workspace Microsoft 365:een: Päivämäärät rikkoutuvat. MigrationWiz lukee IMAP:lla Googlelta ja kirjoittaa M365:een ilman alkuperäistä päivämäärää.
• Exchange Exchangeen (EWS EWS:ään): Alkuperäinen päivämäärä kulkee viestin mukana EWS:n kautta.
• Mikä tahansa lähde Google Workspaceen IMAP:n kautta: IMAP:n kautta Gmail säilyttää työkalun välittämän päivämäärän eikä lisää mitään. Päivämäärät rikkoutuvat vain, jos tämä päivämäärä ei ole alkuperäinen, tai jos kopio kulkee Gmailin tuonti-API:n kautta, joka lisää Received-rivin kopiointipäivän mukaan.
• Cross-tenant Microsoft 365: Kaikki riippuu siitä, minkä päivämäärän menetelmä välittää.

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. Näyttöongelman aiheuttaa se päivämäärä, jonka postilaatikko tallensi kullekin kopiolle.

Redate.io yhdistää postilaatikkoon (Google Workspace, Microsoft 365 tai IMAP), tarkistaa MigrationWiz-siirrosta kärsineet sähköpostit ja korjaa päivämäärämetatiedot. Korjaus kohdistuu nimenomaan metatietokerrokseen, eikä sen tarvitse tietää, mikä työkalu siirron teki: se löytää sähköpostit, joiden näytetty päivämäärä ei vastaa niiden alkuperäistä päivämäärää.

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 siltä varalta, että palautus on tarpeen, kunnes poistat ne itse.

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.