Sjekkliste for e-postmigrering: unngå datotrøbbel

Hvorfor en migreringsjekkliste er verdt det

E-postmigrering er blant de mest risikofylte IT-operasjonene en organisasjon kan gjennomføre. Du flytter årevis med profesjonell kommunikasjon mellom plattformer, og én enkelt glemsel kan ødelegge metadataene i alle postbokser. Det vanligste offeret? E-postdatoene. Etter migrering risikerer hver e-post å vise migrasjonsdatoen i stedet for den opprinnelige sendte- eller mottattdatoen.

Denne sjekklisten dekker hver fase i migreringsprosessen. Følg stegene for å minimere risikoen for datumkorrupsjon og andre metadataproblemer. Og hvis migreringen allerede er gjennomført og datotrøbbelet har dukket opp, les videre.

Fase 1: planlegging før migrering

Kartlegg postboksene

Før du rører et migreringverktøy, dokumenter hver postboks som skal migreres. Registrer totalt antall postbokser, omtrentlig antall e-poster per postboks, datointervallet for de eldste e-postene, og delte postbokser eller distribusjonsgrupper. Denne kartleggingen avgjør hvilket migrerings-verktøy du bør bruke, hvor lang tid migreringen vil ta, og hva slags prissetting som gjelder for eventuelle korreksjoner etterpå.

Velg riktig migrerings-verktøy

Ikke alle migrerings-verktøy håndterer datoer på samme måte. Undersøk hvordan hvert verktøy håndterer bevaring av IMAP INTERNALDATE, og om det legger til "Received"-headere under APPEND-prosessen. Populære verktøy inkluderer BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO og den innebygde importen i Exchange Admin Center. Alle disse kan forårsake datotrøbbel fordi selve IMAP-protokollen krever at målserveren legger til en "Received"-header ved innsetting. Noen verktøy bevarer likevel INTERNALDATE bedre enn andre. For å forstå hvordan INTERNALDATE fungerer, se IMAP INTERNALDATE: derfor ødelegges datoer.

Ta backup av alt

Opprett en fullstendig sikkerhetskopi av hver postboks før migreringen starter. Denne backupen fungerer både som sikkerhetsnett og som referansepunkt for å verifisere datoer i etterkant. For Google Workspace bruker du Google Takeout eller et tredjeparts backup-verktøy. For Microsoft 365 bruker du Exchange Online Backup eller PST-eksport. For IMAP-servere bruker du imapsync for å lage en lokal kopi.

Lagre sikkerhetskopiene på et sted som er helt atskilt fra kilde- og målserverne.

Dokumenter de opprinnelige datoene

Velg ut 10 til 20 e-poster per postboks, spredt over ulike datoperioder (de eldste, de nyeste og noen fra midten). Registrer "Mottatt"-datoen, "Sendt"-datoen og de rå headerne for hver e-post. Disse referanse-e-postene blir grunnlaget for verifisering etter migreringen. Ta et skjermbilde av postboksen sortert etter dato for å dokumentere den opprinnelige kronologiske rekkefølgen visuelt.

Fase 2: testmigrering

Migrer en testpostboks først

Start aldri en fullstendig migrering uten å teste på forhånd.

Opprett en testpostboks med et representativt utvalg e-poster (minst 100, fordelt over flere år). Kjør migreringen på denne ene postboksen og gå gjennom resultatene grundig før du fortsetter. Denne testen avslører datotrøbbel, kodingsfeil, problemer med vedlegg og mappestrukturavvik, lenge før de rekker å påvirke produksjonspostboksene.

Verifiser datoene i testpostboksen

Etter at testpostboksen er migrert, sjekk datoene umiddelbart. Åpne postboksen i e-postklienten sluttbrukerne faktisk kommer til å bruke (Outlook, Apple Mail, Thunderbird eller webmail). Sammenlign de viste datoene med referanse-e-postene du dokumenterte i fase 1. Sjekk både "Mottatt"- og "Sendt"-datoene. Åpne de rå headerne i noen e-poster og let etter nylig tillagte "Received"-headere med migreringstidsstempel.

Hvis datoene er feil i testpostboksen, vil de være feil i alle postbokser. Stopp alt og løs problemet før du går videre med full migrering.

Test med flere e-postklienter

Ulike e-postklienter viser datoer på forskjellige måter. Gmails webgrensesnitt kan vise korrekte datoer (det bruker "Date"-headeren), mens Outlook viser migrasjonsdatoen (det prioriterer "Received"-headeren). Test med alle klienter som brukes i organisasjonen, blant annet Outlook Desktop, Outlook på nettet, Apple Mail, Thunderbird og eventuelle mobile e-postapper.

Fase 3: gjennomføring av migreringen

Konfigurer migrerings-verktøyet

Konfigurer verktøyet slik at det bevarer INTERNALDATE så godt som mulig. I imapsync bruker du riktige flagg for å sette INTERNALDATE på destinasjonen. I BitTitan MigrationWiz går du gjennom de avanserte innstillingene for datohåndtering. Disse innstillingene hindrer ikke "Received"-headerproblemer fullstendig, men de reduserer alvorligheten av datotrøbbelet i visse klienter. Dokumenter alle konfigurasjons-innstillinger slik at du kan gjenskape migreringen om nødvendig.

