İki şirketin Microsoft 365 ortamını birleştirmek, yalnızca e-postaları kopyalamak değildir. Kullanıcı kimlikleri, alan adları, OneDrive dosyaları, SharePoint izinleri ve uygulama bağlantıları birlikte planlanmalıdır. Tenant-to-tenant geçişte doğru teklif, “her şey taşınır” sözü yerine hangi verinin hangi yöntemle taşınacağını ve nasıl doğrulanacağını açıklar.
Hangi durumda tenant-to-tenant geçiş gerekir?
Bir şirket satın aldığınızda iki ayrı Microsoft 365 ortamını tek yönetim altında toplamak isteyebilirsiniz. Şirket bölünmesinde ise bazı çalışanları ve verilerini mevcut ortamdan ayırmanız gerekebilir. İki taraf zaten Microsoft 365 kullansa bile bu işlem, aynı sistem içinde klasör sürüklemek kadar basit değildir.
İlk karar teknik değil, operasyoneldir: Tek ortamda birleşmek gerçekten gerekli mi? Hedef yalnızca toplantı yapmak veya ortak dosya paylaşmaksa, kalıcı veri taşıma projesinden önce işbirliği seçeneklerini değerlendirin. Birleşme kararı kesinse hedef tenant'ın hangisi olacağını, veri sahibini ve onay verecek yöneticileri belirleyin.
Taşıma kapsamını beş ayrı satırda isteyin
| İş yükü | Teklifte cevaplanması gereken soru |
|---|
| Exchange Online | Posta, takvim, kişiler, arşiv ve ortak posta kutuları nasıl ele alınacak? |
| OneDrive | Kişisel iş dosyaları, paylaşım izinleri ve eski bağlantılar nasıl doğrulanacak? |
| SharePoint ve Teams | Dosyalar, siteler, kanallar ve sohbetler için kapsam ve istisnalar neler? |
| Kimlik ve cihazlar | Yeni hesap, oturum açma, cihaz yönetimi ve kullanıcı profili etkisi ne? |
| Uygulamalar | ERP, CRM, otomasyon, rapor ve tek oturum açma bağlantıları kim tarafından güncellenecek? |
Bu tablo bir “tamamı otomatik taşınır” listesi değildir. Tam tersine, her kalemin ayrıca teyit edilmesini sağlar. E-postanın başarılı taşınması, Teams geçmişinin veya bir Power Automate akışının çalıştığını göstermez.
Posta kutusu geçişinde lisans ve geri dönüş ayrıntısı
Microsoft'un yerleşik tenant'lar arası posta kutusu taşıma yöntemi, uygun Exchange Online lisanslarının yanında kullanıcı başına Cross-Tenant User Data Migration eklentisi gerektirir. Hedef kullanıcı nesnesinin de yönteme uygun hazırlanması gerekir. Lisansın kapsamını ve satın alınabilirliğini proje başlamadan doğrulayın. Microsoft: tenant'lar arası posta kutusu taşıma.
Önemli bir ayrıntı: Bu yerleşik yöntemle başarılı geçiş sonrasında kaynak posta kutusu eski tenant'ta erişilebilir bir yedek olarak kalmaz. Bu yüzden “olmazsa eskisini açarız” yaklaşımı yeterli bir geri dönüş planı değildir. Saklama ihtiyaçlarını, ayrı yedekleme kararını ve sorun halinde izlenecek yolu geçiş öncesinde yazılılaştırın. Aynı resmi belgede bu davranış açıkça belirtilir.
Alan adı geçişini son dakikaya bırakmayın
Çalışanların aynı e-posta adresini koruması çoğu projede temel beklentidir. Bunun için alan adının mevcut ortamda bağlı olduğu kullanıcılar, takma adlar, gruplar ve ortak posta kutuları çıkarılmalıdır. Microsoft'un alan adı kaldırma süreci bu bağımlılıkların giderilmesini ister; işlemin süresi nesne sayısına göre değişebilir. Microsoft: alan adı kaldırma ön koşulları.
DNS erişimi kimde? Geçiş saatinde onay verecek kişi ulaşılabilir mi? Bir uygulama eski gönderen adresine bağlı mı? Bu soruların cevabı bilinmeden takvimde bir akşam seçmek, plan yapmak sayılmaz. Alan adı adımlarını ve e-posta akış testlerini ayrı bir geçiş çizelgesine koyun.
OneDrive için “önce boş hesabı açalım” her zaman doğru değil
Yerleşik OneDrive taşıma yönteminde hedef kullanıcının OneDrive sitesinin önceden oluşturulmaması gerekir; mevcut hedef sitenin üzerine yazılmaz. Kullanıcı eşleştirmesi ve paylaşım izinleri de hazırlığın parçasıdır. Geçiş sırasında salt okunur bir dönem olabilir. Microsoft: OneDrive geçiş koşulları.
Bu nedenle personele “yeni hesabınızı açtık, hemen her uygulamaya girin” mesajını hazırlık tamamlanmadan göndermeyin. Teknik ekibin sıralaması ile çalışanlara gönderilecek duyuru aynı plana dayanmalı.
Örnek kabul testi: satış ekibi pazartesi çalışabilecek mi?
Varsayımsal bir birleşmede satış ekibinden bir kullanıcıyı pilot seçtiğinizi düşünün. Sadece gelen kutusunu açtırmak yerine bir müşteriye test mesajı gönderin; eski takvim kaydını ve paylaşılan fiyat dosyasını kontrol ettirin. ERP'den teklif gönderimini, mobil oturumu ve ekip klasöründeki düzenleme yetkisini de deneyin. Her sonuç için “çalıştı / sorun var / kapsam dışı” kaydı tutun.
Bu yaklaşımın yararı, yüzlerce teknik adımı yönetim açısından anlaşılır bir soruya bağlamasıdır: Çalışan temel işini yapabiliyor mu? Pilot sorunları kapanmadan geniş geçişe başlamamak için kabul ölçütlerini önceden belirleyin.
Sık sorulan sorular
İki Microsoft 365 hesabı otomatik birleşir mi?
Hayır. Hedef kullanıcı eşleştirmesi ve iş yükü bazlı taşıma planı gerekir. İki hesabın aynı kişiye ait olması otomatik veri birleşmesi anlamına gelmez.
Bütün Teams içerikleri posta kutusuyla taşınır mı?
Böyle varsayılmamalı. Teams verilerinin türleri ve desteklenen taşıma yöntemi ayrıca kapsamlandırılmalıdır.
Projenin süresini yalnızca kullanıcı sayısı belirler mi?
Hayır. Veri hacmi, izin karmaşıklığı, uygulamalar, alan adı bağımlılıkları ve kabul edilen çalışma kesintisi de planı etkiler.
Birleşme projesini doğru kapsamla başlatın
Micro Bilgi ile görüşmeden önce iki ortamın kullanıcı sayısını, taşınacak iş yüklerini ve hedef tarihinizi hazırlayın. Exchange Online hizmetlerini inceleyebilir, tenant birleştirme ihtiyacınız için değerlendirme talebi bırakabilirsiniz. Şifre veya gerçek müşteri verisi paylaşmadan başlayabilirsiniz.
Hazırlanma ve kaynak kontrol tarihi: 25 Eylül 2026. Ürün hakları ve özellikler değişebileceğinden uygulama öncesinde güncel belgeler kontrol edilmelidir.