Rehber · Microsoft
KOBİ’ler İçin Microsoft 365 Geçiş Rehberi: E-Posta, Kimlik, Güvenlik ve Kullanıcı Hazırlığı
Microsoft 365 geçişinde e-posta taşıma, DNS, MFA, kullanıcı politikaları, OneDrive/Teams ve geçiş sonrası destek için uygulanabilir kontrol listesi.
Yayın · İyi Bilişim
Kısa cevap
Microsoft 365 geçişinde doğru sıra; mevcut e-posta ve kullanıcı envanterini çıkarmak, DNS ve alan adı kayıtlarını hazırlamak, güvenlik politikalarını belirlemek, pilot geçiş yapmak, tüm kullanıcıları taşımak ve geçiş sonrası Outlook/Teams/OneDrive desteğini planlamaktır.
Microsoft 365'e geçmek isteyen ama e-posta kesintisi, kullanıcı karmaşası ve güvenlik ayarları konusunda risk almak istemeyen işletmeler için hazırlanmıştır.
- OKGeçiş sadece posta kutusu taşıma değildir; kimlik, cihaz ve güvenlik politikası birlikte ele alınmalıdır.
- OKMX, SPF, DKIM ve DMARC kayıtları geçiş başarısı için kritik DNS kayıtlarıdır.
- OKMFA ve yönetici hesap güvenliği geçişin başında tasarlanmalıdır.
- OKKullanıcı eğitim ve ilk hafta destek planı yapılmazsa teknik geçiş başarılı olsa bile operasyon aksayabilir.
Microsoft 365 geçişinde e-posta taşıma, DNS, MFA, kullanıcı politikaları, OneDrive/Teams ve geçiş sonrası destek için uygulanabilir kontrol listesi.
01Geçişten önce mevcut durumu belgeleyin
İlk adım mevcut e-posta sisteminin, kullanıcı hesaplarının, posta kutusu boyutlarının, ortak posta kutularının, dağıtım listelerinin, arşiv ihtiyaçlarının ve mobil cihaz erişimlerinin belgelenmesidir. Bu çalışma yapılmadan doğrudan taşıma başlatmak, geçiş sırasında hangi kullanıcının hangi veriye ihtiyaç duyduğunu belirsiz hale getirir. Özellikle eski POP/IMAP kullanımları, lokal PST arşivleri, paylaşımlı posta kutuları ve departman adresleri önceden belirlenmelidir.
02Lisans seçimini sadece fiyata göre yapmayın
Microsoft 365 lisansı seçilirken yalnızca posta kutusu kapasitesine bakmak yeterli değildir. MFA, koşullu erişim, cihaz yönetimi, arşiv, DLP, Teams telefonisi, OneDrive alanı ve güvenlik raporları gibi gereksinimler lisans seçimini etkiler. Küçük işletmelerde bile yönetici hesaplarının korunması ve kullanıcıların veri paylaşım politikalarının belirlenmesi uzun vadede ciddi fark yaratır.
03DNS ve alan adı kayıtlarını önceden hazırlayın
Geçişin en hassas kısmı DNS tarafıdır. MX kaydı e-posta trafiğinin nereye gideceğini belirler; SPF gönderen sunucu doğrulaması için kullanılır; DKIM e-postanın imzasını güçlendirir; DMARC ise alan adınız üzerinden sahte e-posta gönderimini azaltmaya yardımcı olur. Bu kayıtlar doğru planlanmadan yapılan geçişlerde e-posta teslim sorunları, spam klasörüne düşme ve dış gönderim problemleri oluşabilir.
04Pilot kullanıcıyla geçişi test edin
Tüm kullanıcıları tek seferde taşımak yerine pilot kullanıcı veya küçük bir departmanla test yapmak daha güvenlidir. Pilot aşamada Outlook profili, mobil cihaz kurulumu, Teams toplantıları, OneDrive senkronizasyonu, paylaşımlı posta kutuları ve dış e-posta akışı test edilir. Bu testler geçiş günü karşılaşılabilecek problemleri önceden görünür hale getirir.
05Güvenlik politikalarını geçişin sonunda değil başında kurun
Microsoft 365 ortamında MFA, yönetici hesap ayrımı, parola politikaları, dış paylaşım sınırları, kullanıcı rolleri ve e-posta güvenlik ayarları geçişin parçası olmalıdır. Güvenlik ayarlarını sonra yaparız yaklaşımı, özellikle yeni kurulan tenantlarda gereksiz açıklar oluşturabilir. Yönetici hesaplarında ayrı ve güçlü kimlik doğrulama uygulanmalıdır.
06Geçiş sonrası ilk hafta destek planı yapın
Teknik taşıma tamamlandıktan sonra kullanıcıların Outlook profili, mobil posta kurulumu, imza ayarları, Teams kullanımı ve OneDrive senkronizasyonu için destek ihtiyacı doğar. Bu süreç planlanmazsa kullanıcı tarafında verimlilik kaybı yaşanır. İyi bir geçiş projesi, sadece sunucu tarafını değil kullanıcı deneyimini de kapsar.
07Ne zaman profesyonel destek gerekir?
Kullanıcı sayısı artmışsa, eski posta sistemi karmaşıksa, departman posta kutuları varsa, KVKK/veri güvenliği hassasiyeti bulunuyorsa veya kesinti kabul edilemiyorsa profesyonel geçiş desteği alınmalıdır. Böyle durumlarda planlı geçiş takvimi, rollback senaryosu ve kullanıcı iletişimi projenin başarısını belirler.
Uygulama kontrol listesi
- OKKullanıcı ve posta kutusu envanteri çıkarıldı mı?
- OKMX, SPF, DKIM, DMARC kayıtları planlandı mı?
- OKPilot kullanıcı ile test yapıldı mı?
- OKMFA ve yönetici güvenliği aktif edildi mi?
- OKOutlook, mobil cihaz ve Teams destek planı hazır mı?
- OKGeçiş sonrası ilk hafta destek sorumlusu belirlendi mi?
Sık yapılan hatalar
- WARNTüm kullanıcıları test yapmadan aynı gün taşımak
- WARNPST arşivlerini ve ortak posta kutularını unutmak
- WARNSPF/DKIM/DMARC kayıtlarını geçişten sonra düşünmek
- WARNMFA'yı kullanıcı alışınca açarız diye ertelemek
- WARNGeçiş sonrası kullanıcı desteği planlamamak
Sık sorulan sorular
Microsoft 365 geçişi kaç gün sürer?
Kullanıcı sayısı, posta kutusu boyutu ve mevcut sistemin durumuna göre değişir. Küçük yapılarda birkaç gün, daha karmaşık yapılarda planlama ve geçiş süreci daha uzun sürebilir.
E-posta kesintisi yaşanır mı?
Doğru DNS planı, pilot test ve bakım penceresiyle kesinti minimuma indirilebilir. Tamamen sıfır risk demek doğru değildir; bu yüzden geçiş planı önemlidir.
Microsoft 365 geçişinde en sık hata nedir?
En sık hata e-posta taşımasını tek başına proje sanmaktır. Kimlik, güvenlik, DNS, cihaz ve kullanıcı desteği birlikte planlanmalıdır.