Google Workspace'ten Microsoft 365'e Geçiş Nasıl Yapılır? (2026)

Xen Bilişim ekibi · Microsoft Bulut Çözüm Ortağı (CSP Direct Partner, 2016'dan beri) · MS-100/MS-102/AZ-104 sertifikalı danışmanlar · 25+ yıl saha deneyimi

Özet (TL;DR): Google Workspace'ten Microsoft 365'e geçiş, Microsoft'un resmi "kesintisiz geçiş (cutover)" metodolojisiyle 9 adımda ve genellikle 3 haftalık bir takvimde tamamlanır: alan adı doğrulama, kullanıcı sağlama, e-posta/takvim/kişi taşıma (Exchange Online göç sihirbazı), Google Drive dosya taşıma (Migration Manager) ve son olarak alan adının Microsoft 365'e bağlanması. Doğru sırayla ilerlenirse kullanıcılar geçiş boyunca hem eski hem yeni posta kutusuna erişebilir, e-posta akışı kesilmez. Bu rehberde her adımı, yaygın hataları, KVKK ve Türkçe karakter tuzaklarını somut biçimde anlatıyoruz.

Neden bu geçiş şimdi gündemde?

2026 içinde hem Google hem Microsoft ticari bulut paketlerinde fiyat güncellemesi yaptı. Microsoft tarafında 1 Temmuz 2026'dan itibaren yürürlüğe giren zam sonrası liste fiyatları önceki yıllara göre daha yakın seviyelere geldi (detaylı SKU bazlı analiz için Microsoft 365 fiyat artışı yazımıza bakabilirsiniz). Fiyat farkı daraldıkça karar artık sadece "hangisi ucuz" sorusuna değil, "hangi ekosistem işimize daha uygun" sorusuna dayanıyor: Office belgeleriyle çalışan, Türkiye'de KVKK ve yerli yazılım (Logo Tiger, Netsis, Mikro Fly gibi) entegrasyonu gereken kurumlar genellikle Microsoft 365'e daha kolay uyum sağlıyor. İki platformu yan yana karşılaştırmak isterseniz Office 365 vs Google Workspace karşılaştırma yazımıza da göz atabilirsiniz.

Bu yazı bir "neden geçmeli" tartışması değil — geçiş kararı verilmiş bir ekip için gerçek Microsoft dokümantasyonuna dayanan, adım adım uygulanabilir bir metodoloji. Kaynak: Microsoft'un resmi "Switch from Google Workspace to Microsoft 365" rehberi (son güncelleme: 30 Haziran 2026) ve Exchange Online'ın Google Workspace göç dokümantasyonu.

İlk 300 kelimede söylenmesi gereken şey şu: bu geçiş kendi başınıza da yapılabilir bir iştir, ama 50 kullanıcı üstü kurumlarda tek seferde doğru yapmak — veri kaybı, sıfır kesinti ve doğru lisanslamayla — uzmanlık ister. Kendi ekibinizle mi yapacaksınız yoksa desteğe mi ihtiyacınız var, ölçmek için ücretsiz geçiş fizibilite analizi alın.

Ön gereksinimler: başlamadan önce netleştirin

Geçişe başlamadan önce dört konuyu netleştirmeniz gerekir:

• Lisans: E-posta + Office uygulamaları + dosya deposu istiyorsanız Microsoft 365 Business Premium (KOBİ, 300 kullanıcıya kadar) veya E3/E5 (kurumsal) uygun paketlerdir. Sadece e-posta taşıyacaksanız Exchange Online Plan 1/2 yeterli olabilir.
• Rol/yetki: Google Workspace tarafında süper yönetici (super admin) veya proje oluşturucu (project creator) rolü; Microsoft 365 tarafında genel yönetici (global admin) rolü gerekir.
• Alan adı (domain) sahipliği: E-posta adreslerinizde kullandığınız alan adının (örn. sirketiniz.com.tr) DNS yönetimine erişiminiz olmalı — TXT/MX kayıtlarını değiştireceksiniz.
• Envanter: Kaç kullanıcı, kaç paylaşımlı Drive (shared drive), kaç grup/e-posta listesi taşınacak — bu sayı, migrasyon adımının kaç "batch" (grup halinde taşıma turu) olarak planlanacağını belirler.

Bu envanteri çıkarmak sandığınızdan uzun sürer; kullanıcıların gerçek posta kutusu boyutları, paylaşılan Drive'ların sahiplik durumu ve kimin hangi grupta olduğu genelde tek bir yerde belgeli değildir. Microsoft 365 danışmanlığı hizmetimiz kapsamında bu envanter çıkarma adımını genelde ilk günde tamamlıyoruz.

Microsoft'un resmi 9 adımlık yol haritası

Microsoft'un resmi geçiş rehberi süreci şu 9 adıma böler:

1. Microsoft 365 for business'a kaydolun.
2. Microsoft 365'i Google Workspace geçişi için kurun (alan adı doğrulama, kullanıcı ekleme, temel cihaz güvenliği).
3. Windows cihazlar için güvenlik politikalarını ayarlayın.
4. Google Workspace alan adınızı Microsoft 365'e ekleyin (doğrulama sonrası eski e-posta adresiyle Microsoft 365'te oturum açılabilir hale gelir).
5. Microsoft 365 uygulamalarını ve Teams'i kurun.
6. Herkesin e-posta ve takvim öğelerini taşıyın (Exchange Online göç turu).
7. Alan adını Microsoft 365'e bağlayın (MX kaydı değişir, e-posta artık Microsoft 365'e düşer).
8. Migration Manager ile Drive'dan OneDrive'a, paylaşımlı Drive'lardan Teams sitelerine dosya taşıyın.
9. Google Workspace'i sonlandırın (alan adını isterseniz Google'da tutabilirsiniz).

