M&A Sonrası Microsoft 365 Tenant Birleştirme Rehberi (2026)

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-100/MS-102/AZ-104 sertifikalı danışmanlar

Özet (TL;DR): Bir şirket satın alındığında veya iki firma birleştiğinde, ayrı Microsoft 365 kiracılarındaki (tenant) posta kutuları, OneDrive dosyaları ve Teams sohbetlerinin tek bir kiracıda toplanması gerekir. Microsoft bu süreç için 2026'da "Migration Orchestrator" adlı resmi bir aracı devreye aldı: kimlik eşleme (Identity Mapping), tenant yapılandırması ve toplu taşıma (batch migration) olmak üzere üç ana aşamadan oluşuyor ve mailbox, OneDrive, Teams sohbet ile Teams toplantılarını kapsıyor. Bu yazıda Microsoft'un resmi dokümantasyonuna dayanarak süreci adım adım, gerçek PowerShell komutlarıyla anlatıyoruz; SharePoint siteleri ve Teams kanalları bu aracın kapsamı dışında kaldığı için ayrı planlanmalı.

Kurumunuz için ücretsiz tenant birleştirme değerlendirmesi almak isterseniz, kaynak ve hedef kiracınızın envanterini birlikte çıkaralım — kaç kullanıcı, hangi lisans, hangi workload taşınacak, 1 iş günü içinde raporlayalım.

Tenant birleştirme ne zaman gerekir?

Microsoft'un resmi tanımına göre tenant-tenant (kiracıdan kiracıya) göç, dört ana iş bağlamında ortaya çıkar:

• Birleşme veya satın alma: Şirketiniz başka bir firmayı satın aldı, kullanıcıları ve verileri tek bir kiracıda toplamanız gerekiyor.
• Bölünme (divestiture): Bir iş birimi ayrılıyor ve kullanıcıların başka bir organizasyona ait yeni veya mevcut bir kiracıya taşınması gerekiyor.
• Konsolidasyon: Geçmiş satın almalardan kalan birden fazla kiracınız var ve tek kiracıda birleştirmek istiyorsunuz.
• İç yeniden yapılanma: Aynı ana şirket içinde kullanıcıların bir kiracıdan diğerine taşınmasını gerektiren organizasyonel değişiklik.

Türkiye'de orta ölçekli şirket satın almaları ve grup içi konsolidasyonlar (holding yapıları, aynı sermaye grubuna ait farklı şirketlerin tek çatı altında BT yönetimine geçmesi) bu senaryonun en sık görüldüğü durumlar. Microsoft 365 danışmanlığı kapsamında Xen'in gördüğü projelerde tetikleyici çoğunlukla ya bir satın alma sözleşmesinin BT entegrasyon maddesi ya da iki ayrı CSP aboneliğinin tek faturaya indirilmek istenmesi oluyor.

Ön koşullar: lisans, roller ve tenant kimliği

Göçe başlamadan önce netleştirilmesi gereken temel unsurlar (kaynak: Microsoft Learn, Migration Orchestrator planlama ve ön koşullar, 2026-07 güncellemesi):

• Yönetici rolü: Kaynak ve hedef kiracıda Genel Yönetici (Global Administrator) erişimi gerekir; PowerShell komutlarını çalıştıracak hedef yöneticiler Genel Yönetici veya Microsoft 365 Migration Administrator rolünde olabilir.
• Posta özellikli güvenlik grubu: Kaynak kiracıda en az bir posta özellikli güvenlik grubu (mail-enabled security group) tanımlanmalı — taşınacak kullanıcı kapsamını (scope) bu grup belirler.
• Tenant ID: Karşı tarafın Microsoft 365 kiracı kimliği (tenant ID); Microsoft Entra ID > Özellikler sayfasından kopyalanır ve Organization Relationship yapılandırmasında kullanılır.
• Lisans: Cross-Tenant User Data Migration, kullanıcı başına tek seferlik ek ücretli bir lisans olarak Business Basic/Standard/Premium, F1/F3/E3/E5, Exchange Online, SharePoint ve OneDrive planlarına eklenti (add-on) şeklinde sunuluyor; EA, CSP, Web direct, küçük işletme ve eğitim (EDU) müşterileri için mevcut. Güncel liste fiyatı için CSP panelinize veya Microsoft hesap yöneticinize danışın — Microsoft resmi dokümantasyonunda sabit bir USD tutar yayınlanmıyor, bu yüzden burada rakam uydurmuyoruz.
• PowerShell modülleri: ExchangeOnlineManagement, Microsoft.Graph, Microsoft.Graph.Beta (en az 2.33.0) ve MicrosoftTeams modüllerinin her iki kiracıda da kurulu olması gerekir.

