Exchange Online Geçiş Yöntemleri: Cutover, Staged, IMAP ve Hibrit

Exchange Online’a geçişte işin çoğu posta taşımak değil, yanlış yöntemi seçmemektir. Cutover, staged, IMAP ve hibrit aynı hedefe gider; ama kesinti süresi, geri dönüş imkânı ve kesim sabahı destek hattına düşen çağrı sayısı tamamen farklıdır. Aşağıda yöntemi kullanıcı sayısına, kaynak sistem sürümüne ve kesinti toleransına göre nasıl seçeceğinizi ve seçtiğiniz yöntemi hangi sırayla uygulayacağınızı anlatıyoruz.

Dört geçiş yolu ve gerçek kullanım alanları

Exchange Online’ın yerel araçlarıyla dört geçiş yolu var. Her biri belirli bir kaynak ortam ve ölçek için tasarlanmış; birini diğerinin yerine zorlamak sorun çıkarır.

• Cutover geçiş: Şirket içi Exchange’deki tüm posta kutuları tek bir toplu işte (batch) taşınır. Kaynak sunucuda Outlook Anywhere yapılandırılmış ve internetten erişilebilir olmalı. Dizin senkronizasyonu kapalı olmalı; kullanıcıları bulutta toplu işin kendisi oluşturur. Teknik üst sınır 2.000 posta kutusu, ama Microsoft oluşturma ve taşıma süresi nedeniyle bu yöntemi 150 ve altı kullanıcı için makul görüyor.
• Staged geçiş: Posta kutuları gruplar halinde taşınır, dizin senkronizasyonu zorunludur. Yalnız Exchange 2003 ve 2007 için desteklenir; Exchange 2010 ve sonrasında bu yöntem yok. Bugün sahada karşılığı neredeyse kalmadı.
• IMAP geçiş: Zimbra, cPanel tabanlı barındırma veya eski bir IMAP sunucusundan yalnız e-posta taşınır. Takvim, kişiler ve görevler gelmez. Kaynak Google Workspace ise Exchange Online’ın ayrı Google Workspace geçiş toplu işi posta, takvim ve kişileri birlikte taşıdığı için önce ona bakın. Microsoft’un belgelediği sınırlar: posta kutusu başına en fazla 500.000 öğe ve 35 MB’a kadar tekil ileti boyutu.
• Hibrit geçiş: Şirket içi Exchange ile Exchange Online bir süre birlikte çalışır; posta kutuları gruplar halinde, kullanıcı fark etmeden ve gerekirse geri alınabilir şekilde aktarılır. Ortak GAL, serbest/meşgul bilgisi ve tek alan adı altında posta akışı sağlanır. Orta ve büyük ortamlarda ve uzun süreli birlikte çalışma gereken durumlarda standart yol budur.

Yerel araçların yetmediği kaynaklarda (takvim ve kişilerin de taşınması gereken, IMAP dışında erişim sunmayan sistemlerde) üçüncü taraf geçiş araçlarına bakılır. İki tenant arasındaki taşıma ise ayrı bir iş; onu tenant-to-tenant geçiş planı yazısında anlattık.

Karar tablosu: kullanıcı sayısı, sürüm ve kesinti toleransı

Karar sırası basit. Kaynak Exchange değilse IMAP veya üçüncü taraf araç. Kaynak Exchange ise ve kullanıcılar şirket içi AD’den yönetilmeye devam edecekse hibrit. AD senkronizasyonu istenmiyorsa, kullanıcı sayısı düşükse ve tek bir hafta sonunda kesim kabul ediliyorsa cutover. Cutover’ın 2.000 posta kutusu sınırı kâğıt üzerinde kalır; o sayıya yaklaşan bir ortamda tek gecede Outlook profili değiştirmek destek ekibinin kapasitesini aşar. Sınır teknik değil, operasyoneldir.

Geçiş öncesi hazırlık: DNS, lisans, UPN ve posta kutusu boyutları

Geçişin büyük kısmı şirket içi sunucu ve sistem altyapısının hazırlığında kazanılır ya da kaybedilir. Aşağıdaki maddeler yöntemden bağımsız olarak kesimden önce kapanmalı.

