Exchange geçişi: hazırlık ve kontrol listesi

Sunucu ve bulut posta kutuları arasında zarf ve takvim taşıyan köprü ile doğrulama tepsisi.
Temsili görsel: Exchange geçişi veri, erişim ve teslim kontrolleriyle planlanır.

Exchange geçişi: hazırlık ve kontrol listesi

Exchange geçişi, posta kutularının yanında erişim ilişkileri ve bağlı uygulamaların da değerlendirilmesini gerektirir. Kaynak sürüm, hedef ortam ve desteklenen yöntem birlikte incelenmelidir. İletilerin aktarılması; takvim, ortak klasör veya başka bir adres adına gönderme davranışının da doğrulandığını göstermez. Geçiş planı veri türlerini, yeniden hazırlanacak ayarları ve kabul senaryolarını ayrı açıklamalıdır. Uygulama kapsamı için mail taşıma hizmeti sayfasındaki açıklamalar da değerlendirilebilir.

Bu hizmet; eski Exchange altyapısını yenilemek, Exchange Online ortamına geçmek veya mevcut posta yapısını farklı bir hedefe taşımak isteyen işletmeler için değerlendirilebilir. Her hedefin aynı veri türlerini ve çalışma özelliklerini sağladığı varsayılmamalıdır. Teklifte taşınacak varlıklar, korunması beklenen işlevler ve yeniden yapılandırılacak bağımlılıklar ayrı gösterilir. Böylece satın aldığınız iş yalnızca dosya kopyalama olarak kalmaz; şirketin geçiş sonrasında hangi koşullarda çalışacağı da teslim kapsamına girer.

Ön inceleme: Exchange sürümü ve ortam bağımlılıkları

İlk değerlendirmede Exchange sürümü, güncelleme düzeyi, sunucu düzeni, posta kutusu sayısı ve toplam veri hacmi öğrenilir. Active Directory ilişkisi, alan adları, sertifikalar ve mevcut posta akışı da dikkate alınır. Yönetim erişiminin hangi ekipte olduğu, başka bir sağlayıcıdan devir gerekip gerekmediği ve belgelerin bulunup bulunmadığı iş yükünü etkiler. Kaynak sistemin kararsız veya eksik belgelenmiş olması, aktarım başlamadan ayrı hazırlık çalışması gerektirebilir.

Teklif talebinde bu bilgilerin tamamını bilmeniz gerekmez. Mevcut sunucu sorumlusunu, yaklaşık kullanıcı sayısını, işletmenin çalışma saatlerini ve geçiş nedenini paylaşmanız başlangıç sağlar. Teknik erişim gerektiğinde yetkilendirme yöntemi ayrıca belirlenir; açık forma yönetici parolası yazılmamalıdır. Ön incelemenin çıktısı, kaynak durumunu, hedef seçeneklerini, eksik bilgileri ve karar bekleyen konuları açıklayan kısa bir kapsam özeti olabilir. Bu özet, uygulanamayacak bir yönteme erken fiyat verilmesini önler.

Hedef sistem ve desteklenen geçiş yolu birlikte seçilir

Exchange Online geçişiyle yerel Exchange ortamının yenilenmesi aynı proje değildir. Bulut hedefinde abonelik, kuruluş kimliği ve bağlantı koşulları değerlendirilirken, yerel hedefte sunucu altyapısı ve desteklenen kurulum gereksinimleri önem kazanır. Microsoft’un Exchange destek matrisi, sürüm ve ortam uygunluğunu kontrol etmek için temel başvurudur. Uygulanacak rota, teklif hazırlanırken mevcut sürümler ve güncel üretici koşulları üzerinden doğrulanmalıdır.

Exchange Server 2016 ve 2019’un standart destek dönemi 14 Ekim 2025’te sona ermiştir. Bu durum eski ortamın kendiliğinden kapanacağı veya hiçbir geçiş seçeneğinin kalmadığı anlamına gelmez. Destek durumu, varsa özel uzatılmış güvenlik kapsamı ve hedefe ulaşmak için gereken ara çalışmalar ayrı değerlendirilmelidir. Desteklenen yerel sürüme geçiş isteniyorsa lisans, altyapı ve uygulama kapsamı ayrıca netleştirilir. İnceleme yapılmadan eski sürümü yeni bir kurulum önerisi gibi sunmak doğru değildir.

Posta kutusu envanteri yalnız kullanıcı listesinden oluşmaz

Kişisel posta kutuları, ortak kutular, kaynak kutuları, takma adlar ve gruplar farklı kullanımları temsil eder. Toplantı odası rezervasyonu, ekip adına gönderim veya uygulama bildirim adresi günlük işin parçası olabilir. Her varlığın sahibi, yaklaşık hacmi ve hedefte nasıl kullanılacağı belirlenmelidir. Sunucudaki çevrimiçi arşiv ile kullanıcının bilgisayarındaki yerel arşiv aynı veri kaynağı değildir. Bunların teklifte tek kalem altında belirsiz bırakılması kabul sırasında eksik beklenti yaratabilir.

