E-pasta migrācijas kontrolsaraksts: datumu problēmu novēršana

Kāpēc migrācijas kontrolsaraksts ir nepieciešams

E-pasta migrācija ir viena no riskantākajām IT operācijām, ko organizācija var veikt. Tiek pārvietoti gadu garumā uzkrāti profesionālie sarakste materiāli starp platformām, un viens aizmirsts solis var sabojāt metadatus visās pastkastēs. Biežākais cietušais? E-pastu datumi. Pēc migrācijas katrs e-pasts var rādīt migrācijas datumu, nevis sākotnējo nosūtīšanas vai saņemšanas datumu.

Šis kontrolsaraksts aptver katru migrācijas procesa posmu. Izpildiet šīs darbības, lai samazinātu datumu bojājumu un citu metadatu problēmu risku. Ja migrācija jau ir pabeigta un datumu problēmas ir parādījušās, lasiet tālāk.

1. posms: pirmsmigracijas plānošana

Pastkastīšu inventarizācija

Pirms pieskarties kādam migrācijas rīkam, dokumentējiet katru pastkastīti, kas tiks migrēta. Reģistrējiet kopējo pastkastīšu skaitu, aptuveno e-pastu skaitu katrā pastkastītē, vecāko e-pastu datumu diapazonu un koplietotās pastkastītes vai izplatīšanas grupas. Šis inventārs nosaka, kādu migrācijas rīku izmantot, cik ilga būs migrācija un kādi tarifu nosacījumi attieksies uz iespējamajām pēcmigrācijas korekcijām.

Piemērota migrācijas rīka izvēle

Ne visi migrācijas rīki apstrādā datumus vienādi. Noskaidrojiet, kā katrs rīks pārvalda IMAP INTERNALDATE saglabāšanu un vai APPEND procesa laikā tiek pievienoti "Received" galvenes. Populārie rīki ietver BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO un Exchange Administration Center iebūvēto importu. Katrs no šiem rīkiem var radīt datumu problēmas, jo pats IMAP protokols prasa, lai galamērķa serveris pievienotu "Received" galveni ievietošanas laikā. Tomēr daži rīki labāk saglabā INTERNALDATE nekā citi. Lai labāk izprastu INTERNALDATE darbību, skatiet IMAP INTERNALDATE: kāpēc datumi tiek bojāti.

Viss jāsaglabā dublējumkopijās

Pirms migrācijas izveidojiet pilnu katras pastkastītes dublējumkopiju. Šī dublējumkopija kalpo gan kā drošības tīkls, gan kā atsauces punkts datumu pārbaudei pēc migrācijas. Google Workspace gadījumā izmantojiet Google Takeout vai trešās puses dublēšanas rīku. Microsoft 365 gadījumā izmantojiet Exchange Online dublēšanu vai PST eksportu. IMAP serveriem izmantojiet imapsync, lai izveidotu lokālu kopiju.

Glabājiet dublējumkopijas vietā, kas ir pilnīgi atdalīta no avota un galamērķa serveriem.

Sākotnējo datumu dokumentēšana

Katrā pastkastītē atlasiet 10 līdz 20 e-pastus, kas aptver dažādus datumu diapazonus (vecākos, jaunākos un vairākus starpposma). Reģistrējiet katra e-pasta saņemšanas datumu, nosūtīšanas datumu un neapstrādātas galvenes. Šie atsauces e-pasti kļūst par jūsu pārbaudes pamatu pēc migrācijas. Uzņemiet ekrānuzņēmumu no pastkastītes, kas kārtota pēc datuma, lai vizuāli dokumentētu sākotnējo hronoloģisko secību.

2. posms: testmigrācija

Vispirms migrējiet testa pastkastīti

Nekad nesāciet pilnu migrāciju bez iepriekšējas testēšanas.

Izveidojiet testa pastkastīti ar reprezentatīvu e-pastu izlasi (vismaz 100, aptverot vairākus gadus). Palaidiet migrāciju tikai šai pastkastītei un pirms turpināšanas rūpīgi izpētiet rezultātus. Šis tests atklāj datumu problēmas, kodēšanas kļūdas, pielikumu apstrādes kļūdas un mapju struktūras neatbilstības, pirms tās ietekmē ražošanas pastkastītes.

