BitTitan MigrationWiz: ret forkerte e-maildatoer

Hvad BitTitan MigrationWiz gør ved e-maildatoer

Migreringen blev færdig i fredags. 47 postkasser flyttet fra on-prem Exchange til Microsoft 365, alt grønt i MigrationWiz-dashboardet. Så kommer mandag morgen, og den første ticket lander: "Alle mine e-mails viser 28. marts 2026."

Hver eneste besked. Års korrespondance, kundeforslag fra 2019, fakturaer fra 2021, det hele stemplet med migreringsdatoen. MigrationWiz-loggen siger, at alt blev overført med succes (og teknisk set er det rigtigt). Men datoerne er væk.

BitTitan MigrationWiz er et af de mest brugte værktøjer til cloud-to-cloud e-mailmigrering. Det håndterer Exchange til Microsoft 365, Google Workspace til Exchange, cross-tenant flytninger og meget mere. Selve værktøjet fungerer fint til det, det gør. Datoproblemet er ikke en fejl i MigrationWiz. Det handler om én ting: den dato, hver kopi bærer, når den skrives ind i den nye postkasse.

Hvor den forkerte dato egentlig sidder

Når MigrationWiz overfører en e-mail fra kilde til destination, bruger det IMAP-protokollen (eller Exchange Web Services, afhængigt af endpoint-typen). Destinationen bevarer den dato, den får: Microsoft 365, Outlook.com og Gmail bevarer den originale dato, når kopien bærer den. Så hvis alle e-mails viser migreringsdatoen, er det den dato, MigrationWiz overførte, eller ikke overførte, der er problemet.

Sådan ser headerne i en af disse e-mails stadig ud efter en MigrationWiz-migrering:

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

Den originale Date:-header fra 2019 er der stadig, og det samme gælder den originale Received:-kæde. Og i Microsoft 365 er den dato, Outlook viser som modtaget, postkassens eget register over, hvornår hver e-mail ankom: hvis MigrationWiz ikke overførte den originale dato, siger dette register 28. marts 2026.

Værdien INTERNALDATE (det tidsstempel IMAP-servere bruger til sortering) er den dato, kopien fik. MigrationWiz forsøger at bevare datoer, og Microsoft 365 bevarer den dato, den får: når datoerne stadig er forkerte, var den dato, der blev overført for hver e-mail, ikke den originale.

Hvorfor MigrationWiz's "Date Mapping" ikke rækker

BitTitan tilbyder en "Date Mapping"-funktion i MigrationWiz's Avancerede Indstillinger. På papiret lyder det som løsningen. I praksis styrer det, hvilket datointerval af beskeder der migreres, ikke hvordan datoer bevares på destinationen.

Forvirringen er forståelig. Indstillingen har ordet "date" i navnet. Men hvad den faktisk gør, er at filtrere kildebeskeder efter datointerval før migreringen. En besked fra 2018 ankommer stadig til destinationen med migreringstidsstemplet.

Så er der spørgsmålet om IMAP versus Exchange-endpoints. Når MigrationWiz migrerer mellem to Exchange-servere via EWS (Exchange Web Services), fungerer datobevaring bedre, fordi EWS tilbyder mere kontrol over beskedmetadata. Også over IMAP bevarer destinationen den dato, den får: det afgørende er, om den originale dato bliver overført.

Nogle administratorer har prøvet at køre migreringen igen med andre endpoint-konfigurationer i håb om, at skiftet fra IMAP til EWS ville rette datoerne med tilbagevirkende kraft. Det virker ikke. Beskederne er allerede på destinationen med forkerte datoer. At køre MigrationWiz igen ville kun skabe dubletter.

MigrationWiz-scenarier der ødelægger datoer

Ikke enhver MigrationWiz-migrering forårsager datoproblemer. Problemet afhænger af endpoint-kombinationen:

• Exchange (on-prem) til Microsoft 365 via IMAP: Datoer går i stykker. Hver e-mail får kopiens dato.
• Google Workspace til Microsoft 365: Datoer går i stykker. MigrationWiz læser via IMAP fra Google og skriver til M365 uden den originale dato.
• Exchange til Exchange (EWS til EWS): Datoer bevares normalt. Over EWS følger den originale dato med beskeden.
• Vilkårlig kilde til Google Workspace via IMAP: Datoer går i stykker. Over IMAP bevarer Gmail den dato, værktøjet overfører, og tilføjer intet. Datoer går kun i stykker, hvis denne dato ikke er den originale, eller hvis kopien går gennem Gmails import-API, som tilføjer en Received:-linje dateret dagen for kopieringen.
• Cross-tenant Microsoft 365: Det afhænger helt af den dato, metoden overfører.