Uyumluluk açısından hassas sektörlerde (finans, sağlık, kamu) göçe başlamadan önce hukuk ve uyumluluk ekibinizle görüşün; Microsoft, GDPR/HIPAA gibi düzenlemelere tabi kurumlar için bunu açıkça öneriyor. Microsoft Security ekibimizle KVKK açısından veri sorumluluğu ve aktarım onayı konularını da bu aşamada netleştirmenizi öneririz.

Mimari modeller: tek seferde, aşamalı veya bölünerek taşıma

Microsoft Learn üç mimari yaklaşım tanımlıyor; hangisini seçeceğiniz kullanıcı sayısına ve organizasyonel karmaşıklığa bağlı:

• Tek seferlik göç (Single-Event Migration): Tüm kullanıcılar ve workload'lar tek bir kesinti penceresinde taşınır. Küçük-orta ölçekli şirketler veya basit organizasyonel değişiklikler için uygundur.
• Aşamalı göç (Phased Migration): Kullanıcılar zaman içinde gruplar (batch) halinde taşınır. Büyük kurumlar veya karmaşık ortamlar için idealdir; geçiş süresince iki kiracı arasında posta yönlendirme, takvim uygunluk (free/busy) paylaşımı ve Teams federasyonu gibi bir arada var olma (coexistence) mekanizmaları planlanmalıdır.
• Tenant taşıma/bölme (Tenant Move/Split): Kullanıcıların bir alt kümesi yeni bir kiracıya taşınırken diğerleri kalır. Bölünme (divestiture) senaryolarında yaygındır.

Örnek: 300 kişilik bir üretim firmasını satın alan 300 kişilik bir holding şirketi düşünelim. İki tarafın da Teams ve Exchange kullanımı yoğunsa, tek seferlik kesintiyle 600 kullanıcıyı aynı anda taşımak yerine aşamalı göç ile önce yönetim/finans, sonra operasyon, en son satış ekiplerini taşımak; iş sürekliliğini korurken hataları erken tespit etmeyi sağlar.

1. Adım: Identity Mapping (CTIM) ile kullanıcı eşleme

Cross-Tenant Identity Mapping (CTIM), kaynak kullanıcıları hedef kullanıcılarla bire bir eşleyen ve gerekli özniteliklerin (ExchangeGUID, ArchiveGUID, LegacyExchangeDN, UPN, birincil SMTP adresi) doğru şekilde yazılmasını sağlayan zorunlu bir ön adımdır. CTIM tamamlanmadan mailbox göçü başlatılamaz.

Kurulum, her iki kiracıda da tekrarlanmalı:

• Gerekli PowerShell modüllerini kurun: Install-Module ExchangeOnlineManagement, Install-Module Microsoft.Graph, Install-Module Microsoft.Graph.Beta
• CTIM modülünü kurun: Install-Module CrossTenantIdentityMapping -AllowPrerelease
• Genel Yönetici olarak bağlanın ve servis asıl hesabını (service principal) ekleyin: Connect-MgGraph → Import-Module CrossTenantIdentityMapping → Add-CtimServicePrincipal

CTIM süreci beş fazdan oluşur:

