Kaynak sistemi ve posta kutularını envanterleyin
Exchange sürümü veya mevcut sağlayıcı, kullanıcılar, paylaşımlı kutular, gruplar, yönlendirmeler, arşivler, toplam veri, büyük iletiler, takvim ve kişi gereksinimleri çıkarılır.
Envanter · Yöntem · Pilot · DNS · Doğrulama
Microsoft 365 Kurumsal E-Posta Geçiş Rehberi
Microsoft 365’e e-posta geçişi yalnız MX kaydını değiştirmek değildir. Kaynak veri, kimlik, lisans, istemci, DNS, güvenlik, pilot ve geri dönüş planı birlikte yönetilmelidir.
Nasıl çalışır?1 2 3 4 5 6
Temel işleyiş
Hedef tenant ve lisansları hazırlayın
Alan adı, yönetici rolleri, kullanıcı adları, lisanslar, güvenlik temeli ve hedef posta kutuları oluşturulur. Kaynak ile hedef eşleştirme listesi değişiklik kontrolü altında tutulur.
Doğru geçiş yöntemini seçin
Kaynağa göre Exchange cutover veya hybrid, Google Workspace geçişi, IMAP, PST içe aktarma ya da tenantlar arası yöntem değerlendirilir. Her yöntemin taşıdığı veri türleri aynı değildir.
Pilot kullanıcılarla gerçek veri test edin
Farklı posta kutusu boyutu ve kullanım profilinden pilot kullanıcı seçilir. E-posta, klasör, takvim, kişi, yetki, mobil cihaz, Outlook ve mail akışı ayrı kabul kriterleriyle kontrol edilir.
DNS kesişimi ve kullanıcı iletişimini yönetin
MX, SPF, DKIM, DMARC, Autodiscover ve ilgili DNS kayıtları planlanır. Değişiklik saati, TTL, kullanıcı girişleri, mobil cihazlar, yardım kanalı ve geri dönüş kararı önceden yazılır.
Doğrulama, güvenlik ve eski sistemi kapatma
Mail akışı, veri sayımı, hatalar, paylaşımlar ve istemciler doğrulanır; MFA ve gerekli güvenlik politikaları devreye alınır. Eski sistem ancak kabul ve gerekli saklama/yedek kararı tamamlandıktan sonra kapatılır.
Geçiş öncesi hangi bilgiler toplanmalıdır?
Posta kutusu adedi yalnız başlangıç bilgisidir. Veri tipi, kimlik, DNS, istemci ve iş sürekliliği unsurları ölçülmeden süre ve yöntem güvenilir biçimde belirlenemez.
- Kullanıcı, paylaşımlı posta kutusu, dağıtım grubu, oda ve kaynak listesi
- Posta kutusu boyutu, klasör ve öğe sayısı, arşiv ve PST kullanımı
- Takvim, kişi, görev, delegasyon, Send As ve yönlendirme gereksinimleri
- Alan adı, DNS sağlayıcısı, MX/SPF/DKIM/DMARC ve Autodiscover kayıtları
- Outlook sürümleri, mobil cihazlar, uygulamalar ve SMTP kullanan sistemler
IMAP geçişinin sınırları nelerdir?
IMAP birçok cPanel, hosting ve farklı e-posta sisteminden ileti taşımak için kullanılabilir; ancak tam bir grup çalışması veya kimlik geçişi değildir.
- IMAP temel olarak e-posta klasörlerini taşır; kişi, takvim ve görevleri otomatik taşımaz.
- Hedef Microsoft 365 posta kutuları geçişten önce oluşturulmalı ve lisanslanmalıdır.
- Kaynak bağlantı, öğe boyutu, klasör adı ve erişim sınırları pilotta test edilmelidir.
- Paylaşımlı kutu, yönlendirme ve delegasyonlar ayrı yapılandırma olarak ele alınır.
- Yeni posta akışının ne zaman hedefe döneceği MX değişikliğiyle planlanır.
Exchange Server’dan geçiş nasıl seçilir?
Exchange sürümü, posta kutusu sayısı, dizin senkronizasyonu, birlikte çalışma süresi ve geri dönüş ihtiyacı cutover, express veya hybrid yolunu etkiler.
- Küçük ve tek seferde taşınabilecek yapılarda cutover değerlendirilebilir.
- Kademeli taşıma ve uzun süreli birlikte çalışma gerekiyorsa hybrid senaryo incelenir.
- Exchange sürümü ve destek durumu seçilebilecek yöntemi sınırlar.
- Microsoft Entra Connect veya bulut eşitleme gereksinimi kimlik tasarımıyla birlikte ele alınır.
- SMTP relay, uygulama, tarayıcı, cihaz ve ortak adres defteri bağımlılıkları test edilir.
Google Workspace veya başka tenant geçişi nasıl farklıdır?
Kaynak hizmet yalnız posta değil takvim, kişi ve dosya iş yüklerini de içeriyorsa her veri türü için ayrı kapsam ve araç değerlendirilmelidir.
- Google Workspace için yönetici izinleri, API ve kaynak/target yönlendirme hazırlığı yapılır.
- Etiket, paylaşım, takvim, kişi ve ortak alan davranışları birebir aynı olmayabilir.
- Tenantlar arası geçişte alan adı, kullanıcı eşleştirmesi ve hedef nesneler önceden hazırlanır.
- OneDrive ve SharePoint geçişi e-posta geçişinden ayrı iş paketi olabilir.
- Üçüncü taraf araç kullanılıyorsa güvenlik, veri konumu ve lisans kapsamı incelenir.
Kesinti nasıl yönetilir?
“Sıfır kesinti” genel bir garanti olarak verilmemelidir. Amaç, kullanıcı etkisini ölçmek, geçiş penceresini planlamak ve başarısızlık halinde uygulanacak kararı önceden belirlemektir.
- DNS TTL ve değişiklik yayılımı geçişten önce ölçülür.
- Ön eşitleme veya çok geçişli yöntem destekleniyorsa veri yükü önceden azaltılır.
- Pilot sonucuna göre kullanıcı grupları ve geçiş dalgaları oluşturulur.
- Eski ve yeni sisteme gelebilecek postanın davranışı test edilir.
- Geri dönüş tetikleyicisi, sorumlular ve kullanıcı iletişim metni yazılı hale getirilir.
Geçiş hangi kontrollerle tamamlanır?
MX kaydının değişmesi projenin bittiği anlamına gelmez. Veri, mail akışı, kullanıcı erişimi, güvenlik ve eski sistem kapatma kontrolleri ayrı ayrı kapatılmalıdır.
- İç ve dış mail akışı, SPF/DKIM/DMARC ve istenmeyen posta davranışı test edilir.
- Pilot ve örnek kullanıcıların klasör, öğe, takvim, kişi ve delegasyonları doğrulanır.
- Outlook, web ve mobil istemci erişimi kontrol edilir.
- MFA, yönetici rolleri ve e-posta güvenliği politikaları devreye alınır.
- Eski sistem saklama, yedek, silme ve kapatma kararı kayıt altına alınır.
Kaynak sisteme göre Microsoft 365 geçiş yolu
Yöntem seçimi kaynak sürüm, veri türü, posta kutusu sayısı, kimlik ve birlikte çalışma ihtiyacına göre yapılır. Tablo keşif yerine kısa liste sağlar.
| Kaynak yapı | Değerlendirilecek yöntem | Kritik sınırlama veya kontrol |
|---|---|---|
| cPanel, Plesk veya başka IMAP sistemi | IMAP geçişi veya uygun üçüncü taraf araç | IMAP yalnız e-postayı taşır; kişi, takvim ve görev ayrı planlanır |
| Exchange Server | Cutover, express veya hybrid | Exchange sürümü, kullanıcı adedi, dizin senkronizasyonu ve birlikte çalışma |
| Google Workspace | Microsoft’un Google geçiş yöntemi veya doğrulanmış araç | E-posta, takvim, kişi, etiket, paylaşım ve API sınırları |
| Başka Microsoft 365 tenant | Tenantlar arası posta kutusu ve ayrı iş yükü geçişleri | Alan adı aktarımı, nesne eşleştirme, lisans ve DNS kesişimi |
| PST arşivleri | Ağ yükleme, içe aktarma hizmeti veya kontrollü istemci aktarımı | Dosya bütünlüğü, tekrar, sahiplik, saklama ve içe aktarma raporu |
Sık sorulan sorular
Konuyla ilgili net cevaplar
Microsoft 365’e e-posta geçişi nasıl yapılır?
Önce kaynak sistem ve veri envanteri çıkarılır; hedef tenant, kullanıcı ve lisanslar hazırlanır; uygun yöntem seçilir; pilot yapılır; veri eşitlenir; DNS ve mail akışı kontrollü değiştirilir; son olarak veri, istemci, güvenlik ve eski sistem kapatma kontrolleri tamamlanır.
cPanel e-postaları Microsoft 365’e taşınabilir mi?
Kaynak sistem IMAP destekliyorsa e-posta klasörleri taşınabilir. Ancak kişi, takvim, görev, yönlendirme ve delegasyonlar IMAP ile otomatik taşınmaz; ayrı kapsamlandırılmalıdır.
Google Workspace’ten Microsoft 365’e geçiş yapılabilir mi?
Evet. Microsoft’un ve üçüncü tarafların desteklediği geçiş yolları bulunur. E-posta, takvim, kişi ve dosya kapsamı; API izinleri, kaynak hazırlığı ve kullanıcı eşleştirmesi pilotla doğrulanmalıdır.
Microsoft 365 mail geçişinde kesinti olur mu?
Kullanıcı etkisi yönteme, DNS yayılımına, veri hacmine ve kaynak sisteme göre değişir. Genel bir “sıfır kesinti” garantisi doğru değildir; ön eşitleme, pilot, geçiş penceresi ve geri dönüş planıyla etki azaltılır.
IMAP geçişi takvim ve kişileri taşır mı?
Hayır. Microsoft’un dokümantasyonuna göre IMAP geçişi e-posta klasörlerine odaklanır; kişiler, takvim öğeleri ve görevler bu yöntemle taşınmaz. Bunlar için ayrı yöntem gerekir.
E-posta geçişinden önce lisans atanmalı mı?
Hedef posta kutularının oluşturulması ve kullanılabilmesi için uygun lisansların zamanlaması planlanmalıdır. IMAP gibi yöntemlerde hedef posta kutuları geçiş başlamadan önce mevcut olmalıdır.
Microsoft 365 geçişi ne kadar sürer?
Süre posta kutusu adedi, toplam veri, kaynak bağlantı sınırı, veri türü, yöntem, pilot sonucu, DNS ve kullanıcı dalgalarına bağlıdır. Envanter ve pilot olmadan verilen sabit süre güvenilir değildir.
Microsoft 365 geçiş teklifinde neler bulunmalıdır?
Kaynak ve hedef kapsamı, kullanıcı/posta kutusu adedi, veri türleri, seçilen yöntem, taşınmayan öğeler, lisanslar, pilot, DNS, güvenlik, istemci desteği, kabul kriterleri, geri dönüş ve eski sistem kapatma sorumlulukları ayrı yazılmalıdır.
Geçiş teklifini envanter ve pilot kapsamıyla hazırlayın
Kaynak sistem, veri türü, posta kutusu adedi, lisans, geçiş yöntemi, DNS, istemci desteği, güvenlik ve kabul kriterlerini aynı kapsamda değerlendirin.
Birincil ve resmî kaynaklar