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 er en konsekvens af, hvordan IMAP-protokollen fungerer på transportniveau, og MigrationWiz udløser det på en specifik måde.

Hvordan MigrationWiz håndterer Received-headers

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). Under denne proces stempler destinationsmailserveren beskeden med en ny Received:-header med det aktuelle tidsstempel, præcis som den ville med enhver indgående e-mail.

Sådan ser en typisk Received-headerkæde ud efter 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 originale Received:-header fra 2019 er der stadig. Det samme gælder den originale Date:-header. Men e-mailklienter som Outlook bruger ikke dem. Outlook læser den nyeste Received:-header for at bestemme, hvornår beskeden skal vises, og den header siger nu 28. marts 2026.

Værdien INTERNALDATE (det tidsstempel IMAP-servere bruger til sortering) bliver også overskrevet under overførslen. MigrationWiz forsøger at bevare datoer, når destinationen understøtter det, men resultatet afhænger i høj grad af destinationsserverens adfærd. Microsoft 365's transportpipeline overskriver for eksempel INTERNALDATE med sit eget leveringstidsstempel, uanset hvad MigrationWiz anmoder om.

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. Men i det øjeblik IMAP er involveret på en af siderne, overtager IMAP APPEND-operationen, og destinationsserveren bestemmer, hvilket tidsstempel der bruges.

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. M365-transportpipelinen stempler nye Received-headers og overskriver INTERNALDATE.
• Google Workspace til Microsoft 365: Datoer går i stykker. MigrationWiz læser via IMAP fra Google og skriver til M365, der tilføjer sine transportheaders.
• Exchange til Exchange (EWS til EWS): Datoer bevares normalt. EWS omgår transportpipelinen på begge sider.
• Vilkårlig kilde til Google Workspace via IMAP: Datoer går i stykker. Googles IMAP-implementering tilføjer en Received-header med indsættelsestidsstemplet.
• Cross-tenant Microsoft 365: Afhænger af metoden. IMAP-vejen ødelægger datoer. Direkte EWS kan bevare dem.

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 ekstra Received:-header og den overskrevne INTERNALDATE, 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 med mønstermatching mod kendte MigrationWiz-headersignaturer, inklusive de karakteristiske identifikatorer mx.migrationwiz.com og bittitan.com i Received-kæden.

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 i 30 dage, 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.