• Alan adı doğrulama: Kullanılan tüm SMTP alan adları Microsoft 365’e TXT kaydıyla eklenip doğrulanır. MX kaydına bu aşamada dokunulmaz.
• UPN uyumu: Kullanıcının UPN’i birincil SMTP adresiyle aynı olmalı. .local gibi yönlendirilemeyen sonekler senkronizasyondan önce yönlendirilebilir bir sonekle değiştirilir. Bu çalışmanın ayrıntısı Entra Connect Sync ve Cloud Sync karşılaştırması yazısında.
• Lisans: Posta kutusu taşınmadan önce kullanıcıya Exchange Online içeren bir lisans atanır. Paylaşılan posta kutuları 50 GB’ı aşmıyor ve arşiv/saklama gerektirmiyorsa lisanssız kalabilir.
• Posta kutusu boyutları: Exchange Online Plan 1 posta kutusu 50 GB, Plan 2 100 GB birincil depolama sunar. Kotayı aşan posta kutuları önce arşive bölünür veya temizlenir.
• Bağlı veriler: PST dosyaları, ortak klasörler (public folders), oda/kaynak posta kutuları ve SMTP ile posta gönderen uygulamalar (yazıcı, ERP, izleme sistemleri) ayrı bir envantere yazılır. Sahada en sık unutulan bağımlılık uygulama SMTP röleleridir; fark edildiğinde genellikle fatura e-postaları çoktan gitmemeye başlamıştır.

Boyut envanteri için şirket içi Exchange Management Shell’de şu komut yeterli:

Get-Mailbox -ResultSize Unlimited |
  Get-MailboxStatistics |
  Select-Object DisplayName, ItemCount, TotalItemSize |
  Sort-Object TotalItemSize -Descending |
  Export-Csv C:\Gecis\mailbox-boyut.csv -NoTypeInformation -Encoding UTF8

Çıkan listenin en üstündeki birkaç posta kutusu, geçişin toplam süresini belirler. Onları ayrı planlayın.

Hibrit geçişte Hybrid Configuration Wizard ve migration batch akışı

Hibrit kurulum Hybrid Configuration Wizard (HCW) ile yapılır. HCW; organizasyon ilişkisini (organization relationship), OAuth’u, gönderme/alma bağlayıcılarını (connector), uzak etki alanlarını ve geçiş uç noktasını (migration endpoint) iki tarafta birlikte kurar. Sihirbaz hata verdiğinde neredeyse her zaman aşağıdaki ön koşullardan biri eksiktir; çalıştırmadan önce tek tek kontrol edin:

1. Şirket içi Exchange güncel ve Microsoft tarafından destekleniyor olmalı; desteklenen sürüm ve CU listesi için Microsoft’un hibrit dağıtım ön koşulları sayfası esas alınır.
2. Dizin senkronizasyonunda Exchange hibrit dağıtım seçeneği (Exchange hybrid writeback) etkin olmalı. Entra Connect Sync’te bu, kurulum sihirbazındaki isteğe bağlı özelliklerden biridir; Cloud Sync kullanılıyorsa desteğin güncel durumunu Microsoft Learn’den doğrulayın.
3. Klasik topolojide EWS sanal dizininde MRS Proxy uç noktası etkin olmalı (Set-WebServicesVirtualDirectory -MRSProxyEnabled $true). HCW bunu yapılandırabilir, ama birden fazla sunucu varsa hepsinde tutarlı olduğunu kendiniz kontrol edin.
4. Autodiscover ve EWS adları için genel CA’dan alınmış geçerli bir sertifika Exchange’e atanmış olmalı.
5. Klasik topolojide Exchange Online’ın EWS/Autodiscover adreslerine 443’ten erişebilmesi gerekir. Gelen erişim açılamıyorsa modern hibrit (Hybrid Agent) seçilir; bu durumda giden 443 bağlantısı kullanılır, ama posta akışı için 25 portu yine planlanmalı.
6. HCW’yi çalıştıran hesabın şirket içinde Organization Management, bulutta Global Administrator (veya eşdeğer Exchange yetkisi) rolü olmalı.

Hibrit kurulduktan sonra taşıma, uzak taşıma (remote move) toplu işleriyle yapılır. Exchange Online PowerShell’de tipik akış:

Connect-ExchangeOnline -UserPrincipalName admin@ornek.com.tr

# Geçiş uç noktasının erişilebilirliğini doğrulama
Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.ornek.com.tr -Credentials (Get-Credential)

