E-posta Migrasyonu Kontrol Listesi: Tarih Sorunlarını Önleyin

Neden bir migrasyon kontrol listesi gereklidir

E-posta migrasyonu, bir kuruluşun gerçekleştirebileceği en riskli BT operasyonlarından biridir. Yıllarca süren profesyonel yazışmalar platformlar arasında taşınır ve tek bir gözden kaçan ayrıntı, tüm posta kutularının meta verilerini bozabilir. En sık etkilenen şey? E-posta tarihleri. Migrasyon sonrasında her e-posta, orijinal gönderim veya alım tarihi yerine migrasyon tarihini gösterebilir.

Bu kontrol listesi, migrasyon sürecinin her aşamasını kapsar. Tarih bozulmalarını ve diğer meta veri sorunlarını en aza indirmek için bu adımları takip edin. Migrasyon zaten tamamlandıysa ve tarih sorunları ortaya çıktıysa okumaya devam edin.

Aşama 1: Migrasyon öncesi planlama

Posta kutularını envanterleyin

Herhangi bir migrasyon aracına dokunmadan önce taşınacak her posta kutusunu belgeleyin. Toplam posta kutusu sayısını, kutu başına yaklaşık e-posta sayısını, en eski e-postaların tarih aralığını ve paylaşılan posta kutuları ile dağıtım gruplarını kayıt altına alın. Bu envanter hangi migrasyon aracının kullanılacağını, migrasyonun ne kadar süreceğini ve olası migrasyon sonrası düzeltmeler için uygulanacak fiyatlandırmayı belirler.

Doğru migrasyon aracını seçin

Tüm migrasyon araçları tarihleri aynı şekilde ele almaz. Her aracın IMAP INTERNALDATE korumasını nasıl yönettiğini ve APPEND işlemi sırasında "Received" başlığı ekleyip eklemediğini araştırın. Popüler araçlar arasında BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO ve Exchange Yönetim Merkezi'nin yerel içe aktarma özelliği yer alır. Bu araçların her biri tarih sorunlarına yol açabilir; zira IMAP protokolünün kendisi, sunucunun ekleme sırasında bir "Received" başlığı eklemesini zorunlu kılar. Ama bazı araçlar INTERNALDATE'i diğerlerinden daha iyi korur. INTERNALDATE'in nasıl çalıştığını daha iyi anlamak için IMAP INTERNALDATE: tarihlerin neden bozulduğu makalesine bakabilirsiniz.

Her şeyi yedekleyin

Migrasyondan önce her posta kutusunun eksiksiz bir yedeğini alın. Bu yedek hem bir güvenlik ağı hem de sonradan tarihleri doğrulamak için bir referans noktası işlevi görür. Google Workspace için Google Takeout veya üçüncü taraf bir yedekleme aracı kullanın. Microsoft 365 için Exchange Online yedeğini veya PST dışa aktarımını kullanın. IMAP sunucuları için yerel bir kopya oluşturmak amacıyla imapsync kullanın.

Yedekleri kaynak ve hedef sunuculardan tamamen ayrı bir konumda saklayın.

Orijinal tarihleri belgeleyin

Her posta kutusundan farklı tarih aralıklarına yayılmış 10 ila 20 e-posta seçin (en eskiler, en yeniler ve birkaç orta dönem). Her e-postanın "Alındı" tarihini, "Gönderildi" tarihini ve ham başlıklarını kayıt altına alın. Bu referans e-postalar, migrasyon sonrası doğrulamanızın temeli olacak. Orijinal kronolojik sırayı görsel olarak belgelemek için tarihe göre sıralanmış posta kutusunun ekran görüntüsünü alın.

Aşama 2: Test migrasyonu

Önce bir test posta kutusu taşıyın

Önceden test yapmadan tam migrasyon başlatmayın.

Temsili bir e-posta örneği içeren (en az 100 e-posta, birkaç yılı kapsayan) bir test posta kutusu oluşturun. Migrasyonu yalnızca bu kutuda çalıştırın ve devam etmeden önce sonuçları derinlemesine inceleyin. Bu test, üretim kutularını etkilemeden önce tarih sorunlarını, kodlama hatalarını, ek yönetimi hatalarını ve klasör yapısı tutarsızlıklarını ortaya çıkarır.

