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. Allt handlar om en enda sak: vilket datum varje kopia bär med sig när den skrivs in i den nya brevlådan.

Var det felaktiga datumet egentligen sitter

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). Destinationen behåller det datum den får: Microsoft 365, Outlook.com och Gmail behåller det ursprungliga datumet när kopian bär med sig det. Så om alla e-postmeddelanden visar migreringsdatumet är det datumet som MigrationWiz skickade, eller inte skickade, som är boven.

Så här ser headrarna i ett av dessa e-postmeddelanden fortfarande ut 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 ursprungliga Date:-headern från 2019 finns fortfarande kvar, och likså den ursprungliga Received:-kedjan. I Microsoft 365 är datumet Outlook visar som mottaget brevlådans egen uppgift om när varje e-postmeddelande kom in: om MigrationWiz inte skickade med det ursprungliga datumet säger den uppgiften 28 mars 2026.

Värdet INTERNALDATE (tidstämpeln som IMAP-servrar använder för sortering) är det datum kopian fick. MigrationWiz försöker bevara datum, och Microsoft 365 behåller det datum den får: när datumen fortfarande blir fel var det datumet som skickades för varje e-postmeddelande som inte var det ursprungliga.

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. Även över IMAP behåller destinationen det datum den får: det som avgör är om det ursprungliga datumet skickas med.

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. Varje e-postmeddelande får kopians datum.
• Google Workspace till Microsoft 365: Datum förstörs. MigrationWiz läser via IMAP från Google och skriver till M365 utan det ursprungliga datumet.
• Exchange till Exchange (EWS till EWS): Datum bevaras vanligtvis. Via EWS följer det ursprungliga datumet med meddelandet.
• Godtycklig källa till Google Workspace via IMAP: Över IMAP behåller Gmail det datum verktyget skickar med och lägger inte till något. Datum förstörs bara om det datumet inte är det ursprungliga, eller om kopian går via Gmails importAPI, som lägger till en Received-rad daterad kopieringsdagen.
• Cross-tenant Microsoft 365: Allt beror på det datum metoden skickar med.

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 det datum brevlådan registrerade för varje kopia 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 fixar e-postdatumen. Redate.io behöver inte veta vilket verktyg som utförde migreringen: det hittar de e-postmeddelanden vars visade datum inte stämmer med det ursprungliga datumet.

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 tills du själv tar bort dem.

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.