Microsoft’un posta geçiş yöntemleri açıklaması, kullanılan yönteme göre kapsamın değişebildiğini gösterir. Örneğin IMAP üzerinden yalnız ileti klasörlerinin aktarılmasını sağlayan bir çalışma, takvim ve kişilerin de taşındığı anlamına gelmez. Exchange’e özgü özellikleri koruma beklentiniz varsa bunun yöntem değerlendirmesinde açıkça yer alması gerekir. Aktarılmayacak öğeler, başka işlem gerektiren veriler ve müşterinin ayrıca sağlayacağı dosyalar yazılı olarak ayrılmalıdır.

Delege erişimleri ve ortak takvimler ayrı teslimdir

Yönetici takvimini kullanan asistan, ortak kutudan yanıtlayan satış ekibi veya başka çalışan adına gönderim yapan bölüm sorumlusu farklı izin ilişkileri oluşturur. Veri aktarılmış görünse bile bu ilişkiler hedefte beklenen biçimde çalışmayabilir. Exchange geçiş teklifinde erişim envanteri, gerekli yeniden tanımlamalar ve kullanıcıyla yapılacak testler bulunmalıdır. Teknik ekibin uygulama sorumluluğu ile şirketin kime hangi erişimin verileceğine karar verme sorumluluğu ayrılmalıdır.

Microsoft’un Exchange hibrit izinleri belgesi, farklı ortamlardaki posta kutuları arasında bütün izinlerin aynı şekilde desteklenmediğini ve ek yapılandırma gerekebildiğini açıklar. Bu nedenle tek bir ortak kutuyu açabilmek bütün delege senaryolarının kabulü sayılmamalıdır. Tam erişim, adına gönderim ve takvim kullanımının her biri gerçek ihtiyaçla karşılaştırılabilir. Uygulama ve tarayıcı davranışları da farklı olabileceğinden kabul testinde kullanılan istemci belirtilmelidir.

Ortak klasörler ve uygulama gönderimleri ayrıca kapsamlandırılır

Ortak klasör kullanan işletmelerde klasör yapısı, veri hacmi, yetkiler ve e-posta adresi verilmiş klasörler ayrıca incelenir. Bunları sıradan kullanıcı kutusu gibi fiyatlandırmak veya bütün verinin aynı işlemle taşınacağını varsaymak uygun değildir. Microsoft’un ortak klasör işlemleri belgeleri, geçiş ve hibrit kullanım için ayrı çalışma başlıkları tanımlar. Kaynak sürüme uygun güncel yöntem ve hedef sınırları proje öncesinde kontrol edilmelidir.

Ayrıca yazıcılar, tarayıcılar, muhasebe yazılımı ve web uygulamaları Exchange üzerinden bildirim gönderiyor olabilir. Bu bağlantıların kimlik doğrulama, izin verilen gönderici ve erişim bağımlılıkları belirlenmelidir. Cihazın posta göndermesiyle bir çalışanın posta kutusuna giriş yapması aynı test değildir. Teklifte uygulama sahiplerinin hangi aşamada katılacağı yazılabilir. Başka yazılım ekibinin müdahalesi gerekiyorsa koordinasyonun kim tarafından yürütüleceği ve bu işin bedeli de ayrıca açıklanmalıdır.

Birlikte çalışma veya hibrit yapı otomatik gereklilik değildir

Bazı işletmeler bütün kullanıcıları aynı geçiş aralığında taşımayı, bazıları ise gruplar halinde ilerlemeyi ister. Kaynak ve hedef ortamın bir süre birlikte kullanılması planlanıyorsa posta akışı, adres görünürlüğü ve gerekli ortak işlevler değerlendirilir. Microsoft’un hibrit dağıtım açıklaması, bu yapının buluta geçiş veya uzun süreli birlikte çalışma amacıyla kullanılabildiğini gösterir. Ancak her müşteriye aynı hibrit kurulumun gerekli olduğu sonucu çıkarılamaz.

Hibrit çalışma teklif ediliyorsa amacı, ön koşulları, yönetim sorumlusu ve ne kadar süre korunacağı belirtilmelidir. Geçiş tamamlandığında kaynak sunucunun kaldırılması ayrı bir karar olabilir; kimlik yönetimi veya başka bağımlılıklar devam edebilir. “Son kutu taşındığında eski sunucu kapatılır” yaklaşımı inceleme yapılmadan kabul edilmemelidir. Kullanılacak rotanın müşteriye açıklanması, geçici proje işiyle devam edecek işletim maliyetlerinin ayrılmasına yardımcı olur.

Pilot, canlı geçiş ve kabul karşılaştırması

Pilot çalışmada küçük ama farklı ihtiyaçları temsil eden örnekler seçilir. Büyük kutu, ortak adres, delege erişimi ve mobil kullanım gibi senaryolar aktarımın yalnız hızını değil işlevsel sonucunu gösterir. Varsayımsal olarak iletiler taşınmış olsa da ekip adına gönderim çalışmıyorsa ilgili kullanım kabul edilmemiş sayılır. Bu bir müşteri başarısı iddiası değil, teslim ölçütünü açıklayan örnektir. Pilot bulguları canlı geçişten önce açık iş listesine dönüştürülmelidir.