1. Kapsam belirleme (Scoping): Organization Relationship'ta tanımladığınız posta özellikli güvenlik grubu, taşınacak kullanıcıları belirler.
2. Kopyalama (Copying): Kaynak yönetici New-CtimCopyRequest -SecurityGroupGuid <GUID> -TargetTenantGuid <GUID> ile bir kopyalama isteği başlatır; hedef yönetici Accept-CtimCopyRequest ile onaylar.
3. Eşleme (Mapping): Hedef yönetici New-CtimMapRequest -SourceTenantGuid <GUID> ile eşlemeyi başlatır. Sistem, kaynak kullanıcının birincil SMTP adresini hedef kiracıdaki MailUser nesnesinin ExternalEmailAddress alanıyla otomatik eşleştirir (önerilen yöntem); eşleşme bulunamazsa CSV dosyasıyla manuel eşleme yapılabilir.
4. Yazma (Writing): New-CtimWriteRequest -SourceTenantGuid <GUID> komutu, eşlenen özniteliklerin hedef MailUser nesnesine yazılmasını sağlar. Hibrit (on-premises dizin senkronizasyonlu) hedef kiracılarda bu adım Exchange Server Management Shell üzerinden ayrıca çalıştırılmalı.
5. İzinlerin kaldırılması (isteğe bağlı): Göç tamamlandıktan sonra Remove-CtimServicePrincipal ile servis asıl hesabı kaldırılabilir.

Doğrulama için: kaynakta Get-Mailbox <Kullanıcı Takma Adı> | fl Name,ExchangeGuid, hedefte Get-MailUser <Kullanıcı> | fl Name,ExternalEmailAddress,EmailAddresses,PrimarySMTPAddress,ExchangeGuid komutlarıyla özniteliklerin doğru yazıldığı kontrol edilir. Tüm kullanıcılar "Tamamlandı" durumuna gelmeden mailbox göçüne geçilmemeli.

2. Adım: Kaynak ve hedef tenant'ı yapılandırma

CTIM tamamlandıktan sonra, göçü gerçekleştirecek uygulamaların her iki kiracıda da yetkilendirilmesi gerekir (kaynak: Microsoft Learn, tenant yapılandırma rehberi):

• Cross-Tenant Migration Service: Yalnızca hedef kiracıda Grant-CTMSAppPermissions çalıştırılır.
• OneDrive Migration uygulaması: Grant-OneDriveAppPermissions her iki kiracıda da çalıştırılır.
• Teams Sohbet Migration uygulaması: Grant-CTTMAppPermissions her iki kiracıda da çalıştırılır.
• Teams Toplantı Migration uygulaması: Kaynakta Grant-MMSAppPermissions -TenantType "source", hedefte Grant-MMSAppPermissions -TenantType "target".
• Takvim RBAC rolleri: Yalnızca hedef kiracıda Set-CalendarRBACRoles.
• Teams federasyonu: Her iki kiracıda Set-CsTenantFederationConfiguration -AllowFederatedUsers $True çalıştırılmalı; deneme (trial) kiracılarda ayrıca dış erişim (External Access) açılmalı.

Bu adımda ayrıca Organization Relationship yapılandırması yapılır: hedef kiracının tenant ID'si DomainName alanına, kapsamdaki güvenlik grubu MailboxMovePublishedScope alanına yazılır. Bu ilişki kurulmadan migration endpoint bulunamaz ve toplu göç (batch) reddedilir.

3. Adım: Migration batch oluşturma ve içerik taşıma

Migration Orchestrator, bir batch oluştururken dört workload'u destekler: Exchange posta kutuları, OneDrive, Teams sohbetleri ve Teams toplantıları. Birden fazla workload taşınacaksa, ayrı ayrı batch yönetmek yerine hepsini aynı batch'te birlikte çalıştırmak önerilir — orkestratör, bağımlılıkları hesaba katarak doğru sırayla taşır (örneğin Teams toplantı göçü, sohbet ve posta kutusu göçü olmadan başlatılamaz).

Batch gönderilmeden önce sistem otomatik ön doğrulama (pre-validation) kontrolleri çalıştırır; en sık karşılaşılan koşullar:

• Kullanıcı yalnızca bir batch'e ait olabilir — aynı kullanıcı iki farklı batch'te listelenirse göç reddedilir.
• Migration endpoint ve Organization Relationship doğru kurulmamışsa göç başlamaz.
• Teams Migration uygulaması her iki kiracıda da doğru sağlanmamış/etkinleştirilmemişse hata alınır.
• Kullanıcının her iki kiracıda da Teams lisansı olması zorunlu.
• Her kullanıcı Identity Mapping ile hedef kimliğe eşlenmiş olmalı.
• Toplantı göçü için her iki kiracıda giden istenmeyen posta (outbound spam) ilkesinde otomatik yönlendirme (AutoforwardingMode) açık olmalı.

Kapsam notu: bu araç yalnızca bulut-bulut (tenant-tenant) göçü kapsar; on-premises Exchange sunucusundan Exchange Online'a geçiş farklı bir proje ve farklı araçlar gerektirir (bakınız: Exchange 2016/2019'dan Exchange Online'a geçiş rehberimiz). Mailbox tarafında yalnızca kullanıcıya görünen içerik (e-posta, kişiler, takvim, görevler, notlar) taşınır; hukuki tutma (litigation hold) altındaki posta kutuları taşınamaz — göçten önce tutmaların kaldırılması veya mühendislik ekibiyle görüşülmesi gerekir. OneDrive tarafında artımlı (incremental/delta) taşıma desteklenmez, taşıma tek seferde yapılır ve kaynakta yönlendirme bağlantısı bırakılır. SharePoint siteleri ve Teams kanalları bu aracın kapsamında değildir — bunlar kaynak kiracıda kalır ve ayrı bir SharePoint göç projesi olarak planlanmalıdır.

Bu adımların sizin için karmaşık geldiğini düşünüyorsanız yalnız değilsiniz — WhatsApp'tan Xen'e yazın, kaç kullanıcı ve hangi workload'lar için CTIM + tenant yapılandırmasını birlikte planlayalım.

Doğrulama ve yaygın hatalar

Göç tamamlandıktan sonra kaynak posta kutusu silinir ve MailUser'a dönüştürülür; hedef adrese yönlendirme (targetAddress) damgalanır, böylece geçiş dönemi boyunca posta yönlendirmesi ve bir arada var olma (coexistence) sağlanır. En sık karşılaşılan sorunlar ve çözümleri:

• "Loopback redirect URI" hatası: Exchange Online PowerShell'e bağlıyken CTIM komutları çalıştırıldığında görülür. Çözüm: Exchange Online PowerShell ve Microsoft Graph bağlantısını kesip CTIM komutlarını temiz bir PowerShell oturumunda çalıştırın.
• "Gateway timeout" hatası: Genellikle CTIM servis asıl hesabının ilgili kiracıda tanımlı olmamasından kaynaklanır. Disconnect-MgGraph → Add-CtimServicePrincipal → isteği tekrar gönderin.
• Kopyalama isteği üzerine yazma (overwrite) uyarısı: Aynı kapsam için ikinci kez -Overwrite anahtarıyla kopyalama kabul edilirse önceki eşleme çalışması geri alınamaz şekilde kaybolur. Her seferinde eşleme dosyasının bir kopyasını indirip saklayın.
• CSV ayraç hatası: Manuel eşleme dosyası virgülden başka bir ayraç (noktalı virgül, dikey çizgi) içeriyorsa yükleme başarısız olur; dosyayı düz metin editöründe kontrol edin.

Go-live sonrası kontrol listesi: hedef kiracıda posta akışının (mail flow) doğru çalıştığını test edin, kullanıcıların Outlook/OWA'da eski e-postalara yanıt verebildiğini (LegacyExchangeDN doğru yazılmışsa bu sorunsuz çalışır) doğrulayın, Teams istemcisinde artık yalnızca hedef kimliğin kullanıldığını teyit edin ve kaynak kiracıdaki MailUser nesnelerini iş süreçleri izin verdiğinde temizleyin veya mail contact'a dönüştürün.

