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.
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.
Bu yazıda neyi netleştireceğiz?
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.
- Geçiş sadece posta kutusu taşıma değildir; kimlik, cihaz ve güvenlik politikası birlikte ele alınmalıdır.
- MX, SPF, DKIM ve DMARC kayıtları geçiş başarısı için kritik DNS kayıtlarıdır.
- MFA ve yönetici hesap güvenliği geçişin başında tasarlanmalıdır.
- Kullanı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.
1. Geç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.
2. Lisans 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.
3. DNS 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.
4. Pilot 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.
5. Gü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.
6. Geç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.
7. Ne 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
- Kullanıcı ve posta kutusu envanteri çıkarıldı mı?
- MX, SPF, DKIM, DMARC kayıtları planlandı mı?
- Pilot kullanıcı ile test yapıldı mı?
- MFA ve yönetici güvenliği aktif edildi mi?
- Outlook, mobil cihaz ve Teams destek planı hazır mı?
- Geçiş sonrası ilk hafta destek sorumlusu belirlendi mi?
Sık yapılan hatalar
- Tüm kullanıcıları test yapmadan aynı gün taşımak
- PST arşivlerini ve ortak posta kutularını unutmak
- SPF/DKIM/DMARC kayıtlarını geçişten sonra düşünmek
- MFA'yı kullanıcı alışınca açarız diye ertelemek
- Geç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.