Hvorfor en migreringscheckliste er noedvendig
E-mailmigrering er en af de mest risikofyldte IT-operationer en organisation kan foretage. Man flytter aars professionel kommunikation mellem platforme, og en enkelt forglemmelse kan korrumpere metadata i alle postkasser. Det hyppigste offer? E-maildatoerne. Efter migrering risikerer hver e-mail at vise migreringsdatoen i stedet for den originale afsendelses- eller modtagelsesdato.
Denne checkliste daekker hver fase af migreringsprocessen. Foelg disse trin for at minimere risikoen for datokorruption og andre metadataproblemer. Og hvis migreringen allerede er faerdig og datoproblemer er dukket op, laes videre.
Fase 1: planlaegning foer migrering
Inventering af postkasser
Foer du roerer et migreringsvaerktoej, dokumenter hver postkasse der skal migreres. Registrer det totale antal postkasser, omtrentligt antal e-mails per postkasse, datointervallet for de aeldste e-mails, og delte postkasser eller distributionsgrupper. Denne inventering bestemmer hvilket migreringsvaerktoej der skal bruges, hvor lang tid migreringen tager, og hvilken pris der gaelder for eventuelle post-migreringskorrektioner.
Vaelg det rigtige migreringsvaerktoej
Ikke alle migreringsvaerktojer haandterer datoer ens. Undersog hvordan hvert vaerktoej haandterer bevarelse af IMAP INTERNALDATE, og om det tilfojer "Received"-headers under APPEND-processen. Populaere vaerktojer inkluderer BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO og Exchange Admin Centers native import. Hvert af disse vaerktojer kan foraarsage datoproblemer fordi selve IMAP-protokollen kraever at destinationsserveren tilfojer en "Received"-header ved indsaettelse. Men nogle vaerktojer bevarer INTERNALDATE bedre end andre. For at forstaa hvordan INTERNALDATE fungerer, se IMAP INTERNALDATE: hvorfor datoer gaar i stykker.
Tag backup af alt
Opret en komplet backup af hver postkasse foer migreringen. Denne backup fungerer baade som sikkerhedsnet og som referencepunkt for at verificere datoer bagefter. For Google Workspace, brug Google Takeout eller et tredjeparts-backupvaerktoej. For Microsoft 365, brug Exchange Online-backup eller PST-eksport. For IMAP-servere, brug imapsync til at oprette en lokal kopi.
Gem backups paa en placering der er fuldstaendig adskilt fra kilde- og destinationsserverne.
Dokumenter originale datoer
Vaelg 10 til 20 e-mails per postkasse fordelt over forskellige datointervaller (de aeldste, de nyeste og flere mellemliggende). Registrer "Modtaget"-dato, "Sendt"-dato og raa headers for hver e-mail. Disse reference-e-mails bliver dit verifikationsgrundlag efter migrering. Tag et screenshot af postkassen sorteret efter dato for visuelt at dokumentere den originale kronologiske raekkefoelge.
Fase 2: testmigrering
Migrer en testpostkasse foerst
Start aldrig en fuld migrering uden at teste foerst.
Opret en testpostkasse med et repraesentativt udvalg af e-mails (mindst 100, spaendende over flere aar). Koer migreringen paa denne ene postkasse og undersog resultaterne grundigt foer du fortsaetter. Denne test afslorer datoproblemer, encodingfejl, vedhaeftningshaandteringsfejl og mappestrukturafvigelser foer de rammer produktionspostkasserne.
Verificer datoer paa testpostkassen
Efter migrering af testpostkassen verificeres datoer straks. Aabn postkassen i den e-mailklient slutbrugerne faktisk vil bruge (Outlook, Apple Mail, Thunderbird eller webmail-graensefladen). Sammenlign de viste datoer med de reference-e-mails dokumenteret i Fase 1. Tjek baade "Modtaget"- og "Sendt"-datoer. Aabn raa headers for flere e-mails og kig efter nyligt tilfoejede "Received"-headers med migreringstidsstemplet.
Hvis datoerne er forkerte paa testpostkassen, vil de vaere forkerte paa alle postkasser. Stop og loes problemet foer du fortsaetter med den fulde migrering.
Test med flere e-mailklienter
Forskellige e-mailklienter viser datoer forskellige. Gmails webgraenseflade kan vise korrekte datoer (den bruger "Date"-headeren) mens Outlook viser migreringsdatoen (den prioriterer "Received"-headeren). Test med hver klient organisationens brugere anvender, specielt Outlook Desktop, Outlook paa nettet, Apple Mail, Thunderbird og eventuelle mobile e-mailapps.
Fase 3: migreringsudfoersel
Konfiguration af migreringsvaerktoej
Konfigurer migreringsvaerktojet til at bevare INTERNALDATE saa vidt muligt. I imapsync, brug de relevante flags til at saette INTERNALDATE paa destinationen. I BitTitan MigrationWiz, tjek avancerede indstillinger for datohaandteringsmuligheder. Disse indstillinger forhindrer ikke helt "Received"-header-problemet, men de reducerer alvorligheden af datoproblemer i visse klienter. Dokumenter hver konfigurationsindstilling saa migreringen kan reproduceres om noedvendigt.
Migrer i batches
Migrer ikke alle postkasser samtidig. Migrer i batches af 10 til 20 postkasser og verificer datoer efter hver batch. Viser en batch datoproblemer, opdager du det foer hele organisationen er ramt. I oevrigt reducerer batchmigrering ogsaa belastningen paa kilde- og destinationsservere, hvilket mindsker risikoen for timeouts eller forbindelsesfejl der kan foraarsage delvise migreringer.
Overvaag fremskridt
Spoer migreringsfremskridtet for hver postkasse. Registrer starttid, sluttid, antal migrerede e-mails og eventuelle fejl. Migreringsvaerktojer leverer typisk logs - gem dem for hver postkasse. Opdages datoproblemer senere, hjaelper logs med at identificere praecis hvilken migreringsbatch og hvilke indstillinger der blev brugt.
Fase 4: post-migreringsverifikation
Verificer datoer straks
Verificer e-maildatoer inden for 24 timer efter migreringen. For hver batch aabnes 5 til 10 postkasser og datoer sammenlignes med pre-migreringsreferencerne. Er datoerne forkerte, dokumenter omfanget af problemet (hvor mange postkasser paavirket, hvor mange e-mails per postkasse) mens informationen er frisk.
Tjek alle mappetyper
Datoproblemer kan paavirke visse mapper anderledes. Tjek datoer i Indbakken, Sendte elementer, Kladder og eventuelle tilpassede mapper eller labels. Nogle migreringsvaerktojer behandler mapper sekventielt, og fejl i en mappe indikerer ikke noedvendigvis fejl i andre.
Verificer soegning og sortering
Aabn en migreret postkasse, sorter efter dato og bekraeft at den kronologiske raekkefoelge matcher originalen. Soeg efter e-mails efter datointervaller og verificer at resultaterne er praecise. Test eventuelle automatiserede regler eller filtre der afhaenger af modtagelsesdatoer. Bruger organisationen compliance- eller eDiscovery-vaerktojer, verificer at datobaserede foresprgsler returnerer korrekte resultater.
Gaengse fejl der foraarsager datoproblemer
Spring testmigreringen over
Den mest gaengse fejl er at migrere alle postkasser uden at teste foerst. Naar datoproblemer opdages, er alle postkasser ramt, og kildeserveren er maaske allerede nedlagt. En 30-minutters testmigrering kan forhindre ugers afhjaeelpning. Hvorfor springe den over?
Ignorer tilfoejelse af "Received"-headers
Administratorer fokuserer ofte paa bevarelse af INTERNALDATE og overser "Received"-header-problemet. Selv naar INTERNALDATE er korrekt sat, faar migrerings-"Received"-headeren Outlook og andre klienter til at vise den forkerte dato. Det er den hyppigste kilde til klager efter migrering. Laes hvorfor e-mails viser forkerte datoer efter migrering for en komplet teknisk forklaring.
Nedlaegge kildeserveren for tidligt
Opdages datoproblemer efter nedlaeggelse af kildeserveren, forsvinder re-migreringsmuligheden. Hold kildeserveren tilgaengelig (selv skrivebeskyttet) i mindst 30 dage efter migrering. Det giver en fallback-loesning hvis alvorlige problemer dukker op senere.
Hvad du goer hvis datoerne allerede er forkerte
Hvis migreringen allerede er udfoert og datoerne er forkerte, kan problemet loeses. Den originale "Date"-header er bevaret i hver e-mail, hvilket betyder at de korrekte datooplysninger stadig eksisterer. E-maildatoer kan rettes efter migrering, selv maaneder eller aar senere.
Redate.io's proprietaere korrektionsmotor forbinder til postkassen og soeger efter e-mails med korrupte datometadata. Den flertrins analysepipeline identificerer migreringssignaturer, anvender maalrettede korrektioner mens beskedens integritet bevares (inklusive S/MIME-signaturer, multipart-strukturer og ikke-ASCII-headers), og koerer en integritetsverifikation paa hver rettet e-mail. Analysen er gratis og viser praecis hvor mange e-mails der er ramt. Originaler bevares i en synlig backup-mappe i 30 dage.
At forsoge denne korrektion manuelt eller med et tilpasset script er fristende men risikabelt. Saertilfaelde som PGP-krypterede beskeder, korrupte MIME-graenser, indlejrede multipart-strukturer og Content-Transfer-Encoding-forskydninger kan stille og roligt korrumpere e-mails uden at du opdager det foer det er for sent. Og hvordan verificerer du at 10.000 rettede e-mails alle er intakte?
Klar til at tjekke om din postkasse har datoproblemer? Start en gratis analyse med Redate.io - ingen betaling kraeves for at se hvor mange e-mails der er ramt.