Hvorfor en migreringscheckliste er nødvendig
E-mailmigrering er en af de mest risikable IT-operationer en organisation kan gennemføre. Du flytter årevis af professionel kommunikation mellem platforme, og én enkelt fejl kan ødelægge metadataene i samtlige postkasser. Det hyppigste offer? E-maildatoerne. Efter migrering risikerer hver eneste e-mail at vise migrationsdatoen i stedet for den oprindelige afsendelsesdato.
Denne tjekliste dækker hver fase af migreringen. Følg disse trin for at minimere risikoen for korrupte datoer og andre metadataproblemer. Og hvis migreringen allerede er afsluttet og der er dukket datoproblemer op, så læs videre.
Fase 1: planlægning før migrering
Registrer dine postkasser
Før du rører et migreringsværktøj, skal du dokumentere hver postkasse der skal migreres. Notér det samlede antal postkasser, det omtrentlige antal e-mails pr. postkasse, datointerval for de ældste e-mails og eventuelle delte postkasser eller distributionsgrupper. Denne oversigt afgør hvilket migreringsværktøj du skal bruge, hvor lang tid migreringen tager, og hvad en eventuel efterfølgende datokorrigering vil koste.
Vælg det rigtige migreringsværktøj
Ikke alle migreringsværktøjer håndterer datoer på samme måde. Undersøg hvordan hvert værktøj bevarer IMAP INTERNALDATE, og om det tilføjer "Received"-headere under APPEND-processen. Populære værktøjer inkluderer BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO og den native import i Exchange Administration Center. Alle disse kan forårsage datoproblemer, fordi IMAP-protokollen i sig selv kræver at destinationsserveren tilføjer en "Received"-header ved indsættelse. Men nogle værktøjer bevarer INTERNALDATE bedre end andre. Se IMAP INTERNALDATE: datoer ødelagt for en teknisk gennemgang.
Sikkerhedskopier alt
Opret en fuld backup af hver postkasse inden migreringen. Denne backup fungerer både som sikkerhedsnet og som referencepunkt til at verificere datoer bagefter. For Google Workspace bruger du Google Takeout eller et tredjeparts backupværktøj. For Microsoft 365 bruger du Exchange Online Backup eller PST-eksport. For IMAP-servere bruger du imapsync til at lave en lokal kopi.
Opbevar sikkerhedskopierne et sted der er fuldstændig adskilt fra kilde- og destinationsserverne.
Dokumentér de oprindelige datoer
Vælg 10 til 20 e-mails pr. postkasse fordelt over forskellige datointerval (de ældste, de nyeste og flere imellem). Notér modtagelsesdato, afsendelsesdato og de rå headere for hver e-mail. Disse reference-e-mails bliver din baseline til verifikation efter migrering. Tag et screenshot af postkassen sorteret efter dato, så du visuelt dokumenterer den oprindelige kronologiske rækkefølge.
Fase 2: testmigrering
Migrér en testpostkasse først
Start aldrig en fuld migrering uden at teste først.
Opret en testpostkasse med et repræsentativt udsnit af e-mails (mindst 100, fordelt over flere år). Kør migreringen på denne ene postkasse og undersøg resultaterne grundigt, inden du går videre. Denne test afslører datoproblemer, kodningsfejl, fejl i håndtering af vedhæftede filer og afvigelser i mappestrukturen, før de rammer produktionspostkasserne.
Verificér datoer på testpostkassen
Lige efter du har migreret testpostkassen, tjekker du datoerne med det samme. Åbn postkassen i den e-mailklient som slutbrugerne faktisk vil bruge (Outlook, Apple Mail, Thunderbird eller webmail). Sammenlign de viste datoer med de reference-e-mails du dokumenterede i Fase 1. Tjek både modtagelses- og afsendelsesdatoer. Åbn de rå headere på flere e-mails og kig efter nyligt tilføjede "Received"-headere med migreringstidsstemplet.
Hvis datoerne er forkerte på testpostkassen, vil de være forkerte på alle postkasser. Stop alt og løs problemet, før du fortsætter med den fulde migrering.
Test med flere e-mailklienter
Forskellige e-mailklienter viser datoer forskelligt. Gmails webgrænseflade kan vise korrekte datoer (den bruger "Date"-headeren), mens Outlook viser migrationsdatoen (den prioriterer "Received"-headeren). Test med hver klient som organisationens brugere anvender, herunder Outlook Desktop, Outlook på web, Apple Mail, Thunderbird og eventuelle mobile e-mailapplikationer.
Fase 3: gennemførelse af migrering
Konfiguration af migreringsværktøjet
Konfigurér migreringsværktøjet til at bevare INTERNALDATE så godt som muligt. I imapsync bruger du de relevante flag til at sætte INTERNALDATE på destinationen. I BitTitan MigrationWiz tjekker du de avancerede indstillinger for datobehandlingsmuligheder. Disse indstillinger forhindrer ikke "Received"-header-problemer helt, men de reducerer alvoren af datoproblemerne i visse klienter. Dokumentér samtlige konfigurationsindstillinger, så du kan genskabe migreringen om nødvendigt.
Migrér i batches
Migrér ikke alle postkasser på én gang. Kør i batches på 10 til 20 postkasser og verificér datoer efter hvert batch. Hvis et batch viser datoproblemer, opdager du det, inden hele organisationen er ramt. Migrering i batches reducerer desuden belastningen på kilde- og destinationsserverne og mindsker risikoen for timeouts eller forbindelsesfejl, der kan føre til delvise migreringer.
Overvåg fremgangen
Hold øje med migreringsforløbet for hver postkasse. Registrér starttidspunkt, sluttidspunkt, antal migrerede e-mails og eventuelle fejl. Migreringsværktøjer leverer normalt logs, bevar dem for hver postkasse. Hvis der opdages datoproblemer senere, hjælper logsene dig med at identificere præcist hvilket batch og hvilke indstillinger der var i brug.
Fase 4: verifikation efter migrering
Verificér datoer med det samme
Tjek e-maildatoerne inden for 24 timer efter migreringen. For hvert batch åbner du 5 til 10 postkasser og sammenligner datoerne med dine præ-migrerings-referencer. Hvis datoerne er forkerte, dokumentér omfanget af problemet (hvor mange postkasser er berørt, hvor mange e-mails pr. postkasse) mens informationerne er friske.
Tjek alle mappetyper
Datoproblemer kan påvirke visse mapper forskelligt. Tjek datoer i Indbakken, Sendt post, Kladder og alle brugerdefinerede mapper eller etiketter. Visse migreringsværktøjer behandler mapper sekventielt, og fejl i én mappe betyder ikke nødvendigvis fejl i de andre.
Verificér søgning og sortering
Åbn en migreret postkasse, sortér efter dato og bekræft at den kronologiske rækkefølge svarer til originalen. Søg efter e-mails inden for et datointerval og verificér at resultaterne er korrekte. Test alle automatiserede regler eller filtre der er afhængige af modtagelsesdatoer. Hvis organisationen bruger compliance- eller eDiscovery-værktøjer, kontrollér at datobaserede forespørgsler returnerer korrekte resultater.
Typiske fejl der forårsager datoproblemer
At springe testmigreringen over
Den hyppigste fejl er at migrere alle postkasser uden at teste først. Når datoproblemerne opdages, er alle postkasser ramt og kildeserveren er måske allerede lukket ned. En testmigrering på 30 minutter kan spare uger af oprydningsarbejde. Altså, hvorfor springe det over?
At ignorere tilføjede "Received"-headere
Administratorer fokuserer ofte på at bevare INTERNALDATE og overser problemet med "Received"-headere. Selv når INTERNALDATE er korrekt sat, medfører migrationens "Received"-header at Outlook og andre klienter viser den forkerte dato. Det er den hyppigste kilde til klager efter migrering. Læs hvorfor e-mails viser forkerte datoer efter migrering for en fuld teknisk forklaring.
At nedlægge kildeserveren for hurtigt
Hvis der opdages datoproblemer efter kildeserveren er lukket, forsvinder muligheden for re-migrering. Hold kildeserveren tilgængelig (selv i skrivebeskyttet tilstand) i mindst 30 dage efter migreringen. Det giver en fallback-mulighed, hvis alvorlige problemer dukker op senere.
Hvad du gør, hvis datoerne allerede er forkerte
Hvis migreringen allerede er gennemført og datoerne er forkerte, kan problemet rettes. Den oprindelige "Date"-header er bevaret i hver e-mail, hvilket betyder at den korrekte datoinformation stadig findes. E-maildatoer kan rettes efter migrering, selv måneder eller år senere.
Redate.io's proprietære korrektionsmotor forbinder sig til postkassen og søger efter e-mails med korrupte datometadata. Den flertrinede analysepipeline identificerer migreringssignaturer, anvender målrettede korrektioner og bevarer meddelelsernes integritet (herunder S/MIME-signaturer, multipart-strukturer og non-ASCII-headere), og udfører en integritetskontrol på hver korrigeret e-mail. Analysen er gratis og viser præcist, hvor mange e-mails der er berørt. Originalerne bevares i en synlig backup-mappe i 30 dage.
At forsøge denne slags korrektion manuelt eller med et hjemmelavet script er fristende, men risikabelt. Særtilfælde som PGP-krypterede beskeder, korrupte MIME-grænser, indlejrede multipart-strukturer og Content-Transfer-Encoding-forskydninger kan stille og roligt ødelægge e-mails, uden at man opdager det, før det er for sent. Og hvordan verificerer du at 10.000 korrigerede e-mails alle er intakte?
Klar til at tjekke om din postkasse har datoproblemer? Start en gratis analyse med Redate.io - ingen betaling kræves for at se, hvor mange e-mails der er berørt.