BitTitan MigrationWiz: korrigera felaktiga datum

Vad BitTitan MigrationWiz gör med e-postdatum

Migreringen blev klar i fredags. 47 brevlådor flyttade från on-prem Exchange till Microsoft 365, allt grönt i MigrationWiz-panelen. Så kommer måndag morgon och det första ärendet trillar in: "Alla mina e-postmeddelanden visar 28 mars 2026."

Varje enskilt meddelande. Års korrespondens, kundförslag från 2019, fakturor från 2021, allt stämplat med migreringsdatumet. MigrationWiz-loggen säger att allt överförts framgångsrikt (och tekniskt sett är det sant). Men datumen är borta.

BitTitan MigrationWiz är ett av de mest använda verktygen för cloud-to-cloud e-postmigrering. Det hanterar Exchange till Microsoft 365, Google Workspace till Exchange, cross-tenant-flyttar och mycket mer. Verktyget i sig fungerar bra för vad det gör. Datumproblemet är inte en bugg i MigrationWiz. Det är en konsekvens av hur IMAP-protokollet fungerar på transportnivå, och MigrationWiz utlöser det på ett specifikt sätt.

Hur MigrationWiz hanterar Received-headers

När MigrationWiz överför ett e-postmeddelande från källa till destination använder det IMAP-protokollet (eller Exchange Web Services, beroende på endpoint-typ). Under denna process stämplar destinationens e-postserver meddelandet med en ny Received:-header som innehåller aktuell tidstämpel, precis som den skulle göra med vilken inkommande e-post som helst.

Så här ser en typisk Received-headerkedja ut 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 ursprungliga Received:-headern från 2019 finns fortfarande kvar. Likså den ursprungliga Date:-headern. Men e-postklienter som Outlook använder inte dem. Outlook läser den senaste Received:-headern för att avgöra när meddelandet ska visas, och den headern säger nu 28 mars 2026.

Värdet INTERNALDATE (tidstämpeln som IMAP-servrar använder för sortering) skrivs också över under överföring. MigrationWiz försöker bevara datum när destinationen stödjer det, men resultatet beror i hög grad på destinationsserverns beteende. Microsoft 365:s transportpipeline skriver till exempel över INTERNALDATE med sin egen leveranstidstämpel, oavsett vad MigrationWiz begär.

Varför MigrationWiz "Date Mapping" inte räcker till

BitTitan erbjuder en "Date Mapping"-funktion i MigrationWiz Avancerade Inställningar. På papperet låter det som lösningen. I praktiken styr det vilket datumintervall av meddelanden som migreras, inte hur datum bevaras på destinationen.

Förvirringen är förståelig. Inställningen har ordet "date" i namnet. Men vad den faktiskt gör är att filtrera källmeddelanden efter datumintervall före migreringen. Ett meddelande från 2018 anländer fortfarande till destinationen med migreringens tidstämpel.

Det finns också frågan om IMAP kontra Exchange-endpoints. När MigrationWiz migrerar mellan två Exchange-servrar via EWS (Exchange Web Services) fungerar datumbevarandet bättre, eftersom EWS ger mer kontroll över meddelandemetadata. Men så fort IMAP är inblandat på någon sida tar IMAP APPEND-operationen över och destinationsservern bestämmer vilken tidstämpel som används.

Vissa administratörer har försökt köra migreringen igen med andra endpoint-konfigurationer, i hopp om att byte från IMAP till EWS skulle åtgärda datumen retroaktivt. Det fungerar inte. Meddelandena finns redan på destinationen med fel datum. Att köra MigrationWiz igen skulle bara skapa dubbletter.

MigrationWiz-scenarier som förstör datum

Inte varje MigrationWiz-migrering orsakar datumproblem. Problemet beror på endpoint-kombinationen:

• Exchange (on-prem) till Microsoft 365 via IMAP: Datum förstörs. M365-transportpipelinen stämplar nya Received-headers och skriver över INTERNALDATE.
• Google Workspace till Microsoft 365: Datum förstörs. MigrationWiz läser via IMAP från Google och skriver till M365, som lägger till sina transportheaders.
• Exchange till Exchange (EWS till EWS): Datum bevaras vanligtvis. EWS går förbi transportpipelinen på båda sidor.
• Godtycklig källa till Google Workspace via IMAP: Datum förstörs. Googles IMAP-implementation lägger till en Received-header med insättningens tidstämpel.
• Cross-tenant Microsoft 365: Beror på metoden. IMAP-vägen förstör datum. Direkt EWS kan bevara dem.

