Eğer "hızlı" bir bulut e-posta taşımasına güveniyorsanız, bu tuzaklar planlanmış bir kesintiyi maliyetli ve itibarı zedeleyen bir fiyaskoya dönüştürebilir.

Göç neden tek bir kopyalama işleminden daha fazlasıdır

Verileri Google'dan Microsoft'a taşımak tek bir, monolitik bir işlem değildir. Her servis—mail, takvim, kişiler, Drive, Vault, Chat, Groups—bilgileri kendi formatında saklar; bu da ayrı bir çıkarma mantığı ve hedef eşlemesi gerektirir. Gmail mesajlarını kopyalamada çok iyi olan bir araç, Drive izinlerini atlayabilir, Vault arşivlerini düşürebilir veya Chat geçmişini görmezden gelebilir. Askıya alınmış hesaplar gibi uç durumlar da dahil olmak üzere, taşımayı planladığınız her iş yükünün tam bir envanteriyle işe başlayın.

Kimlik doğrulama tuzağı

Düz kullanıcı adları ve şifreler bir güvenlik riskidir ve modern API'lerde neredeyse her zaman başarısız olur. Google'da, alan genelinde yetkilendirmeye (domain-wide delegation) sahip bir servis hesabına ve dar kapsamlı bir OAuth izin setine ihtiyacınız vardır. Çok az kapsam verinin geride kalmasına neden olur; çok fazla kapsam ise suistimal için bir açık yaratır. Microsoft'ta temel kimlik doğrulama (basic authentication) kullanımdan kaldırılmıştır; yalnızca OAuth 2.0 çalışır. Hala temel kimlik doğrulamayı (basic auth) reklam eden tüm taşıma araçlarını eleyin.

Etiketler ve klasörler karşılaştırması

Gmail'in etiket sistemi tek bir mesajın birden fazla etiket altında bulunmasına izin verirken, Outlook her mesajı tek bir klasöre zorlar. Çok etiketli bir e-posta kopyalandığında, taşıma motoru şunları yapabilir:

  • Mesajı her hedef klasöre kopyalayabilir (depolama alanını şişirir ve yinelenen dizinler/thread'ler oluşturur).
  • Mesajı tek bir klasöre yerleştirip ek etiketleri atabilir (organizasyon kaybı).
  • Etiket ağacını taklit eden derin bir klasör yolu oluşturabilir (genellikle son kullanıcılar için kafa karıştırıcıdır).

Güvenilir bir araç seçimi size bırakır; yetersiz bir araç ise iş akışınıza uymayabilecek varsayılan bir ayarı dayatır.

Gerçek darboğaz: Hız sınırlaması (Throttling)

Sadece ham bant genişliğine odaklanan hız testleri, Microsoft Graph API'nin saniye başına istek sınırları uyguladığı gerçeğini gözden kaçırır. Çok fazla çağrıyı çok hızlı yaparsanız Microsoft sizi engelleyecektir. Daha hızlı bir internet bağlantısının sorunu çözeceğini varsaymak yerine; gerektiğinde duraklatan, geri çekilen ve devam eden otomatik hız sınırlaması yönetimi (throttle management) uygulayan araçlar arayın.

Cuma gecesi toplu veri aktarımı değil, artımlı (delta) geçiş

Tüm kiracıyı (tenant) tek bir hafta sonu penceresinde taşımak, kesinti yaşanmasını garantiler. Kademeli bir yaklaşım daha iyi sonuç verir:

  1. Toplu yükleme – E-postaların, dosyaların ve diğer verilerin büyük kısmını nihai geçişten günler veya haftalar önce aktarın.
  2. Delta senkronizasyonu – Geçiş penceresi sırasında, yalnızca yeni veya değiştirilmiş öğeleri yakalayan artımlı bir taşıma işlemi gerçekleştirin.
  3. MX kaydı değişikliği – Delta senkronizasyonu bekleyen öğe kalmadığını onayladığında, e-posta değişim (mail exchange) kaydını Microsoft 365'e yönlendirin.

Bu yöntem, kesinti süresini saatlerden dakikalara indirir.

Başarılı bir taşıma için kontrol listesi

  • Her iş yükünü listeleyin (Mail, Drive, Vault, Chat, Groups vb.).
  • Askıya alınmış hesaplar gibi karmaşık nesneleri dahil edin.
  • Herhangi bir taşıma aracının sadece pazarlama sayfasını değil, teknik dokümantasyonundaki destek özelliklerini doğrulayın.
  • OAuth kapsamlarını, her bir kaynak servis için gereken minimum düzeyde sınırlandırın.
  • Hedefte yinelenen öğelerin görünmemesini sağlamak için, tekilleştirme (deduplication) ile birlikte gerçek delta senkronizasyonunu test edin.
  • Çok etiketli Gmail mesajlarını ve karmaşık Drive izin hiyerarşilerini test eden bir pilot uygulama gerçekleştirin.

Drive bambaşka bir meseledir. Kendi bütçesi ve zaman çizelgesi vardır.