Microsoft 365 Tenant-to-Tenant Geçiş Planı: Birleşme ve Ayrılmalar

İki Microsoft 365 tenant’ı arasındaki taşımada projeyi kilitleyen şey veri hacmi değil, alan adıdır: ornek.com.tr kaynak tenant’ta tek bir paylaşılan posta kutusunda bile ikincil adres olarak duruyorsa, hedefte doğrulanamaz. Birleşme, devralma veya bir iş biriminin ayrılması bu işi gündeme getirir. Şirket içinden buluta göçten farkı, iki tarafın da canlı bulut hizmeti olması ve alan adının aynı anda iki yerde kullanılamamasıdır. Aşağıda iş yüklerinin taşıma sırasını, alan adı kaynaklı kesim penceresini, Microsoft’un yerel araçlarıyla üçüncü taraf araçların kapsamını ve kesim sonrası temizliği sırasıyla veriyoruz.

Geçişi tetikleyen senaryolar

Senaryo, taşımanın yönünü ve hızını belirler:

• Devralma: Devralınan şirketin kullanıcıları ana şirket tenant’ına taşınır. Alan adı da genellikle taşınır; marka bir süre korunabilir.
• Eşit birleşme: İki tenant tek bir yeni ya da mevcut tenant’ta toplanır. İsimlendirme ve politika kararları teknik işten önce verilmelidir.
• Ayrılma (divestiture): Satılan iş biriminin kullanıcıları ve verisi yeni bir tenant’a çıkarılır. Hangi verinin ayrılan tarafa geçeceği hukuki bir karardır; BT yalnızca uygular.
• Tenant konsolidasyonu: Yıllar içinde açılmış bölgesel veya deneme tenant’larının tek tenant’ta toplanması.

Her senaryoda ilk soru şudur: Geçiş döneminde iki organizasyon birbirinin takvimini görecek, Teams’ten birbirine ulaşacak ve ortak dosyalarda çalışacak mı? Cevap evetse, taşımadan önce iki sistem altyapısı arasında bir birlikte çalışma (coexistence) katmanı kurulur. Bu katman atlanırsa ilk hafta “karşı tarafı göremiyorum” talepleriyle geçer.

İş yükleri ve bağımlılık haritası

Tenant’taki iş yükleri birbirine bağlıdır. Bir Teams ekibi bir Microsoft 365 grubuna, gruba bağlı bir SharePoint sitesine ve çoğu zaman paylaşılan bir posta kutusuna dayanır. Bağımlılık haritası olmadan yapılan taşımada kullanıcı kırık bağlantıyla karşılaşır.

Envanter için iki tenant’ta da posta kutularını, grupları, siteleri, ekipleri ve uygulama kayıtlarını dışa aktarın. Kaynak tenant’ta saklama ilkesi (retention) ve dava bekletmesi (litigation hold) altındaki posta kutularını ayrıca işaretleyin; taşıma ve silme adımlarında bunlar farklı ele alınır.

Sahada en geç fark edilen bağımlılıklar her zaman aynıdır: Power Automate akışları, Power BI çalışma alanları, Forms formları, Planner planları ve üçüncü taraf uygulama entegrasyonları. Bunları sahipleriyle birlikte listeleyip “yeniden kurulacak” veya “taşınacak” diye sınıflandırın. Sahibi bilinmeyen akış kesimde ölür.

Alan adı kısıtı ve kesim penceresi

Bir alan adı aynı anda yalnız tek bir tenant’ta doğrulanabilir. Projenin takvimini bu tek kural belirler. ornek.com.tr alan adını hedefe almak için kaynak tenant’ta o alan adını UPN, birincil veya ikincil SMTP adresi olarak kullanan tüm kullanıcılar, gruplar, kişiler, paylaşılan posta kutuları ve kaynaklar başka bir alan adına (genellikle *.onmicrosoft.com) çevrilmelidir. Ardından alan adı kaynaktan silinir ve hedefte doğrulanır.

Alan adını kullanan nesneleri Microsoft Graph PowerShell ile listeleyebilirsiniz:

Connect-MgGraph -Scopes "Domain.Read.All","Directory.Read.All"
Get-MgDomainNameReference -DomainId "ornek.com.tr" -All |
  Select-Object Id, @{n="Tur";e={$_.AdditionalProperties["@odata.type"]}},
                @{n="Ad";e={$_.AdditionalProperties["displayName"]}}

Exchange Online tarafında proxy adresleri ayrıca kontrol edilmelidir:

Connect-ExchangeOnline
Get-Recipient -ResultSize Unlimited |
  Where-Object { $_.EmailAddresses -match "@ornek\.com\.tr$" } |
  Select-Object Name, RecipientTypeDetails, PrimarySmtpAddress

