- (0224) 322 22 90
- info@bursabilgisayar.tr
Kurumsal e-posta altyapısını değiştirmek, yalnızca yeni kullanıcı hesapları açmak anlamına gelmez. Mevcut kullanıcıların geçmiş mesajlarının, klasörlerinin, Outlook verilerinin ve mail akışının yeni sisteme doğru şekilde aktarılması gerekir.
Yanlış planlanan bir e-posta geçişi; geçmiş mesajların kaybolmasına, e-posta gönderim ve alımının kesilmesine, kullanıcıların Outlook erişimini kaybetmesine veya domain DNS kayıtlarının yanlış yapılandırılmasına neden olabilir.
Bursa Bilgisayar olarak Bursa e-posta taşıma ve mail migration hizmetimiz kapsamında işletmelerin mevcut e-posta sistemlerini analiz ediyor; Microsoft 365, Exchange Online, IMAP tabanlı mail sunucuları ve diğer kurumsal e-posta altyapıları arasında kontrollü geçiş planları oluşturuyoruz.
Amacımız yeni mail sistemine geçerken kullanıcıların geçmiş e-postalarını mümkün olduğunca korumak ve e-posta hizmetindeki kesintiyi minimum seviyede tutmaktır.
E-posta taşıma, mevcut mail sunucusunda bulunan kullanıcı hesaplarının ve posta kutularının yeni e-posta altyapısına aktarılmasıdır.
Taşınabilecek veriler kullanılan kaynak ve hedef sisteme göre değişmekle birlikte;
gibi içerikler migration kapsamına dahil edilebilir.
Her sistem arasında birebir aynı veri türlerinin taşınabileceği varsayılmamalıdır.
İşletmenin mevcut altyapısına göre;
hizmetleri sunuyoruz.
Mevcut kurumsal e-posta sisteminizden Microsoft 365 Exchange Online altyapısına geçiş yapılabilir.
Örneğin mevcut yapı;
Eski IMAP Mail Sunucusu
↓
Microsoft 365 Exchange Online
şeklinde taşınabilir.
Geçiş öncesinde kullanıcı hesapları ve Microsoft 365 lisansları hazırlanır.
Ardından mevcut posta kutuları uygun migration yöntemiyle yeni ortama aktarılır.
IMAP destekleyen eski e-posta sunucularından Microsoft 365 ortamına mesaj ve klasörler taşınabilir.
Migration öncesinde;
kontrol edilir.
Ardından kullanıcı bazında migration görevleri oluşturulabilir.
Bir hosting firmasından veya mail sunucusundan başka bir IMAP destekli sisteme geçiş yapılabilir.
Örneğin;
Eski Hosting Mail
↓
Yeni Kurumsal Mail Sunucusu
şeklinde posta kutuları aktarılabilir.
Bu yöntem özellikle domain ve web hosting değişmeden yalnızca mail altyapısının değiştirilmesinde kullanılabilir.
POP3 kullanan işletmelerde durum biraz daha farklıdır.
POP3 mesajları kullanıcının bilgisayarına indiriyor olabilir ve bazı mesajlar mail sunucusunda artık bulunmayabilir.
Bu durumda eski e-postaların önemli bölümü Outlook PST dosyalarında olabilir.
Migration öncesinde kullanıcı bilgisayarlarının kontrol edilmesi gerekir.
Outlook’un POP3 veya eski kurulumlarında e-postalar PST dosyası içerisinde saklanabilir.
Bu dosyalarda;
bulunabilir.
Yeni e-posta sistemi kurulduktan sonra uygun PST dosyaları Outlook’a bağlanabilir veya desteklenen sistemlerde yeni mailbox’a aktarılabilir.
İşlem öncesinde PST dosyalarının ayrıca yedeklenmesi önemlidir.
Şirket içerisinde lokal Microsoft Exchange Server kullanılıyorsa Exchange Online veya Microsoft 365’e migration planlanabilir.
Bu geçiş;
gibi kriterlere göre daha kapsamlı olabilir.
Küçük bir IMAP migration ile Exchange migration aynı şekilde değerlendirilmemelidir.
cPanel üzerinde çalışan kurumsal e-posta hesapları farklı bir mail altyapısına taşınabilir.
Öncelikle kullanıcı hesapları, posta kutuları ve mevcut DNS kayıtları incelenir.
Ardından IMAP üzerinden veya uygun diğer yöntemlerle veriler yeni sisteme aktarılabilir.
Plesk üzerinde çalışan e-posta hesaplarının da yeni mail sistemine migration işlemi gerçekleştirilebilir.
Plesk üzerindeki;
kontrol edilerek yeni sistemde karşılıkları oluşturulabilir.
Migration işlemine başlamadan önce mevcut altyapının envanteri çıkarılmalıdır.
Örneğin;
gibi sorular cevaplanmalıdır.
Geçiş öncesinde aktif e-posta hesapları belirlenmelidir.
Örneğin;
Eski veya artık kullanılmayan hesapların yeni sisteme taşınması gerekmeyebilir.
Bu işlem lisans ve mailbox maliyetlerini de azaltabilir.
Her kullanıcının posta kutusu boyutu migration süresini etkiler.
Örneğin;
olabilir.
Özellikle yüksek mailbox boyutlarında migration süresi ve yeni sistemde kullanılacak lisans kapasitesi önceden planlanmalıdır.
Migration öncesinde gereksiz spam, çöp ve çok büyük eski mesajların temizlenmesi geçiş süresini azaltabilir.
Ancak kullanıcı verileri kontrolsüz şekilde silinmemelidir.
Hangi klasörlerin ve hangi tarih aralığının taşınacağı işletmeyle birlikte belirlenebilir.
Mümkün olan migration yöntemlerinde e-postaların büyük bölümü MX kaydı değiştirilmeden önce yeni sisteme aktarılabilir.
Örneğin;
Eski Mail Server → Ön Migration → Yeni Mail Server
Bu işlem sırasında kullanıcılar eski sistemi kullanmaya devam eder.
Daha sonra final senkronizasyon yapılarak yeni sisteme geçiş gerçekleştirilebilir.
MX kaydı, domaininize gelen yeni e-postaların hangi sunucuya teslim edileceğini belirler.
Geçiş anında MX kaydı eski sunucudan yeni mail sistemine yönlendirilir.
Örneğin;
Eski MX
↓
Yeni Microsoft 365 / Mail Server MX
DNS değişikliğinin internete yayılması belirli bir süre alabilir.
Bu nedenle geçiş öncesinde DNS TTL değerlerinin planlanması faydalı olabilir.
Migration öncesinde uygun durumda MX kaydının TTL süresi düşürülebilir.
Bu sayede geçiş anında yapılan DNS değişikliğinin daha hızlı yayılması sağlanabilir.
TTL değişikliği migration gününde değil, mümkünse önceden planlanmalıdır.
Mail sağlayıcısı değiştiğinde SPF kaydının da yeni gönderim altyapısına göre güncellenmesi gerekir.
Ancak web sitesi, CRM veya ERP gibi sistemlerin de domain adına e-posta gönderdiği işletmelerde bu kaynakların unutulmaması önemlidir.
Aksi halde meşru e-postalar SPF kontrolünden geçemeyebilir.
Yeni e-posta sağlayıcısında DKIM destekleniyorsa gerekli DNS kayıtları oluşturulabilir.
Microsoft 365 veya farklı mail altyapılarında DKIM etkinleştirme yöntemi değişebilir.
DKIM’in migration sonrası aktif olarak çalıştığı test edilmelidir.
Mevcut DMARC kaydı varsa yeni mail sağlayıcısının SPF ve DKIM yapılarıyla uyumlu olması gerekir.
Yeni DMARC kurulacaksa doğrudan sıkı reject politikasına geçmek yerine mevcut mail kaynakları analiz edilmelidir.
Bu sayede web sitesi veya ERP gibi unutulan gönderim kaynaklarının bloklanması önlenebilir.
DNS yayılımı sırasında bazı mesajlar eski sunucuya, bazıları yeni sunucuya ulaşabilir.
Bu nedenle eski e-posta sistemi geçiş tamamlanır tamamlanmaz kapatılmamalıdır.
Belirli süre boyunca eski sistem açık tutularak yeni gelen mesajlar kontrol edilebilir.
Gerekirse final senkronizasyon gerçekleştirilebilir.
MX kaydı yeni sisteme yönlendirildikten sonra eski mail sunucusuna gelen son mesajlar tekrar senkronize edilebilir.
Bu işlem migration sırasında oluşabilecek küçük mesaj farklarının kapatılmasına yardımcı olur.
Final senkronizasyon sonrasında eski sunucu belirli süre gözlem altında tutulabilir.
Mail sağlayıcısı değiştiğinde kullanıcıların Outlook profillerinin yeniden yapılandırılması gerekebilir.
Özellikle Microsoft 365’e geçişte eski IMAP/POP hesabı kaldırılıp yeni Exchange profili oluşturulabilir.
Kullanıcıya ait;
kontrol edilebilir.
Yeni e-posta altyapısına geçildiğinde mevcut Outlook profilinin doğrudan kullanılmaya devam edilmesi her zaman mümkün olmayabilir.
Yeni Outlook profili oluşturularak yeni mailbox bağlanabilir.
Eski PST dosyaları gerekiyorsa ayrıca eklenebilir.
Kullanıcıların telefonlarında eski mail hesabı kayıtlı olabilir.
Migration sonrasında Android ve iOS cihazlarda yeni hesap yapılandırmaları yapılabilir.
Microsoft 365 kullanılıyorsa Outlook mobil uygulaması değerlendirilebilir.
Eski webmail adresi değişebilir.
Örneğin kullanıcı daha önce;
webmail.firma.com
üzerinden giriş yapıyorken yeni sistemde Microsoft 365 Outlook Web veya farklı bir webmail arayüzü kullanılabilir.
Kullanıcılara yeni giriş adresleri ve yöntemleri bildirilmelidir.
info@, satis@, muhasebe@ gibi ortak adresler yeni sistemde farklı şekilde yapılandırılabilir.
Microsoft 365 ortamında uygun hesaplar Shared Mailbox olarak oluşturulabilir.
Böylece tek bir parolanın birden fazla kullanıcıyla paylaşılması yerine kullanıcı bazlı erişim verilebilir.
Bir kullanıcının birden fazla e-posta adresi bulunabilir.
Örneğin;
ve alias olarak;
kullanılıyor olabilir.
Migration öncesinde alias adreslerinin listelenmesi ve yeni sistemde yeniden tanımlanması gerekir.
Mevcut e-posta sistemindeki yönlendirmeler kontrol edilmelidir.
Örneğin;
info@firma.com → metin@firma.com
gibi forwarding tanımları yeni sisteme taşınabilir.
Ancak kurumsal mesajların kişisel Gmail gibi hesaplara yönlendirilmesi veri güvenliği açısından ayrıca değerlendirilmelidir.
Eski mail sistemindeki vacation veya autoresponder ayarları migration sonrasında otomatik olarak taşınmayabilir.
Gerekli otomatik yanıtlar yeni sistem üzerinde yeniden oluşturulabilir.
Satış, yönetim veya diğer departmanlar için kullanılan dağıtım grupları yeni sistemde yeniden oluşturulabilir.
Örneğin;
→ kullanıcı1
→ kullanıcı2
→ kullanıcı3
şeklindeki dağıtım yapıları korunabilir.
IMAP protokolü temel olarak e-posta mesajlarının senkronizasyonuna odaklanır.
Takvim ve kişi verileri her IMAP migration işleminde otomatik olarak taşınmaz.
Bu verilerin kaynağı Outlook PST veya farklı bir Exchange sistemi ise ayrıca migration yöntemi belirlemek gerekebilir.
Outlook imzaları çoğu e-posta migration yöntemiyle otomatik taşınmaz.
Kullanıcı bilgisayarlarındaki mevcut imzalar yedeklenebilir veya yeni kurumsal imza formatı oluşturulabilir.
Microsoft 365 kullanan işletmelerde merkezi imza çözümleri de ayrıca değerlendirilebilir.
Migration süresi;
gibi faktörlere bağlıdır.
Örneğin 5 kullanıcılı küçük bir işletmeyle 100 kullanıcılı ve yüzlerce GB e-postası bulunan işletmenin migration süresi aynı değildir.
30–50 GB ve üzeri posta kutularının taşınması uzun sürebilir.
Bu durumda migration önceden başlatılabilir ve incremental/final sync yöntemleri kullanılabilir.
Kullanıcının çalışmasını mümkün olduğunca etkilemeden veri arka planda aktarılabilir.
Doğru migration planıyla veri kaybı riski önemli ölçüde azaltılabilir ancak hiçbir teknik işlem için sıfır risk garantisi vermek doğru değildir.
Bu nedenle kritik mailboxlar için migration öncesinde ek backup alınması değerlendirilebilir.
Özellikle POP3 kullanan kullanıcılarda Outlook PST dosyalarının yedeklenmesi önemlidir.
Migration öncesinde;
gibi yöntemlerle ek güvenlik kopyası oluşturulabilir.
Hangi yöntemin kullanılabileceği mevcut mail sistemine göre değişir.
Çok kullanıcılı işletmelerde bütün sistemi tek seferde taşımadan önce pilot kullanıcıyla test yapılabilir.
Pilot migration sayesinde;
kontrol edilebilir.
Ardından diğer kullanıcıların migration işlemine geçilebilir.
Çok sayıda kullanıcının bulunduğu işletmelerde final e-posta geçişi çalışma saatleri dışında planlanabilir.
Örneğin cuma akşamı MX değişimi gerçekleştirilerek hafta sonu kullanıcı profilleri hazırlanabilir.
Pazartesi günü kullanıcıların yeni sistemle çalışmaya başlaması hedeflenebilir.
Geçiş zamanı işletmenin çalışma düzenine göre planlanmalıdır.
Geçiş tamamlandıktan sonra;
kontrol edilir.
Migration sonrasında yeni mail sisteminden gönderilen mesajların teslimat durumu kontrol edilebilir.
SPF, DKIM ve DMARC yapılandırmalarının doğru çalışması teslimat güvenilirliği açısından önemlidir.
Yeni sistemin IP ve domain reputation durumu da etkili olabilir.
Eski mail sunucusu yeni sistem tamamen doğrulanmadan kapatılmamalıdır.
Öncelikle;
kontrol edilmelidir.
Ardından eski sistem kontrollü şekilde devreden çıkarılabilir.
Web sitesi hosting değişikliği sırasında e-postalar da aynı hosting hesabında bulunuyorsa migration ayrıca planlanmalıdır.
Web sitesini taşımak e-posta hesaplarının otomatik olarak yeni sunucuya geçtiği anlamına gelmez.
Domain, DNS, web ve mail servisleri ayrı ayrı kontrol edilmelidir.
Domaini farklı firmaya transfer etmek e-posta sistemini değiştirmek zorunda olduğunuz anlamına gelmez.
Domain registrar, DNS ve mail hizmetleri farklı servis sağlayıcılarda bulunabilir.
Bu nedenle migration öncesinde domain ve DNS yönetiminin kimde olduğu belirlenmelidir.
Microsoft 365’e migration yapılan işletmeler;
gibi servislerden yararlanabilir.
Hangi özelliklerin kullanılabileceği seçilen Microsoft 365 lisansına bağlıdır.
Bazı işletmelerde farklı Microsoft 365 tenantları arasında kullanıcı veya domain migration ihtiyacı oluşabilir.
Tenant-to-tenant migration standart IMAP geçişinden daha karmaşık olabilir.
Domain, kullanıcı kimlikleri, Exchange, OneDrive, SharePoint ve Teams gibi servisler ayrı ayrı değerlendirilmelidir.
Migration yapılırken yalnızca mesajların taşınmasına odaklanmak doğru değildir.
Yeni sistemde;
SPF + DKIM + DMARC + MFA + Güçlü Parola Politikası
birlikte yapılandırılmalıdır.
Bu sayede yeni e-posta ortamı ilk günden daha güvenli hale getirilebilir.
E-posta migration öncesinde kullanıcılara kısa bilgilendirme yapılması geçişi kolaylaştırır.
Örneğin;
önceden paylaşılabilir.
Microsoft 365 veya farklı bir mail sistemine geçildiğinde kullanıcıların alışkanlıkları değişebilir.
Özellikle Exchange Online’a geçişte;
kullanımı konusunda kısa kullanıcı desteği sağlanabilir.
Genel olarak şu adımlarla ilerliyoruz:
E-posta migration hizmetlerimiz özellikle;
için planlanabilir.
Bursa Bilgisayar olarak e-posta taşıma işlemini yalnızca eski sunucudan yeni sunucuya mesaj kopyalamak şeklinde değerlendirmiyoruz.
Mail Migration + Microsoft 365 + Domain + DNS + MX + SPF + DKIM + DMARC + Outlook + Mobil Cihazlar + E-Posta Güvenliği süreçlerini birlikte yönetiyoruz.
Böylece kullanıcıların geçmiş mesajlarını mümkün olduğunca koruyarak, yeni e-posta altyapısının güvenlik ve DNS yapılandırmalarını da aynı geçiş içerisinde tamamlamayı hedefliyoruz.
Mevcut hosting veya mail sağlayıcınızı değiştirmek, şirketinizi Microsoft 365’e geçirmek veya eski POP3/IMAP sisteminizden daha profesyonel bir kurumsal e-posta altyapısına taşınmak istiyorsanız mevcut yapınızı birlikte değerlendirebiliriz.
Bursa Bilgisayar olarak Bursa e-posta taşıma, mail migration, Microsoft 365 e-posta taşıma, IMAP migration, Outlook PST taşıma, Exchange Online migration ve kurumsal mail taşıma ihtiyaçlarınız için kontrollü bir geçiş planı oluşturuyor ve kullanıcılarınızın yeni sistemde çalışır hale gelmesini sağlıyoruz.