Datumu pārbaude testa pastkastītē

Pēc testa pastkastītes migrācijas nekavējoties pārbaudiet datumus. Atveriet pastkastīti e-pasta klientā, kuru gala lietotāji faktiski izmantos (Outlook, Apple Mail, Thunderbird vai tīmekļa pasta saskarne). Salīdziniet rādītos datumus ar 1. posmā dokumentētajiem atsauces e-pastiem. Pārbaudiet gan saņemšanas, gan nosūtīšanas datumus. Atveriet vairāku e-pastu neapstrādātās galvenes un meklējiet tikko pievienotas "Received" galvenes ar migrācijas laikspiedolu.

Ja datumi ir nepareizi testa pastkastītē, tie būs nepareizi visās pastkastītēs. Apturiet visu un novērsiet problēmu, pirms turpināt pilno migrāciju.

Testēšana ar vairākiem e-pasta klientiem

Dažādi e-pasta klienti rāda datumus atšķirīgi. Gmail tīmekļa saskarne var rādīt pareizus datumus (izmanto "Date" galveni), bet Outlook rāda migrācijas datumu (tam prioritāte ir "Received" galvenei). Testējiet ar katru klientu, ko organizācijas lietotāji izmanto, tostarp Outlook Desktop, Outlook tīmekļa versiju, Apple Mail, Thunderbird un jebkuru mobilo e-pasta lietotni.

3. posms: migrācijas izpilde

Migrācijas rīka konfigurācija

Konfigurējiet migrācijas rīku, lai pēc iespējas labāk saglabātu INTERNALDATE. Imapsync gadījumā izmantojiet atbilstošus karodziņus, lai galamērķī iestatītu INTERNALDATE. BitTitan MigrationWiz gadījumā pārbaudiet papildu iestatījumus datumu apstrādes opcijām. Šie iestatījumi pilnībā nenovērsīs "Received" galveņu problēmas, bet dažos klientos samazinās datumu problēmu smagumu. Dokumentējiet katru izmantoto konfigurācijas iestatījumu, lai vajadzības gadījumā varētu atkārtot migrāciju.

Migrācija pa partijām

Nemigrējiet visas pastkastītes vienlaicīgi. Migrējiet pa 10 līdz 20 pastkastītēm, pēc katras partijas pārbaudot datumus. Ja kādā partijā parādās datumu problēmas, jūs tās atklājat, pirms tiek ietekmēta visa organizācija. Starp citu, migrācija pa partijām arī samazina slodzi uz avota un galamērķa serveriem, mazinot taimauta vai savienojuma kļūdu risku, kas var izraisīt nepilnīgas migrācijas.

Progresa uzraudzība

Sekojiet migrācijas progresam katrai pastkastītei. Reģistrējiet sākuma laiku, beigu laiku, migrēto e-pastu skaitu un visas kļūdas. Migrācijas rīki parasti nodrošina žurnālus, saglabājiet tos katrai pastkastītei. Ja datumu problēmas tiek atklātas vēlāk, žurnāli palīdz precīzi noteikt, kura migrācijas partija un kādi parametri tika izmantoti.

4. posms: pēcmigrācijas pārbaude

Datumu pārbaude nekavējoties

Pārbaudiet e-pastu datumus 24 stundu laikā pēc migrācijas. Katrai partijai atveriet 5 līdz 10 pastkastītes un salīdziniet datumus ar pirmsmigracijas atsaucēm. Ja datumi ir nepareizi, dokumentējiet problēmas apmēru (cik pastkastīšu ir ietekmētas, cik e-pastu katrā pastkastītē), kamēr informācija ir svaiga.

Visu mapju tipu pārbaude

