Google Workspace’ten Microsoft 365’e geçiş adımları

Google Workspace’ten Microsoft 365’e geçiş adımları

Google Workspace’ten Microsoft 365’e geçişte kaynak izinleri, hedef hesap hazırlığı ve seçilen yöntemin desteklediği veriler birlikte incelenmelidir. Posta, kişi ve takvim kapsamının bulunması bütün dosya ve uygulamaların da taşındığını göstermez. Alan adı, adres eşleştirmesi ve kullanıcı erişimleri geçiş planında açıkça belirtilmelidir. Pilot karşılaştırma, geniş aktarım öncesinde yöntem sınırlarını ve eksik hazırlıkları görünür hale getirir. Uygulama kapsamı için mail taşıma hizmeti sayfasındaki açıklamalar da değerlendirilebilir.

Bu projede kaynak Google Workspace, hedef Microsoft 365 olarak ele alınır. Posta, takvim ve kişi verileri için seçilen yöntemin desteklediği kapsam yazılı hale getirilir; Google’daki bütün uygulamaların kendiliğinden taşındığı varsayılmaz. Şirketin Microsoft 365 ortamı önceden kurulmuş olabilir veya geçiş için eksik hazırlıklar gerekebilir. Teklif, bu mevcut durumu dikkate almalı ve hedef hazırlığını veri aktarımından ayırmalıdır. Böylece satın alınan iş, yalnız araç çalıştırmak yerine sınırları belli bir geçiş ve teslim süreci sunar.

Kullanılacak yöntem ve veri kapsamı aynı belgede belirtilmeli

Microsoft’un Google Workspace geçiş açıklaması, posta, takvim ve kişilerin taşınabildiği bir yöntem tanımlar. Aynı belgede sınırlamalar da bulunur. Ek veya yeni geçiş deneyimleri farklı yetenekler sunabildiğinden hizmet sağlayıcıdan hangi yolun kullanılacağını açıkça yazmasını isteyin. Teklifte araç adıyla veri kapsamı eşleştirilmelidir. Başka bir yöntemin desteklediği özelliği seçilen uygulamanın otomatik parçası gibi sunmak, kullanıcı beklentisini yanlış yönlendirebilir.

Örneğin takvim verisinin taşınabilmesi, bütün paylaşılan takvimlerin ve oda rezervasyonlarının aynı biçimde aktarılacağı anlamına gelmez. Kişi alanları, kurallar ve izin ilişkileri de yönteme göre incelenir. Gereken özellik seçilen yolun dışında kalıyorsa ek uygulama veya manuel düzenleme ayrıca belirtilmelidir. Kaynak ve hedefte aynı işlevin bulunması tek başına aktarımın mümkün olduğunu kanıtlamaz. Kapsam belgesinde dahil öğeler, sınırlar ve ayrı kabul gerektiren işler görülebilmelidir; böylece fiyat ve teslimler birlikte değerlendirilebilir.

Google yönetim erişimi ve API hazırlıkları

Geçiş yöntemine göre kaynak Google ortamında proje, hizmet hesabı ve gerekli API erişimleri hazırlanabilir. Microsoft’un Google Workspace geçiş ön koşulları, kaynak hazırlığıyla hedef kullanıcı hazırlığını birlikte ele alır. Bu işlemleri yapabilecek şirket veya hizmet sağlayıcı sorumlusu belirlenmelidir. Her kullanıcının parolasını toplamak bütün yöntemler için zorunlu bir başlangıç değildir; seçilen güncel bağlantı yolunun gerektirdiği yetki değerlendirilmelidir. Teknik erişim açıklaması teklifin eki olabilir.

Gmail, takvim ve kişi verisine erişim aynı uygulama izninde bir araya gelebilir, ancak istenen kapsamın neden gerekli olduğu anlaşılmalıdır. Şirketin yönetici hesabını paylaşması yerine hangi işlemi yetkili kişinin onaylayacağı planlanabilir. API veya bağlantı hazırlığı tamamlanmadıysa veri aktarımının başlayacağı tarih kesinmiş gibi duyurulmamalıdır. Kaynakta erişim kısıtı görülürse kimin araştıracağı ve hangi onay bekleneceği yazılır. Böylece geçiş aracı çalışmadığında sorumluluk farklı ekipler arasında belirsiz biçimde dolaşmaz.

Yönetici onayı ve hizmet hesabı erişimi kontrol edilir