Bu 9 adım tek günde bitmez — gerçekçi bir takvim 50-150 kullanıcılık bir kurum için genelde 3 hafta (yaklaşık 21 gün) sürer: ilk hafta kurulum ve test, ikinci hafta e-posta/takvim/kişi taşıma dalgaları, üçüncü hafta dosya taşıma + alan adı kesin geçişi + doğrulama. Küçük ekiplerde (10-20 kullanıcı) bu süre 1 haftaya kadar inebilir; 300+ kullanıcılı kurumlarda 4-6 haftaya çıkabilir.

E-posta, takvim ve kişileri taşıma (Exchange Online göç sihirbazı)

Neden "kesintisiz" (cutover) yöntem tercih edilmeli?

Microsoft üç yöntem sunar: otomatik (Exchange yönetim merkezi sihirbazı), manuel (yine yönetim merkezinden ama adımlar elle) ve PowerShell komut satırı. Çoğu KOBİ ve orta ölçekli kurum için otomatik yöntem önerilir çünkü Google tarafındaki API yetkilendirmesini sihirbaz kendisi yürütür, elle API etkinleştirme adımı gerekmez.

Adım adım: otomatik göç turu (batch) oluşturma

1. Exchange yönetim merkezinde (admin.exchange.microsoft.com) Migration bölümüne girin, Add migration batch (Göç turu ekle) seçin ve turunuza benzersiz bir isim verin.
2. Göç yolu olarak Migration to Exchange Online'ı, göç türü olarak Google Workspace (Gmail) migration'ı seçin.
3. Açılan "ön koşullar" ekranında Start'a basarak Google tarafındaki 4 zorunlu ön koşulu (API etkinleştirme, servis hesabı yetkilendirme vb.) otomatik olarak çalıştırın. Bu adım sizi Google oturum açma ekranına yönlendirir; Google süper yöneticinizle giriş yapmanız gerekir.
4. Doğrulama tamamlanınca bir JSON anahtar dosyası (projectid-*.json) bilgisayarınıza iner — bu dosyayı silmeyin, bir sonraki adımda kullanılacak.
5. Verilen bağlantıdan Google Admin API kontrollerine gidip Client ID ve kapsam (scope) bilgisini yapıştırıp yetkilendirin.
6. "Migration endpoint" (göç bağlantı noktası) oluşturun: Gmail oturum açma e-postanızı girin, az önce indirdiğiniz JSON anahtarını içe aktarın. Varsayılan olarak aynı anda en fazla 20 posta kutusu ve 10 artımlı senkronizasyon taşınır — küçük kurumlarda bu değerleri değiştirmenize gerek yoktur.
7. Taşınacak kullanıcıların e-posta adreslerini içeren bir CSV dosyası yükleyin (tek zorunlu sütun: EmailAddress).
8. Hedef teslimat alt alan adını (bir sonraki bölümde anlatılan geçici alt alan adı) seçin; Posta/Takvim/Kişi/Kurallar filtrelerinden hangilerinin taşınacağını işaretleyin.
9. Turu kaydedin ve başlatın. Durum Syncing'den Synced'e geçince tur "tamamlanmaya hazır" demektir; bu noktada elle "complete" (tamamla) adımı çalıştırılır ve kullanıcı posta kutusu artık Microsoft 365'te birincil hale gelir.

