BitTitan MigrationWiz: Yanlış E-posta Tarihlerini Düzeltme

BitTitan MigrationWiz E-posta Tarihlerine Ne Yapıyor?

Taşıma işlemi geçen cuma tamamlandı. 47 posta kutusu şirket içi Exchange'den Microsoft 365'e taşındı, MigrationWiz panelinde her şey yeşil. Sonra pazartesi sabahı geldi ve ilk destek talebi düştü: "Tüm e-postalarım 28 Mart 2026 tarihini gösteriyor."

Her bir mesaj. Yılların yazışmaları, 2019'dan müşteri teklifleri, 2021'den faturalar, hepsi taşıma tarihiyle damgalanmış. MigrationWiz günlüğü her şeyin başarıyla aktarıldığını söylüyor (teknik olarak doğru da). Ama tarihler kaybolmuş.

BitTitan MigrationWiz, buluttan buluta e-posta taşıma için en yaygın kullanılan araçlardan biri. Exchange'den Microsoft 365'e, Google Workspace'den Exchange'e, kiracılar arası taşımalar, hepsini yapıyor. Aracın kendisi işlevsel olarak gayet iyi çalışıyor. Tarih sorunu MigrationWiz'deki bir hata değil. Her şey, her kopyanın yeni posta kutusuna yazılırken taşıdığı tek bir şeye, tarihe bağlı.

Bu sorun sessiz bir sorun. Taşıma sırasında herhangi bir uyarı veya hata mesajı almıyorsunuz. Tüm veriler yerinde, tüm klasörler doğru, tüm ekler bozulmamış. Sadece tarihler yanlış. Ve bunu keşfettiğinizde, genellikle son kullanıcılar çoktan şikayet etmeye başlamış oluyor.

Yanlış Tarih Gerçekte Nerede Duruyor?