Lisanslama, kapsam dışı kalanlar ve KVKK notu

Fiyatlandırma tarafında net olalım: Microsoft, Cross-Tenant User Data Migration'ı "kullanıcı başına tek seferlik ek ücret" olarak tanımlıyor ancak resmi dokümantasyonda sabit bir USD liste fiyatı yayınlamıyor (2026-08 itibarıyla). Xen olarak CSP partner fiyat listemizden güncel tutarı sorgulayıp size TL karşılığıyla birlikte, kur riskini biz üstlenerek sabit fiyatla teklif ediyoruz — bu, tahmini rakamla sürpriz fatura riskini ortadan kaldırıyor.

Kapsam dışı kalan ve ayrıca planlanması gereken kalemler: SharePoint siteleri, Teams kanalları (bunlar için SharePoint Online göç rehberimize bakabilirsiniz), paylaşımlı posta kutuları ve dağıtım listeleri, üçüncü parti uygulama entegrasyonları (Logo Tiger, Netsis Fusion gibi yerli ERP sistemlerinin Microsoft 365 API bağlantıları göç sonrası yeniden yapılandırılmalı — API anahtarları ve webhook uç noktaları genelde tenant ID'ye bağlı çalışır).

KVKK açısından dikkat edilmesi gereken nokta: CTIM servisi, eşleme dosyasının geçici bir kopyasını 48 saat içinde silinmek üzere Avrupa Birliği'nde, hizmet günlüklerini de (kişisel veriden arındırılmış olarak) AB'de tutuyor; kalıcı veri ise hedef kiracının Exchange Online bölgesinde saklanıyor. 6698 sayılı KVKK'nın 12. maddesi kapsamında "gerekli teknik tedbirler" değerlendirmesi yaparken bu veri konumu bilgisini hukuk ekibinizle paylaşmanızı öneririz; VERBİS kaydınızda veri işleyen olarak Microsoft'un bu alt işlemi zaten kapsamda.

Saha vakası: 45 kişilik hukuk bürosu satın alması, 2 haftalık tenant birleştirme

Firma X — İstanbul merkezli 45 kişilik bir hukuk bürosunu satın alan 120 kişilik bir danışmanlık grubu — iki ayrı Microsoft 365 kiracısını tek çatı altında toplamak istedi. Süre: 2 hafta planlama + 3 gün aktif göç penceresi. Karar noktaları: (1) hangi tarafın kiracısının "hedef" olacağı — grup şirketinin mevcut Entra ID Conditional Access politikaları daha olgun olduğu için grup kiracısı hedef seçildi; (2) hukuki tutma altındaki 6 posta kutusunun (devam eden dava dosyaları nedeniyle) göç dışında bırakılıp ayrı arşivlenmesi; (3) 45 kullanıcının Teams sohbet geçmişinin iş sürekliliği açısından kritik görülmesi nedeniyle aşamalı değil tek seferlik göç modeli seçilmesi.

Sonuç: göç penceresi boyunca yalnızca 40 dakikalık planlı bir posta kesintisi yaşandı, hiçbir OneDrive dosyası kaybolmadı, hukuki tutma altındaki kutular ayrı bir e-keşif (eDiscovery) sürecine alındı. Xen ekibinin rolü: CTIM eşleme dosyasının hazırlanması, güvenlik grubu kapsamının doğrulanması ve go-live gecesi canlı izleme. Uyarı: hukuki tutma altındaki kutuların göç dışı bırakılması kararı erken, planlama aşamasında netleştirilmeli — göç günü fark edilmesi tüm batch'i durdurabilir.

Kendi senaryonuza uygun mimari modeli (tek seferlik, aşamalı veya bölünerek) ve ön koşul kontrol listesini görmek isterseniz çözüm sayfamızdan detaylı bilgi alabilir, benzer birleştirme projelerimizi inceleyebilirsiniz.

Sıkça Sorulan Sorular (SSS)

Migration Orchestrator, SharePoint sitelerini de taşıyor mu?

Hayır. Microsoft'un resmi dokümantasyonuna göre Cross-Tenant User Data Migration çözümü yalnızca Exchange posta kutuları, OneDrive, Teams sohbetleri ve Teams toplantılarını kapsar; paylaşımlı SharePoint siteleri ve Teams kanalları bu aracın dışındadır ve ayrı bir SharePoint göç projesi olarak planlanmalıdır.

Tenant birleştirme ne kadar sürer?

Küçük ölçekli satın almalarda (1000 kullanıcının altı) planlamadan devreye almaya 8-12 hafta, orta ölçekli anlaşmalarda (1000-10.000 kullanıcı) 12-20 hafta sürebiliyor; aktif taşıma penceresi ise kullanıcı sayısı, posta kutusu boyutu ve ağ bant genişliğine göre birkaç günden birkaç haftaya kadar değişir.

Kullanıcıların e-posta adresi değişecek mi?

Bu, kimlik stratejisi kararınıza bağlı. Genelde kullanıcı asıl adres alanını (UPN, birincil SMTP) hedef kiracının kabul edilen alan adına taşır; eski alan adı için posta yönlendirmesi (kaynak MailUser üzerinden) geçiş dönemi boyunca korunur.

Hukuki tutma (litigation hold) altındaki posta kutuları taşınabilir mi?

Hayır, herhangi bir tutma türü altındaki posta kutuları için göç engellenir. Bu kutular için Microsoft mühendislik ekibiyle görüşülmesi veya tutmanın kaldırılıp ayrı arşivlenmesi gerekir.

Fiyata neler dahil, kur farkını kim üstleniyor?

Microsoft, kullanıcı başına tek seferlik ek lisans ücreti alıyor; güncel tutar Microsoft'un resmi fiyat listesinde USD cinsinden yayınlanmıyor, CSP partner fiyatlandırmasına göre değişiyor. Xen bu tutarı CSP panelinden sorgulayıp size sabit TL fiyatla teklif eder — kur riskini biz üstleniyoruz.

Yerli ERP entegrasyonlarımız (Logo Tiger, Netsis) göçten etkilenir mi?

Evet, kontrol edilmesi gereken bir alan. Bu tür sistemlerin Microsoft 365 API bağlantıları (e-posta gönderimi, SharePoint doküman entegrasyonu gibi) genelde tenant ID'ye ve uygulama kayıtlarına bağlıdır; göç sonrası bu entegrasyonların hedef kiracıda yeniden kaydedilmesi ve test edilmesi gerekir.

Kaç günde kurulur, planlamaya ne zaman başlamalıyız?

Teknik kurulum (CTIM + tenant yapılandırma) deneyimli bir ekiple 3-5 iş günü sürebilir; ancak kullanıcı iletişimi, lisans envanteri ve hukuki/uyumluluk onayları dahil toplam planlama süresi genelde 4-8 haftayı buluyor. Satın alma sözleşmesi imzalanır imzalanmaz BT entegrasyon planlamasına başlamanızı öneririz.

Sonuç: doğru araçla tenant birleştirme öngörülebilir bir proje

Microsoft 365 tenant birleştirme, doğru sırayla ilerlendiğinde (önce kimlik eşleme, sonra tenant yapılandırması, en son toplu taşıma) öngörülebilir ve ölçülebilir bir BT projesidir. Migration Orchestrator'ın getirdiği en büyük fayda, workload bağımlılıklarını (Teams toplantısının posta kutusuna bağımlı olması gibi) otomatik yönetmesi ve manuel hata riskini azaltması.

Yine de araç tek başına yeterli değil: hukuki tutma altındaki kutuların erken tespiti, yerli ERP entegrasyonlarının yeniden bağlanması ve KVKK kapsamında veri konumu değerlendirmesi gibi kararlar insan tarafından, planlama aşamasında alınmalı. Satın alma veya birleşme sürecinizin BT entegrasyon takvimini, sözleşme imzalanmadan önce netleştirmeniz sürpriz maliyetleri önler.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun tenant birleştirme ve göç yolculuğunda uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.