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. IMAP taşıma protokolünün çalışma biçiminin bir sonucu ve MigrationWiz bunu belirli bir şekilde tetikliyor.

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.

MigrationWiz Received Başlıklarını Nasıl İşliyor?

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. Bu süreçte hedef posta sunucusu, mesaja güncel zaman damgasını içeren yeni bir Received: başlığı ekler, tıpkı gelen herhangi bir e-postaya yapacağı gibi.

MigrationWiz taşımasından sonra tipik bir Received başlık zinciri şöyle görünür:

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

2019'dan orijinal Received: başlığı hala orada. Orijinal Date: başlığı da öyle. Ama Outlook gibi e-posta istemcileri bunları kullanmıyor. Outlook mesajı ne zaman göstereceğini belirlemek için en son Received: başlığını okur ve o başlık artık 28 Mart 2026 diyor.

INTERNALDATE değeri (IMAP sunucularının sıralama için kullandığı zaman damgası) da aktarım sırasında üzerine yazılır. MigrationWiz hedef desteklediğinde tarihleri korumaya çalışır, ama sonuç büyük ölçüde hedef sunucunun davranışına bağlıdır. Örneğin Microsoft 365'in taşıma hattı, MigrationWiz ne isterse istesin INTERNALDATE'i kendi teslim zaman damgasıyla değiştirir.

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. Ama taşımanın herhangi bir tarafında IMAP devreye girdiğinde (kaynak veya hedef), IMAP APPEND işlemi devralır ve hedef sunucu hangi zaman damgasını kullanacağına karar verir.

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. M365 taşıma hattı yeni Received başlıkları ekler ve INTERNALDATE'in üzerine yazar.
• Google Workspace - Microsoft 365: Tarihler bozulur. MigrationWiz Google'dan okumak için IMAP kullanır ve M365'e yazar, M365 de kendi taşıma başlıklarını ekler.
• Exchange - Exchange (EWS - EWS): Tarihler genellikle korunur. EWS her iki tarafta da taşıma hattını atlar.
• Herhangi bir kaynak - Google Workspace arası IMAP ile: Tarihler bozulur. Google'ın IMAP uygulaması ekleme zaman damgasıyla bir Received başlığı ekler.
• Kiracılar arası Microsoft 365: Yönteme bağlıdır. IMAP yolu tarihleri bozar. Doğrudan EWS koruyabilir.

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, eklenen Received: başlığı ve üzerine yazılan INTERNALDATE değeri.

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, bilinen MigrationWiz başlık imzalarını (Received zincirindeki karakteristik mx.migrationwiz.com ve bittitan.com tanımlayıcıları dahil) örüntü eşleştirmesiyle tespit eder.

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 30 gün boyunca saklanır.

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.