Alan adı silme işlemi bir nesne yüzünden reddedildiğinde, suçlu çoğunlukla unutulmuş bir dağıtım grubu, eski bir kişi (contact) nesnesi ya da ikincil adres olarak kalmış bir proxy kaydıdır. Kesim penceresi, alan adının kaynaktan kaldırılmasıyla hedefte kullanılabilir hale gelmesi arasındaki süredir; bu sürede dış posta akışı ve kullanıcıların oturum açma adı etkilenir. Pratik önlemler:

• MX, Autodiscover ve SPF kayıtlarının TTL değerlerini kesimden birkaç gün önce düşürün.
• Kesimi hafta sonu gibi posta trafiğinin düşük olduğu bir zamana koyun. Gönderen sunucular erişemedikleri MX için postayı kuyrukta tutup yeniden dener; ama yeniden deneme süresi gönderene bağlıdır. Pencereyi kısa tutun.
• Toplu adres değiştirme betiklerini önce test tenant’ında veya küçük bir pilot grupta deneyin; binlerce nesnede bu işlem zaman alır.
• Kesim sırasını yazılı bir runbook’a dökün: kaynakta adresleri değiştir, alan adını sil, hedefte doğrula, hedefte adresleri ata, MX ve Autodiscover’ı güncelle, test postası gönder.

Yerel cross-tenant özellikler ve üçüncü taraf araçlar

Microsoft, tenant’lar arası taşıma için bazı yerel özellikler sunar. Kapsamları üçüncü taraf göç araçlarından dardır, ama ek ürün kurulumu istemez.

Yerel cross-tenant posta kutusu taşıma şunları ister: hedef tenant’ta bir uygulama kaydı (app registration), iki tenant arasında organization relationship tanımı, hedefte göç uç noktası (migration endpoint) ve taşınan her kullanıcı için hedefte önceden hazırlanmış bir mail user nesnesi. Hedef mail user’ın ExchangeGuid değeri kaynaktaki posta kutusuyla aynı olmalıdır. GUID tutmazsa taşıma başlamaz. Her kullanıcı için ayrıca bir cross-tenant taşıma lisansı gerekir. Taşıma tamamlanınca kaynaktaki posta kutusu mail user’a dönüşür ve postayı hedefe yönlendirir; posta akışı kesim penceresine kadar böyle korunur.

Üçüncü taraf araç seçerken şu sorulara net yanıt alın: Teams sohbetlerini ve kanal mesajlarını taşıyor mu, taşıyorsa hangi biçimde? İzinleri ve paylaşım bağlantılarını yeniden yazabiliyor mu? Artımlı geçiş destekliyor mu? Taşıma raporları denetim için yeterli mi? Demo ortamında değil, kendi pilot verinizle deneyin.

Kimlik eşleme ve kullanıcı iletişimi

Tüm araçların temel girdisi bir kimlik eşleme dosyasıdır. Kaynak ve hedefteki kimlikler birebir eşleşmeli; paylaşılan posta kutuları ve kaynak hesapları da dosyada olmalıdır.

KaynakUPN,HedefUPN,Tur,Dalga
ayse.yilmaz@ornekholding.onmicrosoft.com,ayse.yilmaz@anasirket.com.tr,Kullanici,1
muhasebe@ornekholding.onmicrosoft.com,muhasebe.ornek@anasirket.com.tr,PaylasilanKutu,1
mehmet.kaya@ornekholding.onmicrosoft.com,mehmet.kaya@anasirket.com.tr,Kullanici,2

Aynı isimli kullanıcılar, ayrılmış çalışanların lisanssız posta kutuları ve iki tenant’ta farklı yazılmış adlar (Türkçe karakterli ve karaktersiz) eşleme dosyasında elle çözülür. Otomatik eşleme betiği “Şahin” ile “Sahin”i aynı kişi saymaz. Dalga (wave) sütunu taşımayı departman veya lokasyon bazında gruplamak için kullanılır.

Kullanıcı tarafında neyin değiştiğini açıkça yazın: yeni oturum açma adı, Outlook profilinin yeniden oluşturulması, mobil cihazda hesap ekleme, OneDrive senkronizasyonunun yeniden başlatılması, Teams’te yeni tenant’a geçiş ve eski paylaşım bağlantılarının çalışmayacağı. Bu bilgiyi dalga başlamadan önce kısa bir rehberle paylaşmak destek taleplerini azaltır.

Teams ve SharePoint taşımasının sınırları

Teams ve SharePoint posta kutusundan daha karmaşıktır, çünkü içerik ile izin, URL ve bağlantılar birbirine bağlıdır:

