Varför en migreringschecklista är nödvändig
E-postmigrering är en av de mest riskfyllda IT-operationerna en organisation kan genomföra. Du flyttar åratal av affärskommunikation mellan plattformar, och ett enda misstag kan korrumpera metadata i alla brevlådor. Det vanligaste offret? E-postdatumen. Efter migrering riskerar varje e-postmeddelande att visa migreringsdatumet istället för det ursprungliga sänd- eller mottagningsdatumet.
Den här checklistan täcker varje fas av migreringsprocessen. Följ dessa steg för att minimera risken för datumkorruption och andra metadataproblem. Och om migreringen redan är klar och datumproblem har uppstått, läs vidare.
Fas 1: planering före migrering
Inventera brevlådorna
Innan du rör ett migreringsverktyg, dokumentera varje brevlåda som ska migreras. Registrera totalt antal brevlådor, ungefärligt antal e-postmeddelanden per brevlåda, datumintervallet för de äldsta e-postmeddelandena, och delade brevlådor eller distributionsgrupper. Denna inventering bestämmer vilket migreringsverktyg som ska användas, hur lång tid migreringen tar, och vilken prisklass som gäller för eventuella korrigeringar efter migreringen.
Välj rätt migreringsverktyg
Alla migreringsverktyg hanterar inte datum på samma sätt. Undersök hur varje verktyg hanterar bevarandet av IMAP INTERNALDATE och om det lägger till "Received"-huvuden under APPEND-processen. Populära verktyg inkluderar BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO och Exchange Admin Centers nativa import. Vart och ett av dessa verktyg kan orsaka datumproblem eftersom själva IMAP-protokollet kräver att destinationsservern lägger till ett "Received"-huvud vid infogning. Men vissa verktyg bevarar INTERNALDATE bättre än andra. För att bättre förstå hur INTERNALDATE fungerar, se IMAP INTERNALDATE: varför datum går sönder.
Säkerhetskopiera allt
Skapa en fullständig backup av varje brevlåda före migrering. Denna backup fungerar både som säkerhetsnät och som referenspunkt för att verifiera datum i efterhand. För Google Workspace, använd Google Takeout eller ett tredjeparts backupverktyg. För Microsoft 365, använd Exchange Online-backup eller PST-export. För IMAP-servrar, använd imapsync för att skapa en lokal kopia.
Förvara backuperna på en plats helt separerad från käll- och destinationsservrarna.
Dokumentera ursprungliga datum
Välj 10 till 20 e-postmeddelanden per brevlåda spridda över olika datumintervall (de äldsta, de senaste och flera däremellan). Registrera "Mottaget"-datum, "Skickat"-datum och råa huvuden för varje e-postmeddelande. Dessa referensmeddelanden blir din verifieringsbas efter migrering. Ta en skärmbild av brevlådan sorterad efter datum för att visuellt dokumentera den ursprungliga kronologiska ordningen.
Fas 2: testmigrering
Migrera en testbrevlåda först
Kör aldrig en fullständig migrering utan att testa först.
Skapa en testbrevlåda med ett representativt urval av e-postmeddelanden (minst 100, från flera år). Kör migreringen på enbart den brevlådan och undersök resultaten noggrant innan du fortsätter. Det här testet avslöjar datumproblem, kodningsfel, bilageproblem och mappstrukturavvikelser innan de drabbar produktionsbrevlådor.
Verifiera datum på testbrevlådan
Efter migrering av testbrevlådan, verifiera datumen omedelbart. Öppna brevlådan i den e-postklient som slutanvändarna faktiskt använder (Outlook, Apple Mail, Thunderbird eller webbmailgränssnittet). Jämför visade datum med referensmeddelandena dokumenterade i Fas 1. Kontrollera både "Mottaget"- och "Skickat"-datum. Öppna råa huvuden på flera e-postmeddelanden och leta efter nyligen tillagda "Received"-huvuden med migreringens tidstämpel.
Om datumen är felaktiga på testbrevlådan blir de felaktiga på alla brevlådor. Stanna upp och åtgärda problemet innan du fortsätter med den fullständiga migreringen.
Testa med flera e-postklienter
Olika e-postklienter visar datum olika. Gmails webbgränssnitt kan visa korrekta datum (det använder "Date"-huvudet) medan Outlook visar migreringsdatumet (det prioriterar "Received"-huvudet). Testa med varje klient som organisationens användare använder, särskilt Outlook Desktop, Outlook på webben, Apple Mail, Thunderbird och eventuella mobila e-postappar.
Fas 3: migreringskörning
Konfiguration av migreringsverktyg
Konfigurera migreringsverktyget för att bevara INTERNALDATE så långt möjligt. I imapsync, använd lämpliga flaggor för att ställa in INTERNALDATE på destinationen. I BitTitan MigrationWiz, kontrollera avancerade inställningar för datumhanteringsalternativ. Dessa inställningar förhindrar inte helt "Received"-huvudproblemet, men de minskar allvaret av datumproblem i vissa klienter. Dokumentera varje konfigurationsinställning som används för att kunna återskapa migreringen om det behövs.
Migrera i batchar
Migrera inte alla brevlådor samtidigt. Migrera i batchar om 10 till 20 brevlådor och verifiera datum efter varje batch. Om en batch visar datumproblem upptäcker du det innan hela organisationen är drabbad. Förresten minskar batchmigrering också belastningen på käll- och destinationsservrar, vilket minskar risken för timeouts eller anslutningsfel som kan orsaka partiella migreringar.
Övervaka framstegen
Följ migreringsframstegen för varje brevlåda. Registrera starttid, sluttid, antal migrerade e-postmeddelanden och eventuella fel. Migreringsverktyg tillhandahåller vanligtvis loggar, spara dem för varje brevlåda. Om datumproblem upptäcks senare hjälper loggarna att identifiera exakt vilken migreringsbatch och vilka inställningar som användes.
Fas 4: verifiering efter migrering
Verifiera datum omedelbart
Verifiera e-postdatum inom 24 timmar efter migrering. För varje batch, öppna 5 till 10 brevlådor och jämför datum med referenserna från före migreringen. Om datumen är felaktiga, dokumentera problemets omfång (hur många brevlådor drabbade, hur många e-postmeddelanden per brevlåda) medan informationen är färsk.
Kontrollera alla mapptyper
Datumproblem kan påverka vissa mappar olika. Verifiera datum i Inkorgen, Skickat, Utkast och alla anpassade mappar eller etiketter. Vissa migreringsverktyg behandlar mappar sekventiellt, och fel i en mapp indikerar inte nödvändigtvis fel i andra.
Verifiera sökning och sortering
Öppna en migrerad brevlåda, sortera efter datum och bekräfta att den kronologiska ordningen matchar originalet. Sök efter e-postmeddelanden via datumintervall och verifiera att resultaten är korrekta. Testa alla automatiserade regler eller filter som beror på mottagningsdatum. Om organisationen använder compliance- eller eDiscovery-verktyg, verifiera att datumbaserade frågor returnerar korrekta resultat.
Vanliga misstag som orsakar datumproblem
Hoppa över testmigreringen
Det vanligaste misstaget är att migrera alla brevlådor utan att testa först. När datumproblemet upptäcks är alla brevlådor drabbade och källservern kan redan ha avvecklats. En testmigrering på 30 minuter kan förhindra veckors åtgärdsarbete. Varför skippa den?
Ignorera tillägg av "Received"-huvuden
Administratörer fokuserar ofta på att bevara INTERNALDATE och förbiser "Received"-huvudproblemet. Även när INTERNALDATE är korrekt satt gör migreringens "Received"-huvud att Outlook och andra klienter visar fel datum. Det är den vanligaste källan till klagomål efter migrering. Läs varför e-post visar fel datum efter migrering för en fullständig teknisk förklaring.
Avveckla källservern för tidigt
Om datumproblem upptäcks efter att källservern stängts av försvinner alternativet med ny migrering. Behåll källservern tillgänglig (om så bara för läsning) i minst 30 dagar efter migreringen. Det ger en reservplan om allvarliga problem dyker upp senare.
Vad gör du om datumen redan är trasiga
Om migreringen redan är genomförd och datumen är felaktiga är problemet åtgärdbart. Det ursprungliga "Date"-huvudet bevaras i varje e-postmeddelande, vilket innebär att korrekt datuminformation fortfarande finns. E-postdatum kan korrigeras efter migrering, även månader eller år senare.
Redate.ios proprietära korrigeringsmotor ansluter till brevlådan och söker efter e-postmeddelanden med korrumperad datummetadata. Den flerstegs analyspipelinen identifierar migreringssignaturer, tillämpar riktade korrigeringar samtidigt som meddelandeintegriteten bevaras (inklusive S/MIME-signaturer, multipart-strukturer och icke-ASCII-huvuden), och kör en integritetskontroll på varje korrigerat e-postmeddelande. Analysen är gratis och visar exakt hur många e-postmeddelanden som berörs. Originalen bevaras i en synlig backupmapp i 30 dagar.
Att försöka den här typen av korrigering manuellt eller med ett eget skript är frestande men riskabelt. Specialfall som PGP-krypterade meddelanden, korrupta MIME-gränser, nästlade multipart-strukturer och Content-Transfer-Encoding-förskjutningar kan tyst korruptera e-postmeddelanden utan att du märker det förrän det är för sent. Och hur verifierar du att 10 000 korrigerade e-postmeddelanden alla är intakta?
Redo att kontrollera om din brevlåda har datumproblem? Kör en gratis analys med Redate.io - ingen betalning krävs för att se hur många e-postmeddelanden som berörs.