Google’ın alan genelinde yetki devri açıklaması, uygulamaların kullanıcı verilerine erişimini yönetici tarafından verilen kapsamlarla ilişkilendirir. Bu güçlü yetki, sıradan kullanıcı izniyle aynı şey değildir. Yetkili yönetici hangi istemciye hangi erişimin verildiğini kontrol etmelidir. Kuruluşta ilave onay süreci varsa bu da geçiş hazırlığına dahil edilir. İzin verme işleminin hangi tarihte ve hangi amaçla yapıldığı kaydedilebilir; gerekli olmayan erişimler yalnız kolaylık için eklenmemelidir.

Microsoft’un otomatik EAC geçiş açıklaması, API hazırlığı ve Google yönetici onayıyla ilgili adımlar içerir. Farklı bir Microsoft geçiş deneyimi seçilirse onun güncel izinleri doğrulanır. Hizmet hesabı anahtarı gibi hassas dosyalar açık e-posta grubuna gönderilmemelidir. İş bittikten sonra kullanılmayacak izinlerin kaldırılması ve geçici hesapların durumu kapanışta ele alınır. Erişim iptalinin kalan aktarımı etkilememesi için bu işlem kabul ve son eşitleme koşullarıyla birlikte planlanmalıdır.

Alan adı, kimlik ve hedef kullanıcı eşleştirmesi

Google’daki birincil kullanıcı adresiyle hedef Microsoft 365 adresi aynı olabilir veya şirket kararıyla değişebilir. Her kaynak hesabın hangi hedefe karşılık geldiği onaylı listede gösterilmelidir. Takma adresler ve ortak kullanım adresleri ayrı satırlarla değerlendirilebilir. Şirketin mevcut Microsoft 365 kuruluşu doğrulanmadan yeni ortam açılması veya kullanıcıların gelişigüzel yeniden oluşturulması uygun değildir. Hedef hesap hazırlığı, kullanılan geçiş yönteminin kullanıcı oluşturma ve posta kutusu koşullarına göre yapılmalıdır.

Alan adı doğrulaması ve posta yönlendirmesi, kaynak veriyi okuma yetkisinden farklı işlerdir. DNS erişiminin kimde olduğu, geçici yönlendirme ihtiyacı ve canlı değişiklik sorumlusu belirtilir. Kullanıcıların bir kısmı önce taşınacaksa iki platform arasındaki posta akışı planlanmalıdır. Teklifte yalnız “alan adı taşınır” yazmak bu kapsamı açıklamaz; alan adı kayıt firmasının değişmesi de her projede gerekmez. Şirketin onaylayacağı eşleştirme ve teknik ekibin uygulayacağı yönlendirme birbirini tamamlamalıdır.

Lisans, posta kutusu ve kullanıcı kullanım ihtiyacı

Hedef Microsoft 365 aboneliklerinin taşınacak kullanıcı ve veri için uygunluğu kontrol edilir. Posta kutusu, arşiv, ortak adres ve kullanılacak uygulamalar farklı ihtiyaçlar oluşturabilir. Gmail’deki hacmin hedef kutuya uygunluğu ve gereken özellikler değerlendirilmeden yalnız kullanıcı sayısına göre ürün atanmamalıdır. Lisans satın alma hizmete dahilse bedeli ve koşulları ayrı gösterilir. Mevcut abonelik kullanılacaksa hangi ürünlerin ve kullanıcıların esas alındığı yazılır; taşıma projesi otomatik olarak lisans değişikliği anlamına gelmez.

Çalışanların Outlook, tarayıcı veya telefon üzerinden kullanım beklentisi geçiş desteğinin kapsamını etkiler. Uygulama kurulumu, hesap bağlantısı ve kısa kullanıcı bilgilendirmesinin dahil olup olmadığı belirtilmelidir. Hedefte erişim çalışırken eski cihaz profilinin ayrı düzenleme istemesi mümkündür. Kullanıcı hazırlığı için gereken ekip ve zaman iş planına eklenebilir. Genel ürün seçimi için Microsoft 365 lisans seçimi rehberini inceleyebilirsiniz; bu projenin odağı onaylanan kaynak verinin doğru hedefte teslim edilmesidir.

Drive ve bağlantılı belgeler ayrı bir çalışma alanıdır

Gmail içindeki Drive bağlantısı, dosyanın Microsoft 365 tarafına taşındığını göstermez. E-posta ekiyle paylaşılan dosya bağlantısı farklı veri türleridir. Kullanıcı geçişten sonra eski bağlantıyı açmak için Google hesabına ihtiyaç duyabilir. Drive, ortak sürücüler ve belge izinleri de taşınacaksa hedefin OneDrive veya SharePoint gibi hangi alanı olacağı ayrıca belirlenmelidir. Posta projesinde bu işin dahil olmadığı açıkça yazılabilir; dahilse veri, sahiplik ve izin kabulü ayrı hazırlanmalıdır.

