Yeni bir araca geçmenin gerçek maliyeti çoğu zaman migration başladıktan sonra ortaya çıkar. Hesap eşlemeleri, ortam yapılandırması, ağ çıkışları, ekip izinleri ve eski ortamın korunup korunmaması, geçişin sorunsuz ilerleyip ilerlemeyeceğini belirler.
Bir ortam yönetim aracını değiştirmek ilk bakışta basit görünür: yazılımı kurup verileri dışa aktarmak.
Asıl zaman alan kısım, günlük kullanımda pek dikkat edilmeyen ayrıntılardır: onlarca hesap ile ortam arasındaki eşleşmeler taşınabiliyor mu, ortam yapılandırmaları baştan mı kurulacak, ekibin mevcut çalışma alışkanlıkları geçerli olmaya devam edecek mi, eski ortam aynı gün kapatılabilir mi? Bu sorular karar aşamasında netleşmezse migration kolayca yeniden iş yapmaya dönüşür.
Önce hesaplar ile ortamların doğru eşleştirilebildiğini doğrulayın
Taşınması gereken şey yalnızca kullanıcı adı ve parola değildir; hangi hesabın hangi ortamda çalıştığı ve o ortama hangi ağ çıkışının bağlı olduğu tüm eşleme yapısıdır. Bu eşleme dışa aktarılamıyorsa migration fiilen elle yeniden kurulum anlamına gelir. Hesap sayısı onlarca veya yüzlerce olduğunda hata neredeyse kaçınılmazdır.
Kontrol yöntemi basittir: eski araçtaki dışa aktarma özelliğine bakın ve dışa aktarılan alanlarda ortam kimlikleri ile ağ yapılandırmasının bulunup bulunmadığını kontrol edin. Yalnızca hesap ve parola dışa aktarılabiliyorsa bu, gerçek eşleme için pratikte yeterli değildir.
Ortam yapılandırması kopyalanmaz, yeniden kurulur
Fingerprint parametreleri, saat dilimi ve dil, ayrıca bağlı ağ çıkışı ortamın temel parçalarıdır. Ancak farklı araçların parametre sistemleri birebir uyumlu değildir. Her değeri tek tek taşımaya çalışmak çoğu zaman eksik veya birbiriyle uyuşmayan bir yapılandırmayla sonuçlanır.
Daha uygulanabilir yaklaşım, yapılandırma niyetini dışa aktarmaktır; örneğin ABD bölgesi, Windows sistemi ve belirli bir donanım seviyesi. Ardından yeni araçta ortam bu niyete göre yeniden oluşturulur. Hedef, eski ortamın aynısını yapmak değil, tutarlı ve kullanılabilir bir ortam elde etmektir.
Cookies ve oturum açma durumu
Oturumun açık kalması gereken hesaplarda session durumunun taşınabilmesi, migration sonrasında tüm hesapların yeniden giriş yapıp yapmayacağını doğrudan belirler. Kolay gözden kaçan bir nokta şudur: onlarca hesabın aynı gün topluca yeniden oturum açması başlı başına olağandışı bir sinyaldir. Bu nedenle geçiş bir kerede bitirilmek yerine zamana yayılmalıdır.
Ağ çıkışının bağlanma yöntemi uyumlu mu?
Çıkış ortam üzerinden bağlanıyorsa yeni aracın aynı protokolü ve bağlama yöntemini desteklediği doğrulanmalıdır. Desteklemiyorsa tüm ağ yapılandırması yeniden yapılır ve bu iş yükü önceden maliyete dahil edilmelidir.
Ekibin çalışma alışkanlıkları bozulacak mı?
İzin modeli benzer mi? Ekip üyeleri birbirlerine parola vermeden çalışabiliyor mu? İşlem günlükleri hâlâ görülebiliyor mu? Bu üç unsur ekibin ne kadar yeniden öğrenmesi gerektiğini belirler. Ekip büyüdükçe maliyet de artar.
Eski ortam bir süre tutulmalı mı?
Migration tek adımda tamamlanmak zorunda değildir. Eski ortamı birkaç hafta daha tutmak beklenenden daha faydalı olabilir: yeni ortamla karşılaştırma yapılabilir, geçiş sırasında sorun yaşayan hesaplar yönetilebilir ve yeni araçta beklenmedik bir problem çıkarsa geri dönülecek bir nokta kalır.
Geçiş dönemi nasıl planlanmalı?
İlk bir veya iki hafta, daha az kritik beş ila on hesapla küçük ölçekli bir pilot migration yapın ve gerçek iş akışını baştan sona çalıştırın. Burada doğrulanması gereken şey, yeni aracın gerçek işi kaldırıp kaldıramadığıdır; özellik listesinin uzunluğu değil.
Ardından iki ila dört haftalık bir gözlem dönemi gelir. Operasyonları mümkün olduğunca önceki düzene yakın tutun ve iki tarafta hesap kararlılığını, doğrulama tetiklenme sıklığını ve görev başarı oranını karşılaştırın. Yeni ortam bu aşamada açıkça daha kötüyse geri dönüş maliyeti hâlâ düşüktür.
Son olarak iş önemine göre gruplar halinde migration yapın. Aynı gruptaki hesapların yeniden oturum açmasını aynı anda yoğunlaştırmayın. Migration sırasında içerik stratejisini değiştirmek gibi başka değişkenleri de eşzamanlı değiştirmemeye çalışın; aksi hâlde bir sorun çıktığında nedenini ayırmak zorlaşır.
Sık görülen değerlendirme hataları
Yalnızca yazılım fiyatına bakarak migration kararı vermek, görünen maliyeti toplam maliyet sanmaktır. İnsan emeği, geçiş dönemindeki iş dalgalanmaları ve olası hesap kayıpları çoğu zaman yazılımdan sağlanan tasarruftan çok daha fazlasına ulaşır.
Başka bir hata, sırf migration yapmak için migration yapmaktır. Mevcut araç ihtiyaçları karşılıyorsa yeni aracın daha fazla özelliğe sahip olması tek başına değişimi haklı çıkarmayabilir. Önce mevcut aracın hangi somut durumlarda yetersiz kaldığını listeleyin, sonra yeni aracın bu sorunları çözüp çözmediğini değerlendirin.
En riskli yaklaşım tüm hesapları aynı anda taşımaktır. Böylece tüm risk tek bir zaman noktasında toplanır ve bir sorun çıktığında elde hiçbir geri dönüş yolu kalmaz.
Karar vermeden önce üç soruyu yanıtlayın
Mevcut aracın somut sorunu nedir? Yanıt, sadece kullanımı kötü hissettiriyor demek yerine belirli senaryolara dayanmalıdır. Yeni araç bu sorunları kesin olarak çözebiliyor mu, tercihen pilot aşamasında doğrulanmış mı? Migration başarısız olursa maliyet nedir, geri dönüş mümkün mü ve ne kadar sürer?
Üç sorunun da açık yanıtı olduğunda harekete geçin.