Datumu problēmas dažādās mapēs var izpausties atšķirīgi. Pārbaudiet datumus Iesūtnē, Nosūtītajos elementos, Melnrakstos un jebkurā pielāgotā mapē vai atzīmē. Daži migrācijas rīki apstrādā mapes secīgi, un kļūdas vienā mapē ne vienmēr nozīmē kļūdas citās.

Meklēšanas un kārtošanas pārbaude

Atveriet migrētu pastkastīti, kārtojiet pēc datuma un pārbaudiet, vai hronoloģiskā secība atbilst sākotnējai. Meklējiet e-pastus pēc datumu diapazona un pārbaudiet, vai rezultāti ir precīzi. Testējiet visus automatizētos noteikumus vai filtrus, kas ir atkarīgi no saņemšanas datumiem. Ja organizācija izmanto atbilstības vai eDiscovery rīkus, pārbaudiet, vai datumiem balstīti vaicājumi atgriež pareizus rezultātus.

Biežākās kļūdas, kas izraisa datumu problēmas

Testmigrācijas izlaišana

Visbiežākā kļūda ir visu pastkastīšu migrācija bez iepriekšējas testēšanas. Kad datumu problēmas tiek atklātas, visas pastkastītes jau ir ietekmētas un avota serveris varbūt jau ir atspējots. 30 minūšu testmigrācija var novērst nedēļas ilgu problēmu novēršanu. Kāpēc no tā atteikties?

"Received" galveņu papildinājumu ignorēšana

Administratori bieži koncentrējas uz INTERNALDATE saglabāšanu un neņem vērā "Received" galveņu problēmu. Pat ja INTERNALDATE ir pareizi iestatīts, migrācijas "Received" galvene liek Outlook un citiem klientiem rādīt nepareizu datumu. Tas ir visbiežākais pēcmigrācijas sūdzību avots. Lasiet kāpēc e-pastiem ir nepareizs datums pēc migrācijas, lai iegūtu pilnu tehnisko skaidrojumu.

Avota servera pārāk ātra atspējošana

Ja datumu problēmas tiek atklātas pēc avota servera izslēgšanas, atkārtotas migrācijas iespēja pazūd. Glabājiet avota serveri pieejamu (kaut vai tikai lasīšanas režīmā) vismaz 30 dienas pēc migrācijas. Tas nodrošina rezerves risinājumu, ja vēlāk parādīsies nopietnas problēmas.

Ko darīt, ja datumi jau ir bojāti

Ja migrācija jau ir veikta un datumi ir nepareizi, problēmu var labot. Sākotnējā "Date" galvene tiek saglabāta katrā e-pastā, kas nozīmē, ka pareizā datuma informācija joprojām pastāv. E-pastu datumus var labot pēc migrācijas, pat mēnešus vai gadus vēlāk.

Redate.io patentētais korekcijas dzinējs pieslēdzas pastkastītei un meklē e-pastus ar bojātiem datumu metadatiem. Daudzpakāpju analīzes cauruļvads identificē migrācijas parakstus, lieto mērķtiecīgas korekcijas, saglabājot ziņojumu integritāti (ieskaitot S/MIME parakstus, multipart struktūras un ne-ASCII galvenes), un veic integritātes pārbaudi katram labotajam e-pastam. Analīze ir bezmaksas un precīzi parāda, cik e-pastu ir ietekmēti. Oriģināli tiek saglabāti redzamā dublējumkopijas mapē 30 dienas.

Šāda veida korekcijas mēģinājums manuāli vai ar pielāgotu skriptu ir kārdināšana, bet tas ir riskanti. Īpašie gadījumi, piemēram, ar PGP šifrēti ziņojumi, bojātas MIME robežas, ligzdotas multipart struktūras un Content-Transfer-Encoding nobīdes var klusi sabojāt e-pastus, un jūs to nepamanīsiet, kamēr nebūs par vēlu. Un kā pārbaudīt, ka 10 000 laboti e-pasti visi ir neskarti?

Gatavs pārbaudīt, vai jūsu pastkastītei ir datumu problēmas? Sāciet bezmaksas analīzi ar Redate.io - maksājums nav nepieciešams, lai redzētu, cik e-pastu ir ietekmēti.