Migrer i bolker

Ikke migrer alle postbokser samtidig. Kjør migreringen i bolker på 10 til 20 postbokser og verifiser datoene etter hver bolk. Oppdager du datotrøbbel i én bolk, fanger du det opp før hele organisasjonen er rammet. Migrering i bolker reduserer dessuten belastningen på kilde- og målservere, noe som minsker risikoen for tidsavbrudd eller tilkoblingsfeil som kan gi ufullstendige migreringer.

Følg med på fremdriften

Overvåk migreringen for hver postboks. Registrer starttidspunkt, sluttidspunkt, antall migrerte e-poster og eventuelle feil. Migrerings-verktøy leverer vanligvis loggfiler, behold dem for hver postboks. Hvis datotrøbbel oppdages senere, hjelper loggene deg å identifisere nøyaktig hvilken migreringsbolk og hvilke innstillinger som ble brukt.

Fase 4: verifisering etter migrering

Verifiser datoene umiddelbart

Sjekk e-postdatoene innen 24 timer etter migreringen. For hver bolk åpner du 5 til 10 postbokser og sammenligner datoene med referansene fra før migreringen. Hvis datoene er feil, dokumenter omfanget av problemet (hvor mange postbokser som er berørt, og omtrent hvor mange e-poster per postboks) mens informasjonen er fersk.

Sjekk alle mappetyper

Datotrøbbel kan ramme enkelte mapper forskjellig. Sjekk datoene i Innboks, Sendte elementer, Utkast og alle egendefinerte mapper eller etiketter. Noen migrerings-verktøy behandler mapper sekvensielt, og feil i én mappe betyr ikke nødvendigvis feil i de andre.

Verifiser søk og sortering

Åpne en migrert postboks, sorter etter dato og bekreft at den kronologiske rekkefølgen stemmer med originalen. Søk etter e-poster i et datoperiode og kontroller at resultatene er korrekte. Test alle automatiserte regler eller filtre som er avhengige av mottattdato. Bruker organisasjonen compliance- eller eDiscovery-verktøy, verifiser at datobaserte spørringer gir korrekte resultater.

Vanlige feil som fører til datotrøbbel

Hoppe over testmigreringen

Den vanligste feilen er å migrere alle postbokser uten å teste først. Når datotrøbbelet oppdages, er alle postbokser allerede rammet og kildeserveren er kanskje allerede slått av. En testmigrering på 30 minutter kan spare deg for uker med feilretting. Hvorfor ta sjansen?

Ignorere tillagte "Received"-headere

Administratorer fokuserer ofte på å bevare INTERNALDATE og overser "Received"-headerproblemet. Selv når INTERNALDATE er riktig satt, gjør migrations-"Received"-headeren at Outlook og andre klienter viser feil dato. Dette er den hyppigste årsaken til klager etter migrering. Les hvorfor e-poster viser feil dato etter migrering for en fullstendig teknisk forklaring.

Skru av kildeserveren for tidlig

Hvis datotrøbbel oppdages etter at kildeserveren er stengt ned, forsvinner muligheten for re-migrering. Hold kildeserveren tilgjengelig (selv i skrivebeskyttet modus) i minst 30 dager etter migreringen. Det gir deg en fallback hvis alvorlige problemer dukker opp senere.

Hva du gjør hvis datoene allerede er feil

Har migreringen allerede blitt gjennomført og datoene er feil, er problemet mulig å rette. Den opprinnelige "Date"-headeren er bevart i hver e-post, noe som betyr at den korrekte datoinformasjonen fortsatt eksisterer. E-postdatoer kan korrigeres etter migrering, selv måneder eller år i etterkant.

Redate.ios proprietære korreksjonsmotor kobler seg til postboksen og søker etter e-poster med korrupte datometadata. Den flertrinns analysepipelinen identifiserer migrasjonssignaturer, anvender målrettede korreksjoner mens meldingsintegriteten bevares (inkludert S/MIME-signaturer, multipart-strukturer og ikke-ASCII-headere), og kjører en integritetssjekk på hver korrigert e-post. Analysen er gratis og viser nøyaktig hvor mange e-poster som er berørt. Originalene beholdes i en synlig backupmappe i 30 dager.

Det kan friste å forsøke denne typen korrigering manuelt eller med et egenlaget skript, men det er risikabelt. Spesialtilfeller som PGP-krypterte meldinger, korrupte MIME-grenser, nestede multipart-strukturer og Content-Transfer-Encoding-avvik kan stille og rolig ødelegge e-poster uten at du merker det, inntil det er for sent. Og hvordan verifiserer du egentlig at 10 000 korrigerte e-poster alle er intakte?

Klar til å sjekke om postboksen din har datotrøbbel? Start en gratis analyse med Redate.io - ingen betaling kreves for å se hvor mange e-poster som er berørt.