Microsoft farklı geçiş deneyimlerinde ek veri kapsamları sunabilir. Bu durum posta için seçilen yöntemin bütün Drive içeriğini otomatik işlediği anlamına gelmez. Hizmet sağlayıcıdan posta, dosya ve uygulama geçişlerini ayrı teslim başlıklarıyla açıklamasını isteyin. Google hesabının kapatılması, kalan dosya erişimleriyle birlikte değerlendirilmelidir. Şirketin geçmiş yazışmalarındaki bağlantıları ne kadar süre kullanması gerektiği de görüşülebilir. Böylece abonelik sonlandırma kararı, yalnız posta aktarım raporuna dayanarak verilmemiş olur.

Pilot ve kabulde Google’dan Microsoft’a işlev karşılaştırması

Pilot grupta farklı etiket düzeni, büyük posta hacmi ve takvim kullanımı olan çalışanlar bulunabilir. Seçilen yöntemin desteklediği posta, kişi ve takvim örnekleri hedefte incelenir. Kaynak etiketleriyle hedef klasör düzeninin nasıl ele alındığı ve kullanıcıların aradığı öğeye ulaşıp ulaşamadığı kontrol edilir. Varsayımsal olarak iletileri aktarılan bir kullanıcının paylaşılan takvim beklentisi karşılanmamışsa, bunun yöntem sınırı mı yoksa eksik yapılandırma mı olduğu araştırılır. Bu örnek gerçek müşteri vakası değildir.

Kabul kriterleri testten önce yazılmalıdır. Hangi tarih aralıklarının, eklerin, kişi alanlarının ve takvim örneklerinin kontrol edileceği seçilen kapsama göre belirlenir. Kurallar veya başka erişimler ayrıca işlenecekse onların durumu da rapora eklenir. Aktarım raporundaki hata ve atlanan öğeler açıklanmadan genel kabul verilmemelidir. Pilot sonunda devam, düzeltme veya kapsam değişikliği kararı müşteri sorumlusuyla alınabilir. Hizmetin teslimi, yalnız yönetim ekranında tamamlandı yazmasından daha fazla doğrulama içermelidir.

Canlı geçiş, posta akışı ve proje kapanışı

Canlı aşamada yönlendirme değişikliği, son farkların aktarılması ve kullanıcıların hedefe geçmesi koordineli yürütülür. Google’da hangi hizmetlerin açık kalacağı ve yeni postanın hangi ortamda karşılanacağı belli olmalıdır. Dış alım, dış gönderim ve gereken uygulama bildirimleri test edilir. Aktarım sırasında bekleyen işlemler varsa durumu şirket yetkilisine bildirilir. Kaynak hesaptan veri silme veya abonelik kapatma işlemleri, posta geçişinin kendiliğinden yapılan bir adımı olarak düşünülmemelidir.

Kapanışta kullanıcı eşleştirmesi, seçilen veri kapsamı, uygulanan değişiklikler, test sonuçları ve kalan bağımlılıklar teslim edilebilir. Kullanılmayacak geçiş erişimleri gözden geçirilir; devam eden Google veya Microsoft yönetimi ayrı sorumlulukla devredilir. Taşıma sonrası düzeltme dönemi ve yeni taleplerin nasıl ele alınacağı yazılı olmalıdır. İşletim desteği gerekiyorsa Microsoft 365 yönetim hizmeti ayrıca kapsamlandırılabilir. Proje kapanışı, eksik işlerin görünmez hale gelmesi yerine hangi işin kimde kaldığını açıklamalıdır.

Uygulama öncesi son kontroller

Google Workspace Microsoft 365 geçiş fiyatını kullanıcı ve hacim yanında seçilen yöntem, veri türleri, yetkilendirme hazırlığı ve hedef ortamın durumu etkiler. Ek takvim veya izin çalışmaları, Drive projesi, kullanıcı cihazları ve mesai dışı uygulama ayrı iş yükleri oluşturabilir. Araç ve abonelik bedelleri proje hizmetinden ayrı gösterilmelidir. Güncel erişim koşulları görülmeden kesin süre veya veri kaybı olmayacağına dair koşulsuz söz verilmesi yerine kapsam ve testlerin belirlenmesi istenmelidir.

Son kontrol listesinde kaynak izinleri, hedef kullanıcılar, adres eşleştirmesi, veri türleri, pilot ve son eşitleme birlikte yer almalıdır. Tamamlanan kontrolleri ve açık kalan işleri ayrı kaydedin. Sorumluları ve sonraki adımları belirlemek, uygulama sonucunu başlangıçta tanımlanan kapsamla karşılaştırmayı kolaylaştırır.

Teklif için mail taşıma hizmeti sayfasına gidin.

Sık Sorulan Sorular