Google'ın kendi kısıtlamaları var: en büyük tek e-posta boyutu varsayılan 35 MB, paylaşılan takvimler ve etkinlik renkleri taşınmaz, kişilerde en fazla 3 e-posta adresi aktarılır, oda rezervasyonları (meeting room bookings) taşınmaz. Bu kısıtları kullanıcılara geçiş öncesi bildirin — "e-postam kayboldu" şikayetlerinin büyük kısmı aslında bu bilinen sınırlardan kaynaklanır.

Google Drive'dan OneDrive/SharePoint'e dosya taşıma

E-posta taşındıktan sonra sıradaki büyük iş dosyalardır. Microsoft bunun için ücretsiz, yerleşik bir araç sunuyor: Migration Manager (Microsoft 365 yönetim merkezi > Kurulum > Geçişler ve içe aktarmalar). Standart akış 6 adımdan oluşur:

1. Google'a bağlanın: Google Workspace Marketplace'ten "Microsoft 365 migration" uygulamasını süper yönetici hesabıyla kurun, alan geneli (domain-wide) yetkilendirin.
2. Tara ve değerlendir: Taşınacak Drive'ları taramaya ekleyin; tarama bitince olası engelleri (çok büyük dosya, desteklenmeyen format) gösteren raporu indirip inceleyin.
3. Göç listesine kopyala: "Taşımaya hazır" durumuna geçen Drive'ları göç listenize ekleyin.
4. Hedef yolları gözden geçirin: Kaynak klasör yapısı otomatik olarak eşleşen hedef yollara haritalanır; yanlış eşleşen yerleri elle düzeltin.
5. Kimlikleri eşleştirin: Google tarafındaki alan adları, gruplar ve kullanıcıları Microsoft 365'teki karşılıklarıyla eşleyin — bu adım atlanırsa dosya izinleri (kimin görebileceği) doğru taşınmaz.
6. Taşı ve izle: Göçü başlatın, ilerleme panelinden takip edin.

Microsoft, 300 lisanstan az kullanıcısı olan kurumlar için bu akışı otomatik olarak sadeleştiren "Migration Manager Lite" sürümünü sunuyor: tarama/eşleştirme adımları arka planda otomatik yürür, yönetici sadece görevleri seçer, hedefleri onaylar ve kimlikleri eşler. Çoğu KOBİ için pratikte bu, işi yarı yarıya kısaltır.

Alan adını Microsoft 365'e bağlama — en kritik an

E-posta ve dosyalar taşındıktan sonra son adım alan adının MX kaydını Google'dan Microsoft 365'e çevirmektir. Bu andan itibaren yeni gelen e-postalar Microsoft 365'e düşer. Pratikte önerilen yöntem, geçiş boyunca iki geçici alt alan adı kullanmaktır (biri Microsoft 365'e, biri Google'a giden postayı yönlendirmek için) — böylece geçiş penceresinde iki tarafa da e-posta ulaşır, kimse posta kaybetmez. MX kaydı değişikliği genelde DNS sağlayıcınıza göre 15 dakika ile birkaç saat arasında yayılır (propagate). Değişiklik öncesi TTL (kayıt yaşam süresi) değerini düşürmek yayılmayı hızlandırır.

Doğrulama ve test adımları

Turu "tamamlandı" ilan etmeden önce şu kontrol listesini uygulayın:

• 3-5 pilot kullanıcıyla e-posta gönder/al testi (hem iç hem dış alıcıya).
• Takvim davetlerinin doğru saatte ve doğru katılımcı listesiyle geldiğini kontrol edin (saat dilimi hataları sık görülür).
• Mobil cihazlarda (Outlook mobil veya yerleşik posta uygulaması) yeni hesabın doğru yapılandırıldığını doğrulayın.
• Paylaşımlı Drive'lardan taşınan dosyalarda izinlerin (kim görebiliyor, kim düzenleyebiliyor) kaynaktakiyle aynı olduğunu örnekleyerek kontrol edin.
• DKIM/SPF/DMARC kayıtlarının yeni gönderim altyapısına göre güncellendiğini doğrulayın — aksi halde gönderdiğiniz postalar spam'e düşebilir.
• MX kaydı değişikliği sonrası dig MX sirketiniz.com.tr ile kaydın gerçekten Microsoft 365'i gösterdiğini teyit edin.

Yaygın hatalar ve nasıl önlenir

• "Veri kayboldu" yanılgısı: Kurumunuzda mesaj kayıt yönetimi (MRM) veya otomatik arşivleme politikaları varsa, bu politikalarca silinmiş/arşivlenmiş öğeler göç raporunda "eksik" (missing) görünür. Bu gerçek bir veri kaybı değildir — göç aracının bu politikalardan haberi olmamasından kaynaklanır. Microsoft, göçe başlamadan önce tüm MRM/arşiv politikalarını geçici olarak kapatmanızı önerir.
• Büyük e-postaların takılması: Varsayılan 35 MB sınırını aşan ekler taşınmaz; sınırı artırmak için taşıma (transport) yapılandırmasında değişiklik gerekir.
• Kimlik eşleştirmeyi atlamak: Dosya göçünde "kimlikleri eşleştir" adımı atlanırsa paylaşım izinleri kaybolur veya yanlış kişilere düşer — bu adımı asla atlamayın.
• Oturum zaman aşımı: Migration Manager'da Google'a bağlanma adımının 10 dakikalık bir oturum süresi vardır; hazırlıksız başlarsanız (JSON dosyasını, yönetici şifresini önceden hazır etmemişseniz) oturum düşer ve baştan başlamanız gerekir.
• Toplu gönderim planlamak: Geçiş haftasında kampanya e-postası, toplu fatura gönderimi gibi yüksek hacimli işleri planlamayın — yeni gönderim altyapısının itibarı (reputation) henüz oturmamıştır.

TR-özel katman: KVKK ve veri konumu

Kişisel Verilerin Korunması Kanunu (KVKK) 6698 sayılı kanunun 12. maddesi, veri sorumlusuna kişisel verinin güvenliği için "gerekli teknik tedbirleri" alma yükümlülüğü getirir. Google Workspace'ten Microsoft 365'e geçerken bu, sadece "veri taşındı mı" sorusu değil, "veri nerede saklanıyor ve kim erişebiliyor" sorusudur. Geçiş sırasında:

• Microsoft 365 kiracınızın veri merkezi bölgesini (data residency) Microsoft 365 yönetim merkezinden teyit edin — Avrupa Birliği veri sınırı (EU Data Boundary) kapsamındaki müşteriler için veri AB içinde tutulabiliyor; kesin kapsam sözleşmenize ve seçtiğiniz plana göre değişir, bu yüzden sözleşme ekini mutlaka kontrol edin.
• Geçiş sırasında oluşturduğunuz geçici Google API anahtarlarını (JSON dosyası) göç bitince güvenli şekilde silin veya erişimi kısıtlayın — bu anahtarlar hassas erişim izni taşır.
• VERBİS'e (Veri Sorumluları Sicil Bilgi Sistemi) kayıtlı veri işleme envanterinizi, e-posta/dosya barındırma sağlayıcısı değişikliğini yansıtacak şekilde güncelleyin.

Veri sınıflandırma, sızıntı önleme ve erişim denetimi gibi konularda kiracınızı geçiş sonrası nasıl sıkılaştıracağınızı Microsoft güvenlik çözümlerimiz sayfasında detaylandırdık.

TR-özel katman: Türkçe karakter ve kullanıcı adı tuzakları