MigrationWiz-dashboardet markerer ikke datoproblemer. Alt vises som "Completed", fordi beskederne faktisk blev overført med succes. Indholdet er intakt, vedhæftede filer er i orden, mappestrukturen er bevaret. Det er kun datoerne, der ændrede sig, og MigrationWiz registrerer ikke det som en migreringsfejl.

De reelle omkostninger ved forkerte datoer efter MigrationWiz

Forkerte e-maildatoer er ikke bare irriterende. For organisationer der migrerede med BitTitan, går konsekvenserne ud over en rodet indbakke.

Juridiske teams kan ikke bruge e-mails som bevismateriale, når hver besked viser migreringsdatoen i stedet for den faktiske afsendelsesdato. Skatterevisjoner kræver kronologisk dokumentation af kommunikation. Compliancerammer som GDPR kræver nøjagtig registrering, og e-mails med fabrikerede tidsstempler opfylder ikke det krav.

Og så er der den praktiske side. Prøv at finde den kontraktdiskussion fra november 2022, når hele din postkasse viser marts 2026. Sortere efter dato? Nyttesløst. Søge efter datointerval? Returnerer alt eller intet.

For MSP'er der brugte MigrationWiz i kundmiljøer, skaber det et ansvarsproblem. Kunden betalte for en migrering. De fik en, men deres e-mailarkiv er reelt ødelagt til datobaserede arbejdsgange.

Faktisk havde en MSP, man hørte om, migreret omkring 380 postkasser for et advokatfirma. Tre måneder senere opdagede firmaets procesteam datoproblemet under bevisindsamling. Hver e-mail de skulle præsentere som bevis, viste migreringsdatoen. MSP'en måtte forklare, hvorfor 6 års tidsstemplet korrespondance alle viste juni 2025.

Ret BitTitan MigrationWiz-datoer

Den originale Date:-header sidder stadig i hver e-mail. MigrationWiz rører ikke ved beskedindholdet eller de originale headers. Det er den dato, postkassen registrerede for hver kopi, der forårsager visningsproblemet.

Redate.io forbinder sig til postkassen (Google Workspace, Microsoft 365 eller IMAP), scanner for e-mails påvirket af MigrationWiz-migreringen og retter datometadataen gennem en proprietær flertrins analysepipeline. Rettelsen retter sig specifikt mod metadatalaget og har ikke brug for at vide, hvilket værktøj der udførte migreringen: den finder de e-mails, hvis viste dato ikke matcher deres oprindelige dato.

Hver rettet e-mail verificeres individuelt mod originalen. Verificeringen kontrollerer beskedintegritet, bevarelse af vedhæftede filer, mappeplacering og threading. Originale e-mails opbevares i en synlig mappe Redate.io - Originals indtil du selv sletter dem, og lægges tilbage, hvis en rollback er nødvendig.

At forstå problemet er én ting. At rette 15.000 e-mails uden at miste en eneste vedhæftet fil, ødelægge S/MIME-signaturer eller korrumpere multipart MIME-grænser er noget helt andet. Et script der virker på 10 testbeskeder i et lab, vil ikke håndtere kanttilfældene i en produktionspostkasse med 7 års korrespondance, PGP-krypterede beskeder og RFC 2047 non-ASCII-headers.

Hvordan verificerer du, at hver rettet besked er intakt? At threading stadig virker, at kalenderinvitationer stadig fungerer, at den 47 MB store vedhæftede fil på den e-mail fra 2020 ikke er beskadiget? Redate.io gør dette automatisk for hver eneste besked. Og hvis noget ser forkert ud, ligger originalen klar i backupmappen.

Den gratis scanning tager cirka to minutter. Den forbinder sig til postkassen, identificerer hver e-mail stemplet med MigrationWiz-migreringsdatoen og viser det præcise antal og omkostningen, før du betaler noget. Intet kreditkort, ingen forpligtelse.

Platformspecifikke retningslinjer for BitTitan

Rettelsesprocessen varierer afhængigt af, hvor MigrationWiz flyttede dine e-mails hen. Redate.io håndterer hver platforms særlige forhold automatisk, men hvis du ønsker detaljer om din specifikke opsætning:

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

Redate.io virker også for migreringer gennemført for måneder eller år siden. Den originale Date-header udløber ikke.

Migreret med BitTitan MigrationWiz og sidder fast med forkerte datoer? Kør en gratis scanning for at se præcis, hvor mange e-mails der er påvirket, før du forpligter dig til noget.