MigrationWiz-panelen flaggar inte datumproblem. Allt visas som "Completed" eftersom meddelandena faktiskt överförts framgångsrikt. Innehållet är intakt, bilagor är i ordning, mappstrukturen är bevarad. Det är bara datumen som ändrats, och MigrationWiz registrerar inte det som ett migreringsfel.

Den verkliga kostnaden för felaktiga datum efter MigrationWiz

Felaktiga e-postdatum är inte bara irriterande. För organisationer som migrerade med BitTitan går konsekvenserna längre än en rörig inkorg.

Juridiska team kan inte använda e-post som bevis när varje meddelande visar migreringsdatumet istället för det faktiska sändningsdatumet. Skatterevisioner kräver kronologiska bevis på kommunikation. Complianceramverk som GDPR kräver korrekt dokumentation, och e-post med fabricerade tidstämplar uppfyller inte det kravet.

Och så finns den praktiska sidan. Försök hitta den där kontraktsdiskussionen från november 2022 när hela din brevlåda visar mars 2026. Sortera efter datum? Meningslöst. Söka efter datumintervall? Returnerar allt eller inget.

För MSP:er som använde MigrationWiz i kundmiljöer skapar det ett ansvarsproblem. Kunden betalade för en migrering. De fick en, men deras e-postarkiv är i praktiken oanvändbart för datumbaserade arbetsflöden.

Förresten, en MSP man hörde talas om hade migrerat runt 380 brevlådor för en advokatbyrå. Tre månader senare upptäckte byråns processteam datumproblemet under bevisframtagning. Varje e-postmeddelande de behövde presentera som bevis visade migreringsdatumet. MSP:en var tvungen att förklara varför 6 års tidstämplad korrespondens alla visade juni 2025.

Korrigera BitTitan MigrationWiz-datum

Den ursprungliga Date:-headern finns fortfarande i varje e-postmeddelande. MigrationWiz rör inte meddelandets innehåll eller de ursprungliga headrarna. Det är den extra Received:-headern och det överskrivna INTERNALDATE som orsakar visningsproblemet.

Redate.io ansluter till brevlådan (Google Workspace, Microsoft 365 eller IMAP), skannar efter e-post som påverkats av MigrationWiz-migreringen och korrigerar datummetadata genom en proprietär flerstegsanalysepipeline. Korrigeringen riktar sig specifikt mot metadatalagret, med mönstermatchning mot kända MigrationWiz-headersignaturer inklusive de karakteristiska identifierarna mx.migrationwiz.com och bittitan.com i Received-kedjan.

Varje korrigerat e-postmeddelande verifieras individuellt mot originalet. Verifieringen kontrollerar meddelandeintegritet, bevarande av bilagor, mappplacering och trådning. Ursprungliga e-postmeddelanden sparas i en synlig mapp Redate.io - Originals i 30 dagar ifall en återställning behövs.

Att förstå problemet är en sak. Att korrigera 15 000 e-postmeddelanden utan att förlora en enda bilaga, skada S/MIME-signaturer eller korrumpera multipart MIME-gränser är något annat. Ett skript som fungerar på 10 testmeddelanden i ett labb kommer inte att hantera kantfallen i en produktionsbrevlåda med 7 års korrespondens, PGP-krypterade meddelanden och RFC 2047 non-ASCII-headers.

Hur verifierar du att varje korrigerat meddelande är intakt? Att trådningen fortfarande fungerar, att kalenderinbjudningar fortfarande fungerar korrekt, att den 47 MB stora bilagan på det där e-postmeddelandet från 2020 inte har skadats? Redate.io gör detta automatiskt, för varje enskilt meddelande. Och om något ser fel ut ligger originalet där i backupmappen.

Den gratis skanningen tar ungefär två minuter. Den ansluter till brevlådan, identifierar varje e-postmeddelande stämplat med MigrationWiz-migreringsdatumet och visar det exakta antalet och kostnaden innan du betalar något. Inget kreditkort, inget åtagande.

Plattformsspecifika guider för BitTitan

Korrigeringsprocessen varierar beroende på var MigrationWiz flyttade din e-post. Redate.io hanterar varje plattforms specifika förhållanden automatiskt, men om du vill ha detaljer om din specifika installation:

• Åtgärda BitTitan-datum i Outlook
• Åtgärda BitTitan-datum i Microsoft 365
• Åtgärda BitTitan-datum i Google Workspace
• Åtgärda BitTitan-datum i Exchange Online

Redate.io fungerar även för migreringar som genomfördes för månader eller år sedan. Den ursprungliga Date-headern förfaller inte.

Migrerade med BitTitan MigrationWiz och fastnade med felaktiga datum? Kör en gratis skanning för att se exakt hur många e-postmeddelanden som är påverkade innan du binder dig till något.