# CSV: EmailAddress sütununda taşınacak kullanıcılar
New-MigrationBatch -Name "Dalga-01" `
  -SourceEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" `
  -CSVData ([System.IO.File]::ReadAllBytes("C:\Gecis\dalga-01.csv")) `
  -TargetDeliveryDomain "ornek.mail.onmicrosoft.com" `
  -AutoStart

# İlerleme takibi
Get-MigrationBatch "Dalga-01"
Get-MigrationUser -BatchId "Dalga-01" | Get-MigrationUserStatistics |
  Select-Object Identity, Status, PercentageComplete, TotalItemsInSourceMailboxCount

# Ön senkronizasyon bitince, planlanan saatte tamamlama
Complete-MigrationBatch -Identity "Dalga-01"

Uç nokta adı HCW’nin oluşturduğu adla aynı olmalı; Get-MigrationEndpoint ile kontrol edin. Toplu işi otomatik tamamlamaya bırakmazsanız veri artımlı senkronize edilir ve kullanıcı geçişi mesai dışında birkaç dakikalık son senkronizasyonla kapanır. Dalgaları departman bazında planlayın: yönetici ile asistanı, paylaşılan takvim kullanan ekipler aynı dalgada olmalı, çünkü bulut ile şirket içi arasında bazı vekâlet ve klasör izinleri sınırlı çalışır. Ayrı dalgaya düşen vekâlet ilişkisi ilk gün şikâyet üretir.

MX, Autodiscover ve istemci kesim sırası

Kesim sırası yönteme göre değişir. Yanlış sıra genellikle ileti kaybettirmez; Outlook bağlantı sorunları ve kesim sabahı destek talebi yığılması üretir.

Hibrit yöntemde

• Geçiş boyunca MX ve Autodiscover şirket içinde kalabilir. Şirket içi Autodiscover, taşınmış posta kutusu için targetAddress özniteliği üzerinden istemciyi Exchange Online’a yönlendirir.
• Son dalga tamamlanınca MX kaydı, Microsoft 365 yönetim merkezinde alan adı için gösterilen değere çevrilir. Eski MX’in TTL süresi dolana kadar şirket içi alım bağlayıcısı açık tutulur.
• Autodiscover CNAME kaydı en son autodiscover.outlook.com değerine çevrilir; SPF kaydına include:spf.protection.outlook.com eklendiğinden emin olun.

Cutover ve IMAP yönteminde

• İlk senkronizasyon tamamlanınca MX kaydı Exchange Online’a çevrilir ve TTL süresi kadar beklenir.
• Bu sürede eski sisteme düşen iletiler toplu işin artımlı senkronizasyonuyla aktarılmaya devam eder; ardından toplu iş tamamlanır.
• Autodiscover güncellenir, kullanıcıların Outlook profilleri yeniden oluşturulur. Mobil cihazlarda hesap silinip yeniden eklenir.

Her iki durumda da TTL değerini MX değişikliğinden birkaç gün önce kısaltmak (örneğin 300 saniye) geri dönüş penceresini daraltır. Kesimden sonra teslim edilmeyen iletilerin teşhisi için Exchange Online posta akışı sorun giderme rehberindeki message trace adımlarını kullanın.

Geçiş sonrası şirket içi Exchange’in durumu

Son posta kutusu taşındığında şirket içi Exchange’i hemen kaldırmak, sahada sık gördüğümüz ve geri alması zor bir hatadır. Kullanıcılar şirket içi AD’den senkronize edildiği sürece kaynak yetki (source of authority) AD’dir: e-posta adresleri, proxyAddresses ve alıcı türü gibi öznitelikler bulutta değil şirket içinde değiştirilir. Bu öznitelikleri ADSI Edit ile elle düzenlemek desteklenmez ve tutarsızlık üretir.

Üç seçenek var:

• Bir yönetim sunucusu bırakmak: Alıcı yönetimi ve SMTP rölesi için tek bir Exchange sunucusu tutulur ve düzenli sunucu ve bulut yönetimi kapsamında güncel kalır. En az riskli yol budur.
• Yalnız yönetim araçlarıyla devam etmek: Exchange Server 2019 CU12 ve sonrası yönetim araçları, son Exchange sunucusu kapatıldıktan sonra alıcı özniteliklerinin PowerShell ile yönetilmesine imkân verir. Bu modelde Exchange Admin Center ve hibrit posta akışı yoktur.
• Bulut kaynaklı kimliğe geçmek: Dizin senkronizasyonu kapatılır, kullanıcılar bulutta yönetilir. Şirket içi AD’ye bağlı başka uygulamalar varsa genellikle uygun değildir.