Kabulde kaynak ve hedef arasında örnek tarih aralıkları, klasörler, ekler, ilgili takvim öğeleri ve kapsamda bulunan erişimler karşılaştırılabilir. Dışarıdan alım, dışarıya gönderim, yanıt ve uygulama bildirimleri ayrıca denenir. Hata ve atlanan öğe raporlarının nasıl değerlendirileceği yazılır. Kullanıcı bilgilendirmesi, canlı değişiklik onayı ve geri dönüş koşulları da plana eklenir. Veri kaybı veya kesinti olmayacağına koşulsuz garanti vermek yerine, risklerin ve kontrol adımlarının açık olması aranmalıdır.

Kaynak sistemin kapatılması ve proje sonrası sorumluluklar

Eski sistemin kapatılması veri aktarımının doğal ve otomatik son adımı olarak görülmemelidir. Kabul edilmeyen öğeler, devam eden uygulama bağlantıları, erişim gerektiren arşivler ve şirketin saklama beklentileri önce değerlendirilir. Kaynak yedeğinin varlığı ve gerektiğinde kullanılabilirliği ayrıca kontrol edilebilir. Geçiş hizmetinin bağımsız yedekleme hizmeti içerip içermediği de yazılmalıdır. Aktarım için tutulan kopyayla uzun süreli geri yükleme ihtiyacının aynı şey olmadığı anlaşılmalıdır.

Teslim belgesinde hangi sistemin açık kalacağı, kim tarafından yönetileceği ve kapanış kararının hangi koşullarda verileceği belirtilir. Geçici erişimler ve proje hesapları gözden geçirilir; devam edecek yönetim yetkileri müşteri onayına bağlanır. Kullanıcı sorunları için geçiş sonrası destek dönemi tanımlanabilir. Sonradan yeni bir kutunun taşınması veya kapsam dışı uygulamanın hazırlanması istenirse ek iş onayı alınmalıdır. Böylece proje kapanışı, çözümlenmemiş teknik işleri görünmez kılmadan yapılabilir.

Exchange geçiş hizmeti fiyatını hangi kalemler belirler?

Fiyatı yalnız posta kutusu sayısı belirlemez. Toplam veri hacmi, büyük arşivler, kaynak sistemin durumu, ortak klasörler, delege ilişkileri, uygulama bağlantıları ve kullanıcı cihazları iş yükünü değiştirir. Geçiş aralığının işletmenin mesaisi dışında olması, yerinde çalışma veya birden fazla ekiple koordinasyon ihtiyacı da değerlendirilir. Lisans, yeni altyapı ve devam eden yönetim bedellerinin proje hizmetinden ayrı gösterilmesi, teklifleri aynı kapsamla karşılaştırmanızı sağlar.

Son kontrol listesinde kaynak sürüm, hedef, kutu envanteri, delege izinleri, ortak klasörler ve kabul sonuçları 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.

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

Exchange geçiş hizmeti hangi işleri kapsar?

Kaynak ortam incelemesi, hedefe uygun yöntem, posta kutusu ve bağımlılık envanteri, pilot aktarım, canlı geçiş ve kabul kontrolleri kapsamlandırılır. Ortak klasörler, delege erişimleri ve uygulama gönderimleri ayrıca belirtilmelidir.

Exchange 2016 veya 2019 ortamından geçiş yapılabilir mi?

Bu sürümlerin standart desteği 14 Ekim 2025’te sona ermiştir. Geçiş yolu kaynak güncelleme düzeyi, hedef, erişim ve güncel üretici koşulları üzerinden değerlendirilir; destek sonu tek başına bütün geçiş seçeneklerinin kapandığı anlamına gelmez.

Exchange geçişinde takvim ve delege yetkileri otomatik taşınır mı?

Kullanılan yöntem ve hedefe göre değişir. İleti aktarımı bütün takvim, adına gönderim ve ortak kutu erişimlerinin çalıştığını göstermez. Beklenen izinler ayrı listelenmeli ve ilgili kullanıcılarla test edilmelidir.

Exchange geçiş hizmeti fiyatı nasıl belirlenir?

Kutu sayısı ve hacim yanında kaynak durumu, arşivler, ortak klasörler, izin ilişkileri, cihazlar, uygulamalar ve çalışma zamanı değerlendirilir. Kesin bedel inceleme ve yazılı kapsam sonrasında belirlenir.

Exchange geçiş teklifi için hangi bilgiler gerekir?

Mevcut Exchange sürümü, yaklaşık posta kutusu sayısı ve hacim, hedef ortam ve varsa ortak klasör ihtiyacı paylaşılabilir. Mail taşıma hizmeti veya iletişim formundan talep iletilebilir; parolalar açık forma yazılmamalıdır.

Birlikte iz bırakalım

Hikâyenizin bir sonraki bölümünü birlikte yazalım.

Projenizi Konuşalım
Birlikte Başlayalım