BitTitan MigrationWiz: korriger feil e-postdatoer

Hva BitTitan MigrationWiz gjør med e-postdatoer

Migreringen ble ferdig på fredag. 47 postbokser flyttet fra on-prem Exchange til Microsoft 365, alt grønt i MigrationWiz-dashboardet. Så kommer mandag morgen, og den første henvendelsen tikker inn: "Alle e-postene mine viser 28. mars 2026."

Hver eneste melding. Års korrespondanse, kundeforslag fra 2019, fakturaer fra 2021, alt stemplet med migreringsdatoen. MigrationWiz-loggen sier at alt ble overført vellykket (og teknisk sett stemmer det). Men datoene er borte.

BitTitan MigrationWiz er et av de mest brukte verktøyene for cloud-to-cloud e-postmigrering. Det håndterer Exchange til Microsoft 365, Google Workspace til Exchange, cross-tenant-flyttinger og mye mer. Selve verktøyet fungerer bra for det det gjør. Datoproblemet er ikke en feil i MigrationWiz. Det er en konsekvens av hvordan IMAP-protokollen fungerer på transportnivå, og MigrationWiz utløser det på en spesifikk måte.

Hvordan MigrationWiz håndterer Received-headere

Når MigrationWiz overfører en e-post fra kilde til destinasjon, bruker det IMAP-protokollen (eller Exchange Web Services, avhengig av endpoint-type). Under denne prosessen stempler destinasjonens e-postserver meldingen med en ny Received:-header som inneholder gjeldende tidsstempel, nøyaktig slik den ville gjort med enhver innkommende e-post.

Slik ser en typisk Received-headerkjede ut etter en MigrationWiz-migrering:

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

Den opprinnelige Received:-headeren fra 2019 er fortsatt der. Det samme gjelder den opprinnelige Date:-headeren. Men e-postklienter som Outlook bruker ikke dem. Outlook leser den nyeste Received:-headeren for å bestemme når meldingen skal vises, og den headeren sier nå 28. mars 2026.

Verdien INTERNALDATE (tidsstempelet IMAP-servere bruker til sortering) blir også overskrevet under overføring. MigrationWiz prøver å bevare datoer når destinasjonen støtter det, men resultatet avhenger i stor grad av destinasjonsserverens oppførsel. Microsoft 365s transportpipeline overskriver for eksempel INTERNALDATE med sitt eget leveringstidsstempel, uansett hva MigrationWiz ber om.

Hvorfor "Date Mapping" i MigrationWiz ikke holder

BitTitan tilbyr en "Date Mapping"-funksjon i MigrationWiz Avanserte Innstillinger. På papiret høres det ut som løsningen. I praksis styrer det hvilket datointervall av meldinger som migreres, ikke hvordan datoer bevares på destinasjonen.

Forvirringen er forståelig. Innstillingen har ordet "date" i navnet. Men det den egentlig gjør, er å filtrere kildemeldinger etter datointervall før migreringen. En melding fra 2018 ankommer fortsatt til destinasjonen med migreringens tidsstempel.

Så er det spørsmålet om IMAP kontra Exchange-endepunkter. Når MigrationWiz migrerer mellom to Exchange-servere via EWS (Exchange Web Services), fungerer datobevaring bedre fordi EWS gir mer kontroll over meldingsmetadata. Men i det øyeblikket IMAP er involvert på en av sidene, tar IMAP APPEND-operasjonen over og destinasjonsserveren bestemmer hvilket tidsstempel som brukes.

Noen administratorer har prøvd å kjøre migreringen på nytt med andre endepunktkonfigurasjoner, i håp om at bytte fra IMAP til EWS ville rette datoene med tilbakevirkende kraft. Det fungerer ikke. Meldingene er allerede på destinasjonen med feil datoer. Å kjøre MigrationWiz igjen ville bare opprette duplikater.

MigrationWiz-scenarier som ødelegger datoer

Ikke enhver MigrationWiz-migrering forårsaker datoproblemer. Problemet avhenger av endepunktkombinasjonen:

• Exchange (on-prem) til Microsoft 365 via IMAP: Datoer går i stykker. M365-transportpipelinen stempler nye Received-headere og overskriver INTERNALDATE.
• Google Workspace til Microsoft 365: Datoer går i stykker. MigrationWiz leser via IMAP fra Google og skriver til M365, som legger til sine transportheadere.
• Exchange til Exchange (EWS til EWS): Datoer bevares vanligvis. EWS omgår transportpipelinen på begge sider.
• Vilkårlig kilde til Google Workspace via IMAP: Datoer går i stykker. Googles IMAP-implementasjon legger til en Received-header med innsettingstidsstempelet.
• Cross-tenant Microsoft 365: Avhenger av metoden. IMAP-veien ødelegger datoer. Direkte EWS kan bevare dem.