Test posta kutusunda tarihleri doğrulayın

Test kutusunu taşıdıktan sonra tarihleri hemen kontrol edin. Son kullanıcıların gerçekte kullanacağı e-posta istemcisinde (Outlook, Apple Mail, Thunderbird veya webmail arayüzü) posta kutusunu açın. Görüntülenen tarihleri Aşama 1'de belgelenen referans e-postalarla karşılaştırın. Hem "Alındı" hem de "Gönderildi" tarihlerini doğrulayın. Birkaç e-postanın ham başlıklarını açın ve migrasyon zaman damgasıyla yeni eklenmiş "Received" başlıklarını arayın.

Tarihler test kutusunda yanlışsa tüm kutularda yanlış olacaktır. Her şeyi durdurun ve tam migrasyona geçmeden önce sorunu çözün.

Birden fazla e-posta istemcisiyle test yapın

Farklı e-posta istemcileri tarihleri farklı şekillerde görüntüler. Gmail'in web arayüzü doğru tarihleri gösterebilir ("Date" başlığını kullanır), oysa Outlook migrasyon tarihini gösterebilir ("Received" başlığına öncelik verir). Kuruluştaki kullanıcıların kullandığı her istemciyle test yapın: masaüstü Outlook, web üzerinde Outlook, Apple Mail, Thunderbird ve tüm mobil e-posta uygulamaları.

Aşama 3: Migrasyonun gerçekleştirilmesi

Migrasyon aracını yapılandırın

Migrasyon aracını INTERNALDATE'i mümkün olduğunca koruyacak şekilde yapılandırın. imapsync'te hedefte INTERNALDATE'i ayarlamak için uygun bayrakları kullanın. BitTitan MigrationWiz'de tarih yönetimi seçenekleri için gelişmiş ayarları kontrol edin. Bu ayarlar "Received" başlığı sorunlarını tamamen önlemez, ancak bazı istemcilerdeki tarih sorunlarının şiddetini azaltır. Gerektiğinde migrasyonu yeniden oluşturabilmek için kullanılan her yapılandırma ayarını belgeleyin.

Gruplar halinde taşıyın

Tüm posta kutularını aynı anda taşımayın. Her gruptan sonra tarihleri kontrol ederek 10 ila 20 kutuluk gruplar halinde taşıyın. Bir grupta tarih sorunları görünürse, tüm kuruluş etkilenmeden önce bunu fark edersiniz. Ayrıca gruplar halinde migrasyon, kaynak ve hedef sunuculardaki yükü de azaltır. Bu sayede kısmi migrasyonlara yol açabilecek zaman aşımı veya bağlantı hatası riski düşer.

İlerlemeyi izleyin

Her posta kutusu için migrasyon ilerlemesini takip edin. Başlangıç saatini, bitiş saatini, taşınan e-posta sayısını ve varsa hataları kayıt altına alın. Migrasyon araçları genellikle log dosyaları üretir; bunları her posta kutusu için saklayın. Tarih sorunları daha sonra keşfedilirse, bu loglar hangi migrasyon grubunun ve hangi parametrelerin kullanıldığını tam olarak belirlemeye yardımcı olur.

Aşama 4: Migrasyon sonrası doğrulama

Tarihleri hemen doğrulayın

Migrasyonun ardından 24 saat içinde e-posta tarihlerini kontrol edin. Her grup için 5 ila 10 posta kutusunu açın ve tarihleri migrasyon öncesi referanslarla karşılaştırın. Tarihler yanlışsa, bilgiler henüz tazeyken sorunun boyutunu belgeleyin (kaç kutu etkilendi, kutu başına kaç e-posta).

Tüm klasör türlerini kontrol edin

Tarih sorunları bazı klasörleri farklı şekilde etkileyebilir. Gelen Kutusu, Gönderilenler, Taslaklar ve tüm özel klasörler ile etiketlerdeki tarihleri kontrol edin. Bazı migrasyon araçları klasörleri sıralı olarak işler ve bir klasördeki hatalar diğer klasörlerdeki hataları zorunlu olarak göstermez.