• SharePoint site URL’leri değişir; belgelerdeki köprüler, Excel bağlantıları ve tarayıcı yer imleri eski adresi gösterir.
• Paylaşım bağlantıları (“bağlantıya sahip olanlar”) hedefte yeniden oluşturulmalıdır; dış kullanıcılarla yapılan paylaşımlar dahil.
• Teams toplantıları kaynak tenant’taki düzenleyiciye bağlıdır; tekrarlanan toplantılar hedefte yeniden oluşturulur.
• Teams sohbetleri yerel araçlarla taşınmaz. Mesaj geçmişinin hukuki veya operasyonel gerekliliği varsa ya bunu destekleyen bir araç seçilir ya da kaynak tenant bir süre salt okunur tutulup veriler eDiscovery ile dışa aktarılır.

Geçiş döneminde Entra ID cross-tenant synchronization ile kullanıcıları karşı tenant’ta B2B kullanıcı (varsayılan olarak dış üye) olarak oluşturmak, iki organizasyonun Teams’te birbirine ulaşmasını ve dosya paylaşmasını kolaylaştırır.

Kesim sonrası temizlik

• Cihazlar: Kaynak tenant’a kayıtlı cihazları hedefe yeniden kaydedin. Autopilot kullanılıyorsa donanım hash’lerini kaynaktan silip hedefe yeniden yükleyin; adımlar Windows Autopilot ile cihaz kurulumu rehberinde.
• Lisanslar: Taşınan kullanıcıların kaynak lisanslarını hemen değil, doğrulama bittikten sonra kaldırın; lisansı kaldırılan posta kutusu bekletme süresinden sonra silinir.
• Saklama yükümlülükleri: Dava bekletmesi veya saklama ilkesi altındaki veri varsa kaynak tenant’ın kapatılması hukuk biriminin onayına bağlanmalıdır.
• Yedek: Kaynak tenant’ı kapatmadan önce gereken verinin yedeğini alın; yöntemler için Microsoft 365 yedekleme yazısına bakabilirsiniz.
• Uygulama kayıtları ve SSO: Kaynak tenant’taki kurumsal uygulamaları hedefte yeniden yapılandırın, eski kayıtları devre dışı bırakın.
• DNS: Eski Autodiscover, SPF ve DKIM kayıtlarını hedef tenant’a göre güncelleyin; yeni tenant’ta DKIM imzalamayı etkinleştirin.

Kaynak tenant’ı kapatmak geri dönüşü kapatmaktır. Acele etmeyin.

Şirket içi Exchange’ten buluta taşıma farklı riskler taşır; o yöntemler için Exchange Online geçiş yöntemleri rehberine bakabilirsiniz. Birleşme ve devralma süreçlerinin teknik planlamasında destek için Microsoft 365 ve bulut hizmetleri ile bilişim danışmanlığı sayfalarımızı inceleyebilirsiniz. Yerel posta kutusu taşımanın güncel ön koşulları Microsoft’un cross-tenant mailbox migration dokümanındadır.

Sık sorulan sorular

Alan adı iki tenant’ta aynı anda kullanılabilir mi?

Hayır. Bir alan adı aynı anda yalnız tek bir Microsoft 365 tenant’ında doğrulanabilir. Hedefte kullanmak için kaynakta o alan adını kullanan tüm nesnelerden kaldırmak ve alan adını kaynaktan silmek gerekir; bu da planlı bir kesim penceresi ister.

Teams sohbet geçmişi yeni tenant’a taşınabilir mi?

Microsoft’un yerel cross-tenant araçları Teams sohbet ve kanal mesajlarını taşımaz. Kanal dosyaları SharePoint’te durduğu için taşınabilir; mesajların da taşınması gerekiyorsa bunu destekleyen üçüncü taraf araçlar değerlendirilir ya da mesajlar kaynakta arşivlenir.

Cross-tenant posta kutusu taşıma için ek lisans gerekir mi?

Evet. Microsoft’un yerel cross-tenant posta kutusu ve OneDrive taşıma özellikleri, taşınan her kullanıcı için ayrı bir taşıma lisansı ister. Güncel lisans adı ve koşulları için Microsoft dokümantasyonunu ve lisans sağlayıcınızı kontrol edin.

Taşınan kullanıcıların cihazları ne olur?

Kaynak tenant’a Entra join edilmiş ve Intune’a kayıtlı cihazlar hedefe kendiliğinden geçmez. Cihazlar kaynaktan çıkarılıp hedefe yeniden kaydedilir; Autopilot kayıtları da kaynakta silinip hedefte yeniden oluşturulur.