MigrationWiz-dashboardet flagger ikke datoproblemer. Alt vises som "Completed" fordi meldingene faktisk ble overført vellykket. Innholdet er intakt, vedlegg er i orden, mappestrukturen er bevart. Det er bare datoene som endret seg, og MigrationWiz registrerer ikke det som en migreringsfeil.

De reelle kostnadene ved feil datoer etter MigrationWiz

Feil e-postdatoer er ikke bare irriterende. For organisasjoner som migrerte med BitTitan, går konsekvensene utover en rotete innboks.

Juridiske team kan ikke bruke e-poster som bevis når hver melding viser migreringsdatoen i stedet for den faktiske sendedatoen. Skattrevisjoner krever kronologisk dokumentasjon av kommunikasjon. Regelverksrammer som GDPR krever nøyaktig registrering, og e-poster med fabrikkerte tidsstempler oppfyller ikke det kravet.

Og så er det den praktiske siden. Prøv å finne den kontraktdiskusjonen fra november 2022 når hele postboksen din viser mars 2026. Sortere etter dato? Nyttesløst. Søke etter datointervall? Returnerer alt eller ingenting.

For MSP-er som brukte MigrationWiz i kundemiljøer, skaper dette et ansvarsproblem. Kunden betalte for en migrering. De fikk en, men e-postarkivet deres er rett og slett ubrukelig for datobaserte arbeidsflyter.

Egentlig hadde en MSP man hørte om migrert rundt 380 postbokser for et advokatfirma. Tre måneder senere oppdaget firmaets prosessteam datoproblemet under bevisinnsamling. Hver e-post de måtte presentere som bevis, viste migreringsdatoen. MSP-en måtte forklare hvorfor 6 års tidsstemplet korrespondanse alle viste juni 2025.

Korriger BitTitan MigrationWiz-datoer

Den opprinnelige Date:-headeren sitter fortsatt i hver e-post. MigrationWiz rører ikke meldingsinnholdet eller de opprinnelige headerene. Det er den ekstra Received:-headeren og det overskrevne INTERNALDATE som forårsaker visningsproblemet.

Redate.io kobler seg til postboksen (Google Workspace, Microsoft 365 eller IMAP), skanner etter e-poster påvirket av MigrationWiz-migreringen og korrigerer datometadataene gjennom en proprietær flertrinns analysepipeline. Korrigeringen retter seg spesifikt mot metadatalaget, med mønstermatchning mot kjente MigrationWiz-headersignaturer inkludert de karakteristiske identifikatorene mx.migrationwiz.com og bittitan.com i Received-kjeden.

Hver korrigert e-post verifiseres individuelt mot originalen. Verifiseringen sjekker meldingsintegritet, bevaring av vedlegg, mappeplassering og tråding. Originale e-poster oppbevares i en synlig mappe Redate.io - Originals i 30 dager i tilfelle en tilbakerulling er nødvendig.

Å forstå problemet er én ting. Å korrigere 15 000 e-poster uten å miste et eneste vedlegg, ødelegge S/MIME-signaturer eller korrumpere multipart MIME-grenser er noe helt annet. Et skript som fungerer på 10 testmeldinger i et lab, vil ikke håndtere kanttilfellene i en produksjonspostboks med 7 års korrespondanse, PGP-krypterte meldinger og RFC 2047 non-ASCII-headere.

Hvordan verifiserer du at hver korrigert melding er intakt? At trådingen fortsatt fungerer, at kalenderinvitasjoner fortsatt løses, at det 47 MB store vedlegget på den e-posten fra 2020 ikke er skadet? Redate.io gjør dette automatisk, for hver eneste melding. Og hvis noe ser feil ut, ligger originalen klar i sikkerhetskopimappen.

Den gratis skanningen tar omtrent to minutter. Den kobler seg til postboksen, identifiserer hver e-post stemplet med MigrationWiz-migreringsdatoen og viser det eksakte antallet og kostnaden før du betaler noe. Ikke noe kredittkort, ingen forpliktelse.

Plattformspesifikke veiledninger for BitTitan

Korrigeringsprosessen varierer avhengig av hvor MigrationWiz flyttet e-posten din. Redate.io håndterer hvert plattforms særtrekk automatisk, men hvis du ønsker detaljer om ditt spesifikke oppsett:

• Korriger BitTitan-datoer i Outlook
• Korriger BitTitan-datoer i Microsoft 365
• Korriger BitTitan-datoer i Google Workspace
• Korriger BitTitan-datoer i Exchange Online

Redate.io fungerer også for migreringer fullført for måneder eller år siden. Den opprinnelige Date-headeren utløper ikke.

Migrerte med BitTitan MigrationWiz og sitter fast med feil datoer? Kjør en gratis skanning for å se nøyaktig hvor mange e-poster som er påvirket før du forplikter deg til noe.