Hangi yolu seçerseniz seçin, SMTP ile posta gönderen cihaz ve uygulamalar Exchange Online’a (SMTP AUTH, doğrudan gönderim veya bağlayıcı üzerinden röle) taşınmadan sunucuyu kapatmayın. Exchange veritabanlarının son yedeğini alın ve saklama süresini belirleyin. Bulut tarafındaki veri koruma ihtiyacı için Microsoft 365 yedekleme yazısına bakabilirsiniz.

Sahada en sık gördüğümüz hatalar

• Sertifikayı son anda yenilemek: HCW’nin kullandığı sertifika geçiş sırasında değişirse bağlayıcılar ve OAuth güveni bozulur. Sertifikanın geçiş boyunca geçerli kalacağını baştan doğrulayın.
• Ters proxy veya WAF’ın EWS’yi kesmesi: MRS proxy trafiği uzun süreli ve yoğun bağlantılar kurar. Taşıma hatalarında ilk bakılacak yer zaman aşımı ve ön kimlik doğrulama ayarlarıdır.
• Lisansı geç atamak: Lisanssız taşınan kullanıcının posta kutusu bir süre sonra devre dışı kalır. Lisans, toplu işten önce atanır.
• Uygulama SMTP trafiğini unutmak: Fatura, alarm ve tarama e-postaları geçişten sonra sessizce kaybolur. Envantere gönderen IP’ler ve hesaplar yazılmalı.
• Kullanıcı iletişimini atlamak: Mobil cihaz yeniden kurulumu ve Outlook profili değişikliği önceden duyurulmazsa destek talepleri kesim sabahı yığılır.
• Kimlik kararını sonraya bırakmak: Kimlik doğrulama yöntemi (PHS, PTA, federasyon) geçiş başlamadan belirlenmeli. Geçiş ortasında değiştirilirse oturum açma sorunları geçiş sorunlarıyla karışır ve teşhis iki katına çıkar.

Hibrit yapılandırmanın resmi ön koşulları ve desteklenen topolojiler için Microsoft’un Exchange hibrit dağıtım dokümantasyonu esas alınmalı. Planlama, dalga yönetimi ve kesim aşamalarında destek gerekiyorsa Microsoft 365 ve bulut hizmetleri sayfasından kapsamı inceleyebilirsiniz.

Sık sorulan sorular

Cutover geçişte kaç posta kutusu taşınabilir?

Microsoft cutover geçişte en fazla 2.000 posta kutusu taşınabileceğini belirtir, ama süre nedeniyle 150 ve altı kullanıcıyı makul sınır olarak önerir. Bu sayının üzerinde Outlook profillerinin yeniden oluşturulması ve tek bir kesim gününün yönetimi zorlaşır. Kullanıcı sayısı yüksekse veya geçiş birkaç haftaya yayılacaksa hibrit yöntem daha kontrollüdür.

Hibrit geçiş için Exchange sunucusunun internete açık olması gerekir mi?

Klasik hibrit topolojide Exchange Online’ın EWS ve Autodiscover uç noktalarına 443 portundan, posta akışı için de 25 portundan erişebilmesi gerekir. Modern hibrit (Hybrid Agent) kullanıldığında posta kutusu taşıma ve serbest/meşgul bilgisi için gelen 443 erişimi gerekmez; hibrit posta akışı için SMTP bağlantısı yine planlanmalıdır.

Geçişten sonra kullanıcıların Outlook profilini yeniden oluşturması gerekir mi?

Hibrit geçişte posta kutusu taşındığında Autodiscover kullanıcıyı Exchange Online’a yönlendirir ve profil genellikle korunur. Cutover, staged ve IMAP geçişlerinde hedef farklı bir organizasyon olduğu için Outlook profili yeniden oluşturulur; OST dosyası da sıfırdan iner.

Son posta kutusu taşındıktan sonra şirket içi Exchange kaldırılabilir mi?

Kullanıcılar Entra Connect ile şirket içi AD’den senkronize ediliyorsa alıcı öznitelikleri şirket içinde yönetilmeye devam eder. Exchange Server 2019 CU12 ve sonrasındaki yönetim araçlarıyla son Exchange sunucusu kapatılabilir; bu adım hibrit posta akışı, uygulama SMTP röleleri ve Autodiscover kayıtları temizlendikten sonra atılır.