Mail taşıma nasıl yapılır? Kontrol listesi
Mail taşıma planında kaynak sağlayıcı, hedef ortam ve taşınacak veri türleri birlikte açıklanmalıdır. İleti klasörleri, yerel arşivler, kişiler ve takvimler aynı aktarım yönteminin kapsamına girmeyebilir. Kullanıcıların yeni ortamda hangi işlemleri yapacağı ve kaynak sistemin ne zaman kapatılacağı da veri kopyalama işinden ayrı değerlendirilir. Kabul listesi hem örnek veriyi hem günlük kullanım senaryolarını göstermelidir. Uygulama kapsamı için mail taşıma hizmeti sayfasındaki açıklamalar da değerlendirilebilir.
Kurumsal mail taşıma ihtiyacı sağlayıcı değişiminden, hesapların tek ortamda toplanmasından veya şirketin yeni bir platform kullanmak istemesinden doğabilir. Her geçişin kaynak ve hedef koşulları farklıdır. Bu nedenle yalnız kullanıcı adedine bakılarak verilen paketlerin kapsamı ayrıca incelenmelidir. Satın alma aşamasında beklenen sonuç; dosyaların kopyalandığının söylenmesinden çok, onaylanan verinin ve kullanım senaryolarının hangi kontrollerle teslim edileceğinin anlaşılmasıdır. Eksik bilgiler ilk incelemede belirlenebilir; bütün teknik ayrıntıları önceden bilmeniz beklenmez.
Kaynak ve hedef belirsizken teklif karşılaştırılamaz
Kaynak sistemin adı, hedef platform ve hizmeti değiştirme nedeni ilk görüşmenin temelidir. Şirket adına açılmış bütün adresler aynı sağlayıcıda bulunmayabilir. Bazı kullanıcılar yalnız tarayıcıyla çalışırken bazıları bilgisayarında ayrı arşiv tutuyor olabilir. Alan adının kayıt edildiği firma da posta sağlayıcısından farklı olabilir. Bu ilişkiler açıklanmadan yapılacak aktarımın iş yükü ve gerekli erişimleri doğru hesaplanamaz. Teknik ekipten mevcut durumu özetleyen anlaşılır bir varlık listesi isteyebilirsiniz.
Hedef platform seçilmişse hangi ihtiyaçlara cevap vermesinin beklendiği belirtilmelidir. Henüz karar verilmemişse seçenek incelemesiyle veri taşıma uygulaması teklif içinde ayrı açıklanabilir. Bir sağlayıcının kendi barındırma hizmetini önermesi, başka hedefe taşıma yapabileceği anlamına gelmez; kapsam sorulmalıdır. Alan adı transferi, yeni abonelik alımı ve mevcut ileti verisinin aktarılması farklı işlemlerdir. Hangilerinin yapılacağı yazıldığında, sonradan beklenmeyen kayıt veya abonelik giderleriyle karşılaşma ihtimali azaltılabilir.
Veri türü matrisiyle neyin taşınacağını belirleyin
İletiler, klasörler, kişiler, takvimler ve yerel arşivler tek bir veri türü değildir. Ortak adresler, yönlendirmeler ve gruplar ise çoğu zaman veri kopyalamaktan çok hedefte kurulacak bir çalışma düzenidir. Teklifte her veri türü için kaynak, hedef ve uygulanacak işlem gösterilebilir. Örneğin sunucudaki ileti klasörleri aktarılırken çalışan bilgisayarındaki dosya arşivinin ayrıca incelenmesi gerekebilir. Bir klasörün adı görünüyorsa içindeki bütün öğelerin doğru aktarıldığı otomatik kabul edilmemelidir.
Microsoft’un e-posta geçiş yöntemleri açıklaması, kaynak ve yönteme göre farklı seçenekler bulunduğunu gösterir. Aynı kaynağın IMAP bölümünde yalnız ileti klasörlerinin kapsamda olduğu, takvim ve kişilerin aynı yöntemle taşınmadığı açıklanır. Bu teknik ayrım, bütün teklifleri aynıymış gibi karşılaştırmamak için önemlidir. Hizmet satın alırken “bütün mailler” ifadesinin neyi içerdiğini sorun; dışarıda kalan veri ve işlevler teklif ekinde açıkça belirtilmelidir.
Erişim yetkisi ve müşteri sorumlulukları nasıl yazılır?
Kaynak kutulara ve hedef yönetimine yetkili erişim olmadan bazı işlemler yapılamaz. Erişim başka bir sağlayıcıdaysa devir talebini kimin ileteceği ve ne zaman tamamlayacağı belirlenmelidir. Teknik ekibin iş yapma yetkisiyle şirketin veri aktarımına onay verme sorumluluğu farklıdır. Kullanıcı listesini onaylayacak kişi, DNS değişikliğine izin verecek kişi ve kabulü gerçekleştirecek bölüm sorumluları başlangıçta belirlenebilir. Eksik müşteri onayı beklenen işlerin takvimde nasıl gösterileceği de açıklanmalıdır.
Hassas erişim bilgilerinin paylaşımı uygulama aşamasında uygun yöntemle düzenlenir. Parolaların herkese açık bir dosyaya yazılması veya şirket içindeki geniş bir e-posta grubuna gönderilmesi gerekmez. Hangi hesabın hangi amaçla kullanılacağı ve iş sonunda erişimin nasıl kaldırılacağı belirlenebilir. Kullanıcılardan işlem yapmaları bekleniyorsa talimatı kimin vereceği ve destek gerektiğinde kime ulaşılacağı yazılmalıdır. Böylece proje, teknik ekibin beklemediği erişim engelleriyle karşılaştığında sorumluluk belirsizliğine düşmez.
Başlangıç ve devam kararını koşullara bağlayın
Taşıma işine başlamadan kaynak erişiminin çalışması, hedef hesapların hazır olması ve kullanıcı listesinin onaylanması gibi koşullar doğrulanabilir. Pilot aktarım sonrasında belirlenen kontroller tamamlanmadan genel geçişe başlanmaması kararlaştırılabilir. Bu kontrol noktaları, belirli bir takvim gününe koşulsuz bağlı kalmaktan daha yararlıdır. Kaynak sistemde eksik veri, hedefte kapasite sorunu veya uygulama bağımlılığı görülürse bunların hangi kararı durduracağı yazılmalıdır. Kontrolün sonucu müşteriye anlaşılır biçimde bildirilmelidir.
Örneğin varsayımsal bir işletmede ortak adresi kullanan bölümün gönderim testi başarısızsa, ilgili bölümün geçişi ertelenebilir. Bu bir gerçek müşteri sonucu değil, karar koşulunu açıklayan senaryodur. Teklifin yalnız aktarım aracını çalıştırmayı değil, böyle bir bulguyu incelemeyi içerip içermediğini sorun. Müşteri ek incelemeye onay vermiyorsa kapsamın nasıl daralacağı ve kabulün neye göre yapılacağı belirtilmelidir. Eksikler görünmez kılınarak tamamlandı raporu oluşturulmamalıdır.
Kullanıcı geçişi ve yeni posta akışı ayrı yönetilir
Geçmiş iletilerin hedefe kopyalanması, yeni gelen e-postanın doğru sisteme yönlendiği anlamına gelmez. Posta yönlendirmesi, kullanıcı cihazları ve varsa uygulama gönderimleri koordineli değerlendirilmelidir. Değişiklik zamanında hangi ekibin hazır bulunacağı ve çalışanların hangi sistemi kullanacağı açıklanabilir. Kullanıcıların aynı anda iki ortamda işlem yapması veri farkları oluşturabilir; bu durumun izlenmesi ve son farkların kontrolü teklifin parçası olmalıdır. Planlanan saat ile kesin tamamlanma süresi birbirine karıştırılmamalıdır.
Microsoft hedefli projelerde alan adı ekleme belgesi, e-posta yönlendirmesinden önce ilgili kullanıcı ve posta kutularının hazırlanması gerektiğini belirtir. Başka hedeflerde de uygulanacak üretici koşulları ayrıca kontrol edilir. DNS değişikliği sırasında web sitesi veya başka gönderim hizmetlerinin kayıtlarına gereksiz müdahale edilmemelidir. Değişecek değerler, mevcut değerler ve işlem sonrası kontroller kayda alınabilir. Kullanıcı bilgilendirmesi teknik uygulamadan ayrı düşünülmemelidir.
Kabul edilen kapsam hangi kanıtla teslim edilir?
Bir aktarım raporunda başarılı yazması işletmenin bütün beklentilerinin karşılandığını tek başına göstermez. Örnek kutularda eski ve yeni tarihli iletiler, klasörler, ekler ve kapsamda bulunan diğer öğeler incelenebilir. Dış alım, dış gönderim ve gerekli ortak adres kullanımı da denenir. Örnekleme yöntemi, seçilen kutular ve kontrol eden müşteri sorumlusu teslim belgesinde bulunabilir. Hata raporlarında yer alan atlanan öğelerin nasıl değerlendirildiği ayrıca açıklanmalıdır.
Kaynak ve hedefin aynı toplam sayıyı göstermemesi her durumda aynı nedenden kaynaklanmaz. Kapsam dışı klasör, farklı görüntüleme veya aktarım hatası gibi ihtimaller araştırılır. İşin kabulünde sayıların yanında veri türü ve kullanım testi birlikte değerlendirilmelidir. Giderilmeyen bir bulgu varsa etkisi, kapsamı ve sonraki adımı yazılır. Sağlayıcıdan yalnız ekran görüntüsü yerine onaylanan kapsamla karşılaştırılabilen bir teslim özeti istemek, proje sonucunu daha anlaşılır hale getirir.
Eski sağlayıcıdan devir ve hizmetin kapatılması
Eski sağlayıcıyla sözleşmenin bitiş tarihi, kaynak sistemin açık kalacağı süre ve kullanıcıların eski verilere erişimi ayrı ele alınmalıdır. Kaynak hizmeti erken kapatmak, eksik kalan öğelerin kontrolünü zorlaştırabilir. Hangi tarihte hangi erişimin sona ereceğine şirketin yetkili kişisi karar vermelidir. Bağımsız yedekleme isteniyorsa kapsamı ayrıca belirlenir; geçiş sırasında kullanılan kopyanın uzun süreli geri yükleme hizmeti olduğu varsayılmamalıdır. Saklanacak çıktıların sorumlusu da yazılmalıdır.
Devir paketinde onaylanan kullanıcı listesi, yönlendirme ve ortak adres kayıtları, değişiklik özeti, aktarım sonuçları ve açık iş listesi bulunabilir. Şirketin kendi sistemlerini başka ekibe devredebilmesi için gerekli bilgilerin açıklanması önemlidir. Hizmet sağlayıcının özel işlem araçlarını teslim etmesiyle şirketin yönetim ve veri bilgilerini devretmesi aynı konu değildir. Erişimlerin kontrolü, geçici hesapların durumu ve sonraki destek kanalı kapanış toplantısında netleştirilebilir. Bu çıktıları satın alma aşamasında istemek sonradan belirsizlik yaşanmasını azaltır.
Ön inceleme sonucu teklif nasıl kesinleşir?
Ön görüşmede paylaşılan kutu sayısı ve veri hacmi yaklaşık olabilir. Teknik incelemede farklı bir durum görülürse sağlayıcının güncellenmiş kapsamı açıklaması gerekir. Örneğin sunucuda bulunmadığı düşünülen yerel arşivlerin birden fazla cihazda olduğu anlaşılabilir. Bu durumda yeni verinin nasıl ele alınacağı, işin ne kadarının ilk bedelde kaldığı ve hangi kalemin ek onay istediği belirtilmelidir. Değişiklikler yalnız sözlü görüşmelerde bırakılmamalıdır.
Kesinleşen teklifi şirketin iş sorumlusu da okuyabilmelidir. Teknik yöntem yanında kullanıcıdan beklenen işlemler, planlanan iletişim ve kabul edilecek çıktı anlaşılır olmalıdır. Müşterinin erişim sağlayamadığı veya kararı ertelediği başlıklar açık işler olarak gösterilebilir. Böylece uygulama başladığında hangi bilginin doğrulandığı, hangi varsayımın devam ettiği ve hangi değişikliğin ayrıca değerlendirileceği iki taraf için de görülebilir.
Uygulama öncesi son kontroller
Mail taşıma hizmeti fiyatını kutu sayısı, toplam hacim, kaynak sınırlamaları, veri türleri ve kullanıcı geçiş ihtiyacı etkiler. Yerel arşiv incelemesi, uygulama ayarları, mesai dışı çalışma ve başka sağlayıcıyla koordinasyon farklı iş yükleri oluşturabilir. Yeni abonelik veya barındırma bedeli varsa aktarım hizmetinden ayrı gösterilmelidir. Aynı kullanıcı adedi için verilen iki fiyatın farklı olmasının nedeni farklı teslimler olabilir; bu nedenle teklif satırlarını eşitlemeden yalnız toplam bedel üzerinden seçim yapılmamalıdır.
Son kontrol listesinde kaynak ve hedef, veri türleri, adres eşleştirmesi, erişimler, yönlendirme ve kabul bulguları 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.
İlgili kaynaklar
Resmî kaynaklar
Teknik belgeler ve mevzuat değişebilir; uygulama öncesinde ilgili sürüm ve güncel metin kontrol edilmelidir.
Sık Sorulan Sorular
Mail taşıma hizmeti hangi verileri kapsar?
İletiler, klasörler, kişiler, takvimler ve yerel arşivler ayrı değerlendirilir. Hangi verinin hangi yöntemle taşınacağı ve kapsam dışında kalanlar yazılı teklifte belirtilmelidir.
E-posta taşıma hizmeti için alan adı transferi gerekir mi?
Her zaman gerekmez. Alan adı kayıt firmasını değiştirmekle posta sağlayıcısını değiştirmek ayrı işlemlerdir. Gerekli DNS düzenlemeleri mevcut alan adı yönetiminde yapılabilir.
Mail taşıma fiyatını ne belirler?
Kutu sayısı, hacim, kaynak sınırları, veri türleri, yerel arşivler, cihaz ayarları ve uygulama bağlantıları bedeli etkiler. Kesin fiyat ön inceleme ve kapsam sonrasında belirlenir.
Eski e-posta hizmeti ne zaman kapatılmalı?
Kabul edilen veri ve kullanım kontrolleri tamamlandıktan, kalan bağımlılıklar değerlendirildikten sonra yetkili şirket sorumlusuyla karar verilmelidir. Kaynak erken kapatılmamalıdır.
Kurumsal mail taşıma teklifi nasıl alınır?
Mail taşıma hizmeti veya iletişim formundan kaynak sağlayıcı, hedef, yaklaşık kutu sayısı ve veri hacmi paylaşılabilir. Parola gibi hassas bilgiler açık forma eklenmemelidir.