Google Workspace'te kullanıcı adları ve dosya adlarında Türkçe karaktere (ç, ğ, ı, ö, ş, ü) genelde göz yumulur; Microsoft 365 tarafında ise bazı bileşenler (özellikle eski SharePoint söz dizimi ve bazı senkronizasyon istemcileri) bu karakterlerle sorun çıkarabilir. Sık karşılaşılan üç tuzak:

• Kullanıcı asıl adı (UPN): Microsoft 365'te oturum açma adı olarak kullanılan UPN alanı Türkçe karakter kabul etmez; "Öztürk" soyadı UPN'de "Ozturk" olarak ASCII'ye çevrilmeli, ama görünen ad (display name) alanında "Öztürk" olarak kalabilir.
• Klasör/dosya adları: Google Drive'da "Muhasebe İşleri" gibi Türkçe karakterli bir klasör adı OneDrive/SharePoint'e taşınırken senkronizasyon istemcisinde ara sıra görüntüleme sorunu yaşanabilir; taşıma sonrası bu tip klasörleri örnekleyerek kontrol edin.
• E-posta takma adları (alias): "[email protected]" gibi Türkçe karakter içermeyen takma adlar sorunsuz taşınır, ancak "İnsan Kaynakları" gibi grup görünen adları taşıma sonrası elle düzeltilmesi gerekebilir.

Bu iki katman (KVKK + Türkçe karakter) çoğu genel geçiş rehberinde hiç geçmez, çünkü onlar global pazar için yazılır — ama Türkiye'de saha tecrübesi olan bir ekiple çalışmanın asıl farkı burada ortaya çıkar.

Saha vakası: 60 kişilik bir mühendislik bürosunun 18 günlük geçişi

Firma X — 60 kişilik bir mühendislik/proje yönetim bürosu — 6 yıldır Google Workspace kullanıyordu; e-posta, paylaşımlı Drive'larda proje dosyaları ve Google Takvim üzerinden saha ziyareti planlaması vardı. Karar noktaları şunlardı: (1) Office belgeleriyle çalışan müşteri/kamu kurumu iletişiminde dosya format uyumsuzluğu sık şikayet konusuydu, (2) Logo Tiger muhasebe yazılımına e-posta/dosya entegrasyonu Google tarafında elle yapılıyordu, (3) KVKK denetimi öncesi veri konumu netliği isteniyordu.

Süre: 18 gün. İlk 4 gün envanter + alt alan adı + pilot grup kurulumu, sonraki 8 gün 4 dalga halinde e-posta/takvim/kişi taşıma (her dalga ~15 kullanıcı), son 6 gün paylaşımlı Drive'ların (toplam ~1,2 TB) Migration Manager ile taşınması ve alan adı geçişi. Sonuç: geçiş penceresinde bildirilen e-posta kaybı sıfır; en büyük sürtünme noktası saha ekibinin mobil cihazlarında yeni hesabın manuel yapılandırılması oldu (bu adım sonraki projelerde Intune ile otomatikleştirildi).

Xen ekibinin rolü: envanter çıkarma, göç turu planlaması, KVKK veri konumu teyidi ve Logo Tiger entegrasyon testleri. Uyarı: paylaşımlı Drive büyüklüğü 1 TB'ı geçen kurumlarda dosya taşıma adımı en az bir hafta ekstra süre gerektirir — bunu takvime baştan koyun.

Sıkça Sorulan Sorular (SSS)

Google Workspace'ten Microsoft 365'e geçiş ortalama kaç günde tamamlanır?

10-20 kullanıcılık küçük ekiplerde 5-7 gün, 50-150 kullanıcılık orta ölçekli kurumlarda genelde 3 hafta (21 gün), 300+ kullanıcılı kurumlarda 4-6 hafta sürer. Süreyi belirleyen en büyük değişken paylaşımlı Drive'ların toplam veri boyutudur.

Geçiş sırasında e-postalarım kaybolur mu, ne kadar kesinti yaşarım?

Doğru planlanmış bir kesintisiz (cutover) göçte kesinti yaşanmaz — geçici alt alan adları sayesinde geçiş penceresinde her iki sisteme de e-posta ulaşır. "Kayıp" olarak görünen öğelerin büyük kısmı aslında MRM/arşiv politikalarınca daha önce silinmiş/arşivlenmiş içeriktir, gerçek veri kaybı değildir.