Arama ve sıralamayı doğrulayın

Taşınmış bir posta kutusunu açın, tarihe göre sıralayın ve kronolojik sıranın orijinalle eşleştiğini doğrulayın. Tarih aralığına göre e-posta arayın ve sonuçların doğru olduğunu kontrol edin. Alım tarihlerine dayanan otomatik kuralları veya filtreleri test edin. Kuruluş uyumluluk veya eKeşif araçları kullanıyorsa, tarihe dayalı sorguların doğru sonuçlar döndürdüğünü doğrulayın.

Tarih sorunlarına neden olan yaygın hatalar

Test migrasyonunu atlamak

En yaygın hata, önceden test yapmadan tüm posta kutularını taşımaktır. Tarih sorunları keşfedildiğinde tüm kutular etkilenmiş olur ve kaynak sunucu belki çoktan devre dışı bırakılmıştır. 30 dakikalık bir test migrasyonu, haftalarca sürecek bir düzeltme sürecini önleyebilir. Buna neden gerek duyulmayacak ki?

"Received" başlığı eklemelerini görmezden gelmek

Yöneticiler çoğunlukla INTERNALDATE korumasına odaklanır ve "Received" başlığı sorununu gözden kaçırır. INTERNALDATE doğru şekilde ayarlanmış olsa bile, migrasyon "Received" başlığı Outlook'un ve diğer istemcilerin yanlış tarihi göstermesine neden olur. Bu, migrasyon sonrası şikayetlerin en sık görülen kaynağıdır. Teknik açıklama için migrasyondan sonra e-postaların neden yanlış tarih gösterdiğini okuyabilirsiniz.

Kaynak sunucuyu çok erken devre dışı bırakmak

Kaynak sunucu kapatıldıktan sonra tarih sorunları keşfedilirse, yeniden migrasyon seçeneği ortadan kalkar. Kaynak sunucuyu migrasyondan sonra en az 30 gün boyunca erişilebilir (en azından salt okunur olarak) tutun. Bu, daha sonra ciddi sorunlar ortaya çıkarsa bir geri dönüş yolu sağlar.

Tarihler zaten bozulduysa ne yapmalı

Migrasyon zaten gerçekleştirildi ve tarihler yanlışsa, sorun düzeltilebilir. Orijinal "Date" başlığı her e-postada korunur; bu, doğru tarih bilgisinin hala var olduğu anlamına gelir. E-posta tarihleri migrasyondan aylar hatta yıllar sonra bile düzeltilebilir.

Redate.io'nun özel düzeltme motoru posta kutusuna bağlanır ve bozulmuş tarih meta verilerine sahip e-postaları tarar. Çok aşamalı analiz pipeline'ı migrasyon imzalarını tespit eder, S/MIME imzaları, multipart yapılar ve ASCII olmayan başlıklar dahil mesaj bütünlüğünü korurken hedefli düzeltmeler uygular ve düzeltilen her e-posta üzerinde bütünlük doğrulaması çalıştırır. Analiz ücretsizdir ve tam olarak kaç e-postanın etkilendiğini gösterir. Orijinaller, 30 gün boyunca görünür bir yedekleme klasöründe saklanır.

Bu tür bir düzeltmeyi manuel olarak veya özel bir betikle yapmaya çalışmak cazip gelebilir ama risklidir. PGP şifreli mesajlar, bozulmuş MIME sınırları, iç içe geçmiş multipart yapılar ve Content-Transfer-Encoding uyumsuzlukları gibi özel durumlar, fark edilmeden önce çok geç olana kadar e-postaları sessizce bozabilir. Üstelik 10.000 düzeltilmiş e-postanın tamamının sağlam olduğunu nasıl doğrularsınız?

Posta kutunuzda tarih sorunları olup olmadığını kontrol etmeye hazır mısınız? Redate.io ile ücretsiz analiz başlatın - kaç e-postanın etkilendiğini görmek için herhangi bir ödeme gerekmez.