MigrationWiz bir e-postayı kaynaktan hedefe aktarırken IMAP protokolünü (veya uç nokta türüne bağlı olarak Exchange Web Services'ı) kullanır. Hedef, kendisine verilen tarihi korur: kopya orijinal tarihi taşıdığında Microsoft 365, Outlook.com ve Gmail bu tarihi saklar. Yani her e-posta taşıma tarihini gösteriyorsa, sorgulanması gereken MigrationWiz'in geçirdiği (veya geçirmediği) tarihtir.

MigrationWiz taşımasından sonra bu e-postalardan birinin başlıkları hala şunu taşır:

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

2019'dan orijinal Date: başlığı hala orada, orijinal Received: zinciri de öyle. Microsoft 365'te Outlook'un alındı tarihi olarak gösterdiği ise posta kutusunun her e-postanın ne zaman geldiğine dair kendi kaydıdır: MigrationWiz orijinal tarihi geçirmediyse bu kayıt 28 Mart 2026 diyor.

INTERNALDATE değeri (IMAP sunucularının sıralama için kullandığı zaman damgası) kopyanın aldığı tarihtir. MigrationWiz tarihleri korumaya çalışır ve Microsoft 365 kendisine verilen tarihi saklar: tarihler yanlış çıkıyorsa, her e-posta için geçirilen tarih orijinal tarih değildi.

MigrationWiz Tarih Eşleme Özelliği Neden Yetersiz Kalıyor?

BitTitan, MigrationWiz Gelişmiş Seçenekler'de bir "Tarih Eşleme" özelliği sunuyor. Kağıt üzerinde çözüm gibi görünüyor. Pratikte? Bu ayar mesajların hedefte nasıl korunacağını değil, taşımadan önce hangi tarih aralığındaki mesajların taşınacağını kontrol ediyor.

Karışıklık anlaşılabilir. Ayarın adında "tarih" geçiyor. Ama aslında yaptığı, kaynak mesajları taşımadan önce tarih aralığına göre filtrelemek. 2018'den bir mesaj yine taşıma zaman damgasıyla hedefe ulaşıyor.

Bir de IMAP ile Exchange uç noktaları meselesi var. MigrationWiz iki Exchange sunucusu arasında EWS (Exchange Web Services) kullanarak taşıma yaptığında, tarih koruması daha iyi çalışır çünkü EWS mesaj meta verileri üzerinde daha fazla kontrole sahiptir. IMAP üzerinden de hedef, kendisine verilen tarihi korur: önemli olan orijinal tarihin geçirilip geçirilmediğidir.

Bazı yöneticiler farklı uç nokta yapılandırmalarıyla taşımayı yeniden çalıştırmayı denemiş, IMAP'ten EWS'ye geçmenin tarihleri geriye dönük düzelteceğini umarak. Düzeltmiyor. Mesajlar zaten yanlış tarihlerle hedefte. MigrationWiz'i tekrar çalıştırmak sadece kopyalar oluşturur.

Tarihleri Bozan Spesifik MigrationWiz Senaryoları

Her MigrationWiz taşıması tarih sorununa neden olmaz. Sorun uç nokta kombinasyonuna bağlıdır:

• Exchange (şirket içi) - Microsoft 365 arası IMAP ile: Tarihler bozulur. Her e-posta, kopyanın tarihini alır.
• Google Workspace - Microsoft 365: Tarihler bozulur. MigrationWiz Google'dan okumak için IMAP kullanır ve orijinal tarih olmadan M365'e yazar.
• Exchange - Exchange (EWS - EWS): Tarihler genellikle korunur. EWS'de orijinal tarih mesajla birlikte taşınır.
• Herhangi bir kaynak - Google Workspace arası IMAP ile: Tarihler bozulur. IMAP üzerinden Gmail, aracın geçirdiği tarihi korur ve hiçbir şey eklemez. Tarihler yalnızca geçirilen tarih orijinal değilse ya da kopya, kopyalama gününün tarihiyle damgalanan bir Received: satırı ekleyen Gmail içe aktarma API'sinden geçerse bozulur.
• Kiracılar arası Microsoft 365: Her şey, yöntemin geçirdiği tarihe bağlıdır.

MigrationWiz paneli tarih sorunlarını işaretlemiyor. Her şey "Tamamlandı" olarak görünüyor çünkü mesajlar gerçekten başarıyla aktarıldı. İçerik bozulmamış, ekler yerinde, klasör yapısı korunmuş. Sadece tarihler değişmiş ve MigrationWiz bunu bir taşıma hatası olarak izlemiyor.

MigrationWiz Sonrası Yanlış Tarihlerin Gerçek Maliyeti

Yanlış e-posta tarihleri sadece can sıkıcı değil. BitTitan ile taşıma yapan kuruluşlar için sonuçlar dağınık bir gelen kutusunun ötesine geçiyor.

Hukuk ekipleri, her mesaj gerçek gönderim tarihi yerine taşıma tarihini gösterdiğinde e-postaları kanıt olarak kullanamıyor. Vergi denetimleri yazışmaların kronolojik kanıtını gerektiriyor. KVKK ve GDPR gibi uyumluluk çerçeveleri doğru kayıt tutmayı zorunlu kılıyor ve sahte zaman damgalı e-postalar bu gereksinimi karşılayamıyor.

Bir de pratik tarafı var. Kasım 2022'den bir sözleşme tartışmasını bulmayı deneyin, tüm posta kutunuz Mart 2026 gösterirken. Tarihe göre sırala? İşe yaramaz. Tarih aralığına göre ara? Ya her şeyi döndürür ya da hiçbir şeyi.

Müşteri ortamlarında MigrationWiz kullanan yönetilen hizmet sağlayıcıları (MSP'ler) için bu bir sorumluluk meselesi oluşturuyor. Müşteri taşıma için ödeme yaptı. Taşıma yapıldı, ama e-posta arşivleri tarih tabanlı iş akışları için fiilen kullanılamaz hale geldi. Açıkçası, müşteriye teknik olarak her şey doğru aktarıldı demek bu durumda pek tatmin edici bir cevap olmuyor.

Bir MSP'den duyduğumuz bir örnekte, bir hukuk firması için yaklaşık 380 posta kutusu taşınmıştı. Üç ay sonra firmanın dava ekibi belge keşfi sırasında tarih sorununu fark etti. Kanıt olarak sunmaları gereken her e-posta taşıma tarihini gösteriyordu. MSP, 6 yıllık zaman damgalı yazışmaların neden hepsinin Haziran 2025 tarihini gösterdiğini açıklamak zorunda kaldı.

BitTitan MigrationWiz Tarihlerini Düzeltme

Orijinal Date: başlığı her e-postanın içinde hala duruyor. MigrationWiz mesaj gövdesine veya orijinal başlıklara dokunmuyor. Görüntüleme sorununa neden olan, posta kutusunun her kopya için kaydettiği tarihtir.

Redate.io posta kutusuna bağlanır (Google Workspace, Microsoft 365 veya IMAP), MigrationWiz taşımasından etkilenen e-postaları tarar ve tescilli çok aşamalı bir analiz hattı aracılığıyla tarih meta verilerini düzeltir. Düzeltme özellikle meta veri katmanını hedefler, ve bunun için taşımayı hangi aracın yaptığını bilmesi gerekmez: gösterilen tarihi orijinal tarihiyle eşleşmeyen e-postaları bulur.

Düzeltilen her e-posta orijinaliyle tek tek doğrulanır. Doğrulama; mesaj bütünlüğünü, ek korumasını, klasör yerleşimini ve ileti dizisi yapısını kontrol eder. Orijinal e-postalar, geri alma gerektiğinde görünür bir Redate.io - Originals klasöründe saklanır, siz silene kadar.

Sorunu anlamak bir şey. 15.000 e-postayı tek bir ek kaybetmeden, S/MIME imzalarını bozmadan veya çok parçalı MIME sınırlarını bozmadan düzeltmek başka bir şey. Laboratuvarda 10 test mesajında çalışan bir betik, 7 yıllık yazışması, PGP şifreli mesajları ve RFC 2047 ASCII dışı başlıkları olan bir üretim posta kutusunun uç durumlarını kaldıramaz.

Düzeltilen her mesajın bozulmadığını nasıl doğrularsınız? İleti dizisinin hala çalıştığını, takvim davetlerinin hala çözümlendiğini, 2020'den o 47 MB'lık ekin bozulmadığını? Redate.io bunu otomatik olarak, her bir mesaj için yapar. Ve bir şey uyumsuz görünürse orijinal yedek klasörde tam orada duruyor.

Ücretsiz tarama yaklaşık iki dakika sürer. Posta kutusuna bağlanır, MigrationWiz taşıma tarihiyle damgalanmış her e-postayı tespit eder ve ödeme yapmadan önce tam sayıyı ve maliyeti gösterir. Kredi kartı gerekmez, taahhüt yok.

Tarama sonuçları tam olarak neyle karşı karşıya olduğunuzu gösterir: etkilenen e-posta sayısı, etkilenen klasörler ve tarih aralığı bilgisi. Bu bilgiyle yöneticinize veya müşterinize durumu net bir şekilde rapor edebilirsiniz. Aslında çoğu MSP, tarama sonuçlarını doğrudan müşteriye göstererek sorunu belgeler.

BitTitan İçin Platforma Özel Düzeltme Kılavuzları

Düzeltme süreci MigrationWiz'in e-postalarınızı nereye taşıdığına bağlı olarak değişir. Redate.io her platformun özelliklerini otomatik olarak ele alır, ama kendi kurulumunuz hakkında ayrıntı istiyorsanız:

• Outlook'ta BitTitan tarihlerini düzeltme
• Microsoft 365'te BitTitan tarihlerini düzeltme
• Google Workspace'te BitTitan tarihlerini düzeltme
• Exchange Online'da BitTitan tarihlerini düzeltme

Redate.io aylar veya yıllar önce tamamlanan taşımalar için de çalışır. Orijinal Date başlığının süresi dolmaz. Taşımanın üzerinden iki yıl geçmiş olsa bile, düzeltme aynı doğrulukla yapılabilir.

BitTitan MigrationWiz ile taşıma yaptınız ve yanlış tarihlerle mi kaldınız? Herhangi bir taahhütte bulunmadan önce kaç e-postanın etkilendiğini görmek için ücretsiz tarama başlatın.