Google Drive'daki dosyalar ve paylaşım izinleri Microsoft 365'e aynen taşınır mı?

Migration Manager'da "kimlikleri eşleştir" adımı doğru yapıldıysa evet, dosya izinleri (kimin görüp düzenleyebileceği) korunur. Bu adım atlanır veya yanlış yapılırsa izinler kaybolur veya yanlış kişilere düşebilir — bu yüzden bu adım göçün en kritik noktasıdır.

Hangi Microsoft 365 paketini (lisansı) almam gerekiyor?

E-posta + Office masaüstü/web uygulamaları + OneDrive/SharePoint istiyorsanız 300 kullanıcıya kadar Business Premium, daha büyük kurumlarda E3 veya E5 (ek güvenlik/uyumluluk özellikleri gerekiyorsa) uygun paketlerdir. Sadece e-posta taşıyacaksanız Exchange Online Plan 1/2 yeterlidir. Doğru paketi seçmek toplam maliyeti önemli ölçüde etkiler; lisans envanteri çıkaralım.

Geçişi kendi ekibimizle mi yapmalıyız yoksa uzman desteği mi almalıyız?

10-15 kullanıcıya kadar teknik bilgisi olan bir yönetici Microsoft'un otomatik sihirbazıyla süreci kendi başına yürütebilir. Daha büyük kurumlarda, birden fazla dalga planlaması, KVKK veri konumu teyidi ve yerli yazılım (Logo Tiger, Netsis, Mikro Fly) entegrasyonu gerektiğinde uzman desteği süreci hem hızlandırır hem risk azaltır. WhatsApp'tan yazarak ekibinizin büyüklüğüne göre ön değerlendirme alabilirsiniz.

Fiyatlar artık birbirine yakınsa geçişin maliyeti neye göre hesaplanır?

Lisans farkı daraldığı için asıl maliyet kalemi artık geçiş projesinin kendisi: envanter çıkarma, göç turlarının planlanması, dosya taşıma süresi ve kullanıcı eğitimi. Sabit fiyatlı bir geçiş paketiyle çalışmak, projenin kaç haftaya yayılacağını ve kur dalgalanmasından etkilenmeyeceğini baştan netleştirir.

Geçiş sonrası Google Workspace'i ne zaman ve nasıl kapatmalıyım?

Tüm posta kutuları, takvimler, kişiler ve dosyalar taşınıp doğrulandıktan, alan adı MX kaydı Microsoft 365'e tam geçtikten ve en az 1-2 hafta sorunsuz kullanım gözlemlendikten sonra Google Workspace aboneliğini sonlandırabilirsiniz. Alan adınızı Google'da DNS yönetimi için tutmaya devam edebilir veya başka bir sağlayıcıya taşıyabilirsiniz.

Sonuç: Doğru sırayla ilerleyen bir geçiş, kesintisiz olur

Google Workspace'ten Microsoft 365'e geçiş, Microsoft'un kendi 9 adımlık metodolojisi izlendiğinde ve geçici alt alan adı stratejisiyle e-posta akışı korunduğunda, kullanıcıların günlük işini kesintiye uğratmadan tamamlanabilecek bir projedir. Asıl risk teknik zorluktan değil, atlanan adımlardan doğar: kimlik eşleştirmeyi atlamak, MRM politikalarını kapatmadan başlamak, ya da paylaşımlı Drive büyüklüğünü hafife almak.

Türkiye'de faaliyet gösteren bir kurum için bu listeye iki madde daha eklenir: KVKK kapsamında veri konumu teyidi ve Türkçe karakter/UPN uyumu. Bu ikisi atlandığında geçiş "teknik olarak başarılı" görünse de denetim veya kullanıcı memnuniyeti açısından sorun çıkarabilir.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Google Workspace'ten Microsoft 365'e geçiş yolculuğunda envanter çıkarmadan alan adı geçişine, KVKK veri konumu teyidinden kullanıcı eğitimine kadar uçtan uca destek sağlıyoruz. Microsoft 365 çözümlerimizi inceleyin veya iletişim sayfamızdan bize ulaşın; TL faturayla CSP paketimizi görün, kur farkını biz üstlenelim.