Hvorfor en migreringssjekkliste er uunnvaerlig
E-postmigrering er en av de mest risikofylte IT-operasjonene en organisasjon kan gjennomfoere. Du flytter aarevis med profesjonell kommunikasjon mellom plattformer, og en eneste forglemmelse kan korruptere metadata i alle postkasser. Det hyppigste offeret? E-postdatoene. Etter migrering risikerer hver e-post aa vise migreringsdatoen i stedet for den opprinnelige sende- eller mottaksdatoen.
Denne sjekklisten dekker hver fase av migreringsprosessen. Foelg disse stegene for aa minimere risikoen for datokorrupsjon og andre metadataproblemer. Og hvis migreringen allerede er fullfoert og datoproblemer har dukket opp, les videre.
Fase 1: planlegging foer migrering
Kartlegg postkassene
Foer du roerer et migreringsverktoy, dokumenter hver postkasse som skal migreres. Registrer totalt antall postkasser, omtrentlig antall e-poster per postkasse, datointervall for de eldste e-postene, og delte postkasser eller distribusjonsgrupper. Denne kartleggingen bestemmer hvilket migreringsverktoy som skal brukes, hvor lang tid migreringen tar, og hvilken pris som gjelder for eventuelle korreksjoner etter migrering.
Velg riktig migreringsverktoy
Ikke alle migreringsverktoy haandterer datoer paa samme maate. Undersoek hvordan hvert verktoy haandterer bevaring av IMAP INTERNALDATE og om det legger til "Received"-headere under APPEND-prosessen. Populaere verktoy inkluderer BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO og Exchange Admin Centers innebygde import. Hvert av disse verktoyene kan foraarsake datoproblemer fordi IMAP-protokollen selv krever at maalserveren legger til en "Received"-header ved innsetting. Men noen verktoy bevarer INTERNALDATE bedre enn andre. For aa forstaa hvordan INTERNALDATE fungerer, se IMAP INTERNALDATE: hvorfor datoer oedelegges.
Sikkerhetskopier alt
Opprett en fullstendig sikkerhetskopi av hver postkasse foer migreringen. Denne sikkerhetskopien fungerer baade som sikkerhetsnett og referansepunkt for aa verifisere datoer i ettertid. For Google Workspace, bruk Google Takeout eller et tredjeparts sikkerhetskopieringsverktoy. For Microsoft 365, bruk Exchange Online-sikkerhetskopiering eller PST-eksport. For IMAP-servere, bruk imapsync for aa opprette en lokal kopi.
Lagre sikkerhetskopiene paa et sted fullstendig adskilt fra kilde- og maalserverne.
Dokumenter opprinnelige datoer
Velg 10 til 20 e-poster per postkasse fordelt paa ulike datointervaller (de eldste, de nyeste og flere mellom). Registrer "Mottatt"-datoen, "Sendt"-datoen og raaheaderne for hver e-post. Disse referanse-e-postene blir din verifikasjonsbase etter migrering. Ta et skjermbilde av postkassen sortert etter dato for aa dokumentere den opprinnelige kronologiske rekkfoelgen visuelt.
Fase 2: testmigrering
Migrer en testpostkasse foerst
Start aldri en fullstendig migrering uten aa teste foerst.
Opprett en testpostkasse med et representativt utvalg e-poster (minst 100, som spenner over flere aar). Kjoer migreringen paa denne ene postkassen og undersoek resultatene grundig foer du gaar videre. Denne testen avdekker datoproblemer, kodingsfeil, vedleggshaandteringsproblemer og mappestrukturavvik foer de rammer produksjonspostkassene.
Verifiser datoer paa testpostkassen
Etter aa ha migrert testpostkassen, verifiser datoene umiddelbart. Aapne postkassen i e-postklienten sluttbrukerne faktisk vil bruke (Outlook, Apple Mail, Thunderbird eller webmailgrensesnittet). Sammenlign viste datoer med referanse-e-postene dokumentert i fase 1. Sjekk baade "Mottatt"- og "Sendt"-datoer. Aapne raaheaderne til flere e-poster og se etter nylig tillagte "Received"-headere med migreringstidsstempelet.
Hvis datoene er feil paa testpostkassen, vil de vaere feil paa alle postkasser. Stopp og loes problemet foer du gaar videre med fullstendig migrering.
Test med flere e-postklienter
Ulike e-postklienter viser datoer forskjellig. Gmails webgrensesnitt kan vise korrekte datoer (det bruker "Date"-headeren) mens Outlook viser migreringsdatoen (det prioriterer "Received"-headeren). Test med hver klient organisasjonens brukere benytter, spesielt Outlook Desktop, Outlook paa nettet, Apple Mail, Thunderbird og eventuelle mobile e-postapper.
Fase 3: gjennomfoering av migrering
Konfigurasjon av migreringsverktoy
Konfigurer migreringsverktoeyet til aa bevare INTERNALDATE saa godt som mulig. I imapsync, bruk de riktige flaggene for aa sette INTERNALDATE paa destinasjonen. I BitTitan MigrationWiz, sjekk avanserte innstillinger for datohaandteringsalternativer. Disse innstillingene vil ikke fullstendig forhindre "Received"-headerproblemer, men de reduserer alvorlighetsgraden av datoproblemer i noen klienter. Dokumenter hver konfigurasjonsinnstilling som brukes, saa du kan reprodusere migreringen om noedvendig.
Migrer i batcher
Ikke migrer alle postkasser samtidig. Migrer i batcher paa 10 til 20 postkasser og verifiser datoer etter hver batch. Hvis en batch viser datoproblemer, oppdager du det foer hele organisasjonen er rammet. Forresten, batchmigrering reduserer ogsaa belastningen paa kilde- og maalservere, noe som senker risikoen for tidsavbrudd eller tilkoblingsfeil som kan foraarsake ufullstendige migreringer.
Overvaak fremdriften
Spoer migreringens fremdrift for hver postkasse. Registrer starttidspunkt, sluttidspunkt, antall migrerte e-poster og eventuelle feil. Migreringsverktoy gir vanligvis logger - bevar dem for hver postkasse. Hvis datoproblemer oppdages senere, hjelper loggene med aa identifisere noeyaktig hvilken migreringsbatch og hvilke innstillinger som ble brukt.
Fase 4: verifisering etter migrering
Verifiser datoer umiddelbart
Verifiser e-postdatoer innen 24 timer etter migreringen. For hver batch, aapne 5 til 10 postkasser og sammenlign datoer med referansene fra foer migreringen. Hvis datoene er feil, dokumenter omfanget av problemet (hvor mange postkasser er paavirket, hvor mange e-poster per postkasse) mens informasjonen er fersk.
Sjekk alle mappetyper
Datoproblemer kan paavirke noen mapper annerledes. Verifiser datoer i Innboks, Sendte elementer, Utkast og eventuelle egendefinerte mapper eller etiketter. Noen migreringsverktoy behandler mapper sekvensielt, og feil i en mappe indikerer ikke noedvendigvis feil i de andre.
Verifiser soek og sortering
Aapne en migrert postkasse, sorter etter dato og bekreft at den kronologiske rekkfoelgen samsvarer med originalen. Soek etter e-poster etter datointervall og verifiser at resultatene er noeyaktige. Test eventuelle automatiserte regler eller filtre som avhenger av mottaksdatoer. Hvis organisasjonen bruker samsvars- eller eDiscovery-verktoy, verifiser at datobaserte sporringer gir korrekte resultater.
Vanlige feil som foraarsaker datoproblemer
Hoppe over testmigreringen
Den vanligste feilen er aa migrere alle postkasser uten aa teste foerst. Naar datoproblemer oppdages, er alle postkasser paavirket og kildeserveren er kanskje allerede deaktivert. En testmigrering paa 30 minutter kan forhindre uker med opprydding. Hvorfor unnlate det?
Ignorere tillagte "Received"-headere
Administratorer fokuserer ofte paa aa bevare INTERNALDATE og overser "Received"-headerproblemet. Selv naar INTERNALDATE er korrekt satt, faar migrerings-"Received"-headeren Outlook og andre klienter til aa vise feil dato. Det er den hyppigste kilden til klager etter migrering. Les hvorfor e-poster viser feil dato etter migrering for en fullstendig teknisk forklaring.
Deaktivere kildeserveren for tidlig
Hvis datoproblemer oppdages etter at kildeserveren er tatt ned, forsvinner re-migreringsalternativet. Behold kildeserveren tilgjengelig (selv i skrivebeskyttet modus) i minst 30 dager etter migreringen. Dette gir en reserveloesning hvis alvorlige problemer dukker opp senere.
Hva du gjoer hvis datoene allerede er feil
Hvis migreringen allerede er gjennomfoert og datoene er feil, er problemet reparerbart. Den opprinnelige "Date"-headeren er bevart i hver e-post, noe som betyr at korrekt datoinformasjon fortsatt eksisterer. E-postdatoer kan korrigeres etter migrering, selv maaneder eller aar senere.
Redate.ios proprietaere korreksjonsmotor kobler til postkassen og soeker etter e-poster med korrupte datometadata. Den flertrinns analysepipelinen identifiserer migreringssignaturer, anvender maalrettede korreksjoner mens meldingsintegriteten bevares (inkludert S/MIME-signaturer, multipart-strukturer og ikke-ASCII-headere), og kjoerer en integritetssjekk paa hver korrigert e-post. Analysen er gratis og viser noeyaktig hvor mange e-poster som er berort. Originaler bevares i en synlig sikkerhetskopimappe i 30 dager.
Aa forsoeke denne typen korrigering manuelt eller med et egendefinert skript er fristende men risikabelt. Spesialtilfeller som PGP-krypterte meldinger, korrupte MIME-grenser, nestede multipart-strukturer og Content-Transfer-Encoding-forskyvninger kan stille korruptere e-poster uten at du merker det foer det er for sent. Og hvordan verifiserer du at 10 000 korrigerte e-poster alle er intakte?
Klar til aa sjekke om postkassen din har datoproblemer? Kjoer en gratis analyse med Redate.io - ingen betaling kreves for aa se hvor mange e-poster som er berort.