Kāpēc migrācijas kontrolsaraksts ir neaizstājams
E-pasta migrācija ir viena no riskantākajām IT operācijām, ko organizācija var veikt. Tiek pārvietoti gadiem ilgi uzkrāti profesionālie saziņas dati starp platformām, un viens izlaidums var sabojāt visu pastkašu metadatus. Visbiežāk cietusī? E-pastu datumi. Pēc migrācijas katram e-pastam draud rādīt migrācijas datumu, nevis oriģinālo nosūtīšanas vai saņemšanas datumu.
Šis kontrolsaraksts aptver katru migrācijas procesa fāzi. Sekojiet šiem soļiem, lai minimizētu datumu sabojāšanas un citu metadatu problēmu risku. Un ja migrācija jau ir pabeigta un datumu problēmas ir parādījušās, turpiniet lasīt.
1. fāze: pirmsmigrācijas plānošana
Inventarizēt pastkastes
Pirms jebkura migrācijas rīka pieskaršanās dokumentējiet katru pastkasti, kas tiks migrēta. Reģistrējiet kopējo pastkašu skaitu, aptuveno e-pastu skaitu katrā pastkastē, vecāko e-pastu datumu diapazonu un kopīgās pastkastes vai izplatīšanas grupas. Šis inventārs nosaka, kuru migrācijas rīku izmantot, cik ilgi migrācija prasīs un kāds tarifs piemērojas iespējamajai pēcmigrācijas labošanai.
Izvēlēties pareizo migrācijas rīku
Ne visi migrācijas rīki apstrādā datumus vienādi. Izpētiet, kā katrs rīks apstrādā IMAP INTERNALDATE saglabāšanu un vai tas pievieno "Received" galvenes APPEND procesa laikā. Populārie rīki ietver BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO un Exchange administrēšanas centra iebūvēto importu. Katrs no šiem rīkiem var izraisīt datumu problēmas, jo pats IMAP protokols prasa galamērķa serverim pievienot "Received" galveni ievietošanas laikā. Taču daži rīki labāk saglabā INTERNALDATE nekā citi. Lai labāk izprastu INTERNALDATE darbību, skatiet IMAP INTERNALDATE: kāpēc datumi sabojājas.
Visu dublēt
Izveidojiet pilnu katras pastkastes dublējumkopiju pirms migrācijas. Šī dublējumkopija kalpo gan kā drošības tīkls, gan kā atsauces punkts datumu verificēšanai pēc tam. Google Workspace gadījumā izmantojiet Google Takeout vai trešās puses dublēšanas rīku. Microsoft 365 gadījumā izmantojiet Exchange Online dublējumkopiju vai PST eksportu. IMAP serveriem izmantojiet imapsync lokālas kopijas izveidei.
Glabājiet dublējumkopijas pilnībā atsevišķā vietā no avota un galamērķa serveriem.
Dokumentēt oriģinālos datumus
Atlasiet 10 līdz 20 e-pastus katrā pastkastē, kas sadalīti dažādos datumu diapazonos (vecākie, jaunākie un vairāki starplaikā). Reģistrējiet katra e-pasta "Saņemts" datumu, "Nosūtīts" datumu un neapstrādātās galvenes. Šie atsauces e-pasti kļūst par verifikācijas bāzi pēc migrācijas.
2. fāze: testa migrācija
Vispirms migrēt testa pastkasti
Nekad nepalaidiet pilnu migrāciju bez iepriekšējas testēšanas.
Izveidojiet testa pastkasti ar reprezentatīvu e-pastu izlasi (vismaz 100, aptverot vairākus gadus). Palaidiet migrāciju tikai šai vienai pastkastei un padziļināti pārbaudiet rezultātus pirms turpināšanas. Šis tests atklāj datumu problēmas, kodēšanas kļūdas, pielikumu apstrādes defektus un mapju struktūras neatbilstības, pirms tās skar ražošanas pastkastes.
Verificēt datumus testa pastkastē
Pēc testa pastkastes migrēšanas nekavējoties verificējiet datumus. Atveriet pastkasti e-pasta klientā, ko faktiski izmantos galalietotāji (Outlook, Apple Mail, Thunderbird vai tīmekļa pasta saskarne). Salīdziniet attēlotos datumus ar 1. fāzē dokumentētajiem atsauces e-pastiem. Pārbaudiet gan "Saņemts", gan "Nosūtīts" datumus.
Ja datumi ir nepareizi testa pastkastē, tie būs nepareizi visās pastkastēs. Apturiet visu un atrisiniet problēmu pirms pilnas migrācijas turpināšanas.
Testēt 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 pareizos datumus (tā izmanto "Date" galveni), kamēr Outlook rāda migrācijas datumu (tas piešķir prioritāti "Received" galvenei). Testējiet ar katru klientu, ko organizācijas lietotāji izmanto, tostarp Outlook darbvirsmu, Outlook tīmeklī, Apple Mail, Thunderbird un jebkuru mobilo e-pasta lietotni.
3. fāze: migrācijas izpilde
Migrācijas rīka konfigurēšana
Konfigurējiet migrācijas rīku, lai saglabātu INTERNALDATE cik vien iespējams. imapsync gadījumā izmantojiet atbilstošos karodziņus INTERNALDATE iestatīšanai galamērķī. BitTitan MigrationWiz gadījumā pārbaudiet papildu iestatījumus datumu apstrādes opcijām. Šie iestatījumi pilnībā nenovērsīs "Received" galvenes problēmas, bet tie samazina datumu problēmu smagumu dažos klientos.
Migrēt pa partijām
Nemigrējiet visas pastkastes vienlaicīgi. Migrējiet pa 10 līdz 20 pastkašu partijām, verificējot datumus pēc katras partijas. Ja partija uzrāda datumu problēmas, jūs to atklājat, pirms visa organizācija ir skarta. Starp citu, migrācija pa partijām arī samazina slodzi avota un galamērķa serveriem, mazinot taimautu vai savienojuma kļūdu risku, kas var izraisīt daļējas migrācijas.
Uzraudzīt progresu
Sekojiet migrācijas progresam katrai pastkastei. Reģistrējiet sākuma laiku, beigu laiku, migrēto e-pastu skaitu un visas kļūdas. Migrācijas rīki parasti sniedz žurnālus - saglabājiet tos katrai pastkastei.
4. fāze: pēcmigrācijas verifikācija
Nekavējoties verificēt datumus
Verificējiet e-pastu datumus 24 stundu laikā pēc migrācijas. Katrai partijai atveriet 5 līdz 10 pastkastes un salīdziniet datumus ar pirmsmigrācijas atsaucēm.
Pārbaudīt visus mapju veidus
Datumu problēmas var atšķirīgi skart dažādas mapes. Pārbaudiet datumus Ienākošajā pastā, Nosūtītajos vienumos, Melnrakstos un jebkurā pielāgotā mapē vai iezīmē.
Verificēt meklēšanu un kārtošanu
Atveriet migrētu pastkasti, kārtojiet pēc datuma un apstipriniet, ka hronoloģiskā secība atbilst oriģinālam. Meklējiet e-pastus pēc datumu diapazona un verificējiet rezultātu precizitāti.
Izplatītas kļūdas, kas izraisa datumu problēmas
Testa migrācijas izlaišana
Visizplatītākā kļūda ir migrēt visas pastkastes bez iepriekšējas testēšanas. Kad datumu problēmas tiek atklātas, visas pastkastes ir skartas un avota serveris, iespējams, jau ir deaktivizēts. 30 minūšu testa migrācija var novērst nedēļām ilgu koriģēšanu. Kāpēc to izlaist?
"Received" galveņu pievienošanas ignorēšana
Administratori bieži koncentrējas uz INTERNALDATE saglabāšanu un neievēro "Received" galvenes problēmu. Pat tad, kad INTERNALDATE ir pareizi iestatīts, migrācijas "Received" galvene liek Outlook un citiem klientiem rādīt nepareizo datumu. Skatiet kāpēc e-pasti rāda nepareizos datumus pēc migrācijas pilnam tehniskam skaidrojumam.
Avota servera pāragra deaktivizēšana
Ja datumu problēmas tiek atklātas pēc avota servera izslēgšanas, atkārtotas migrācijas opcija izzūd. Saglabājiet avota serveri pieejamu (kaut vai tikai lasīšanai) vismaz 30 dienas pēc migrācijas.
Ko darīt, ja datumi jau ir sabojāti
Ja migrācija jau ir veikta un datumi ir nepareizi, problēma ir labojama. Oriģinālā "Date" galvene ir 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 labošanas dzinējs pieslēdzas pastkastei un meklē e-pastus ar sabojātiem datuma metadatiem. Daudzpakāpju analīzes cauruļvads identificē migrācijas parakstus, piemēro mērķtiecīgus labojumus, vienlaikus saglabājot ziņojumu integritāti (tostarp S/MIME parakstus, daudzdalīgas struktūras un galvenes ar simboliem ārpus ASCII), un izpilda integritātes pārbaudi katram izlabotajam e-pastam. Analīze ir bezmaksas un rāda precīzi, cik e-pastu ir skarti. Oriģināli tiek saglabāti redzamā dublējumkopiju mapē 30 dienas.
Vai esat gatavi pārbaudīt, vai jūsu pastkastei ir datumu problēmas? Palaidiet bezmaksas analīzi ar Redate.io - nav nepieciešams maksājums, lai redzētu, cik e-pastu ir skarti.