Çalışan ama eskimiş bir uygulamayı bir anda yeniden yazmak çoğu zaman gereksiz risk yaratır. Bu rehber, eski yazılım modernizasyonunu envanter, kademeli geçiş ve iş sürekliliği odaklı bir planla nasıl yürüteceğinizi anlatır.
Eski yazılım modernizasyonu, hâlâ iş gören ama bakımı, güvenliği veya entegrasyonu zorlaşmış uygulamaları kontrollü biçimde yenileme sürecidir. Amaç, sistemi bir gecede sıfırdan yazmak değil; iş kesintisini sınırlayarak değeri koruyan parçaları güncellemek ve riski adım adım azaltmaktır. Bu rehber, çalışan bir legacy uygulamayı kademeli modernizasyon stratejisiyle planlamak isteyen ekipler için hazırlanmıştır.
Birçok işletmede sipariş, stok, saha operasyonu veya muhasebe akışı yıllardır aynı çekirdek yazılım üzerinde yürür. Uygulama “çalışıyor” görünse de yama almak zordur, yeni entegrasyonlar kırılgandır ve bilgi yalnızca birkaç kişide toplanmıştır. Aşağıdaki plan, bu tabloyu yönetilebilir parçalara ayırır.
Eski yazılım modernizasyonu ne zaman gerekir?
Her eski sistem acil modernizasyon adayı değildir. Kararı, teknik borç listesinden çok iş etkisi belirler. Aşağıdaki işaretler bir araya geldiğinde planlamayı ertelemek pahalıya mal olabilir:
- Güvenlik yamaları veya bağımlılık güncellemeleri uygulanamıyor ya da her güncelleme regrese yol açıyor.
- Yeni bir ödeme, kargo, CRM veya e-belge entegrasyonu haftalarca sürüyor veya hiç bağlanamıyor.
- Kaynak kod, sunucu ve veritabanı bilgisi yalnızca bir-iki kişide; izin, yedek ve devir belgesi dağınık.
- Raporlama için sürekli Excel dışa aktarımı ve manuel birleştirme yapılıyor.
- Mobil erişim, API veya çok şubeli kullanım ihtiyacı var ama mimari buna kapalı.
- Lisans, işletim sistemi veya barındırma desteği sona eriyor; yedek ve felaket kurtarma belirsiz.
Bu işaretler “hemen her şeyi yeniden yaz” demek değildir. Önce hangi modülün işi durdurduğu, hangisinin yalnızca rahatsız ettiği netleştirilmelidir.
Büyük yeniden yazım neden çoğu zaman risklidir?
Tek seferlik “big bang” yeniden yazım cazip görünür: temiz mimari, yeni arayüz, sıfır eski kod. Pratikte ise kapsam şişer, paralel işletme maliyeti artar ve canlıya geçiş günü tek bir hata noktasına dönüşür. Eski sistemdeki örtük iş kuralları (istisnalar, özel indirimler, saha alışkanlıkları) çoğu zaman belgede yoktur; bunlar ancak kullanım sırasında ortaya çıkar.
Kademeli yaklaşımda hedef, çalışan değeri korumak ve her adımda ölçülebilir bir iyileşme bırakmaktır. Yeni özellikler modern katmanda doğar; kritik akışlar kontrollü biçimde taşınır; eski parça zamanla daralır. Böylece ekip hem işi sürdürür hem de öğrenme eğrisini yönetir.
Modernizasyon yaklaşımlarını seçmek
Tüm legacy sistemler için tek doğru yöntem yoktur. Aşağıdaki tablo, karar verirken sık kullanılan yaklaşımları özetler. Bir projede birden fazla yaklaşım, modül bazında bir arada da kullanılabilir.
| Yaklaşım | Ne zaman uygun? | Dikkat edilecek nokta |
|---|---|---|
| Yeniden barındırma (rehost) | Altyapı riski yüksek, kod değişmeden önce güvenlik ve yedek iyileştirilecekse | Teknik borç kalır; yalnızca ortamı güçlendirir |
| Yeniden platformlama | Eski dil/çatı desteklenmiyor, orta düzey uyum yeterliyse | Uyumluluk testleri kritiktir |
| Yeniden düzenleme (refactor) | İş kuralları doğru, kod okunaksız ve test edilemiyorsa | Kapsamı dar tutun; “fırsat buldukça yenileme” tuzağına düşmeyin |
| Strangler (boğucu sarmaşık) geçişi | Büyük monolit; yeni özellikler ayrı servis/UI ile doğacaksa | API sözleşmeleri ve yönlendirme disiplini şart |
| Seçici yeniden yazım | Belirli bir modül işi kilitleyorsa, geri kalanı makulse | Veri sahipliği ve tek kaynak gerçeği net olmalı |
| Tam yeniden yazım | Ürün stratejisi kökten değiştiyse ve paralel işletme bütçesi varsa | Kapsam kayması ve veri taşıma en büyük risklerdir |
Türkiye’de hâlâ aktif PHP/MySQL tabanlı kurumsal paneller ve masaüstü istemcili sistemler yaygındır. Bu tür yapılarda çoğu zaman önce arayüz ve raporlama katmanı ayrılır; çekirdek veri modeli kontrollü taşınır. İhtiyaca göre özel PHP/MySQL yazılım birikimini koruyarak modern API ve arayüz katmanı eklemek, sıfırdan başlamakten daha düşük kesinti riski taşıyabilir.
Legacy envanter ve öncelik haritası
Planın ilk somut çıktısı bir envanterdir. Envanter olmadan modernizasyon tahmine dönüşür.
Teknik envanter
- Kaynak kod depoları, dallanma modeli, derleme/yayın adımları
- Çalışma ortamı: sunucu, veritabanı sürümü, zamanlanmış işler, dosya paylaşımları
- Dış bağımlılıklar: ödeme, SMS, e-posta, e-belge, ERP, banka, kargo
- Gizli yapılandırmalar, sertifikalar, API anahtarları ve erişim hesapları
- Yedek alma sıklığı, geri yükleme testi yapılıp yapılmadığı
İş envanteri
- Günlük/haftalık kritik akışlar (sipariş alma, stok düşümü, faturalama, saha kapanışı)
- Rol bazlı kullanıcılar ve yetki matrisi
- İstisna kuralları: manuel düzeltmeler, “sistemde yok ama yapıyoruz” adımları
- Rapor tüketicileri: kim hangi çıktıyı ne sıklıkla kullanıyor?
Önceliklendirme
Her modülü iki eksende puanlayın: iş etkisi ve modernizasyon aciliyeti. Yüksek etki + yüksek aciliyet parçalar ilk dalgaya alınır. Düşük etki parçalar “olduğu gibi bırak / izole et” kutusuna gidebilir. Bu sıralama, bütçeyi herkese yedirmek yerine darboğazı çözmeye yönlendirir.
Kademeli yenileme planı: adım adım
Aşağıdaki sıra çoğu ticari uygulamada işe yarar. Süre iddiası vermeden, karar kapılarını net tutmak önemlidir.
- Hedef ve başarı ölçütlerini yazın. “Daha modern olsun” yeterli değildir. Örneğin: yeni entegrasyon eklenebilirlik, yedeklenebilirlik, yetki denetimi, belirli bir sürecin manuel adım sayısının düşmesi.
- Sınırları çizin. Hangi süreç bu projede, hangisi bilinçli olarak dışarıda? Kapsam kaymasını engellemek için değişiklik talebi kuralı baştan konur.
- Hedef mimariyi sade tutun. İlk adımda mikroservis ordusu kurmak şart değildir. Net API sınırları, tek veri sahipliği ve izlenebilir log çoğu projede yeterlidir.
- Strangler veya modül dalgaları tasarlayın. Yeni kullanıcı arayüzü eski API’ye, ya da yeni servis eski veritabanına kontrollü bakabilir; önemli olan geçiş sözleşmesinin yazılı olmasıdır.
- Veri modelini ve taşıma senaryosunu ayırın. Alan eşlemesi, tekilleştirme, tarihsel kayıt ve geri alma planı ayrı iş paketidir.
- Paralel işletme ve kesme noktası belirleyin. Kim, hangi günde, hangi kontrol listesiyle eski ekranı kapatır? Geri dönüş kriteri önceden yazılır.
- Gözlemlenebilirlik ekleyin. Hata logu, iş metrikleri ve kullanıcı geri bildirimi olmadan “geçti” demek erken olur.
KepezWeb gibi ekiplerle çalışırken bu adımların teklif ve yol haritasına yansıması, geliştirme hızından önce belirsizliği azaltır. Yazılım geliştirme sürecinde modernizasyon, yeşil alan üründen farklı olarak keşif ve devir yükü taşır; bunu plan kalemine yazmak gerekir.
Veri, entegrasyon ve iş sürekliliği
Legacy yenilemede en sık sızıntı veri ve entegrasyon hattında olur. Ekran yenilenir, rapor bozulur; API ayağa kalkar, gece batch’i unutulur.
- Kaynak gerçek tek olsun. Aynı müşteri veya stok kaydı iki sistemde “asıl” kabul edilmesin. Geçiş süresince yazma yönü net tanımlansın.
- Kimlik ve referans alanlarını sabitleyin. Eski kod, fatura no veya cari kod gibi iş anahtarları yeni kimliklerle eşlenmeden taşınırsa raporlar kırılır.
- Entegrasyonları sözleşmeye bağlayın. İstek/yanıt örnekleri, hata kodları, yeniden deneme ve zaman aşımı kuralları dokümante edilsin.
- Yedek ve geri yükleme prova edilsin. Yalnızca yedek almak yetmez; geri yükleme süresi ve doğrulama adımı bilinmelidir.
- Kullanıcı iletişimi planlansın. Eğitimsiz geçiş, teknik olarak doğru sistemde operasyonel kaosa yol açar.
Altyapı tarafında barındırma, erişim ve yedekleme kararları da modernizasyonun parçasıdır. Ortam seçimini sonraya bırakmak yerine, web hosting seçimi gibi teknik kararları envanterle birlikte ele almak kesinti riskini düşürür.
Test, kabul ve devir
Kademeli modernizasyonda test, projenin sonuna sıkıştırılacak bir formalite değildir. Her dalga kendi kabul kapısından geçmelidir.
- Kritik iş senaryoları (mutlu yol + istisnalar) iş birimi diliyle yazılsın.
- Regresyon seti: eski sistemde bozulmaması gereken akışlar listelensin.
- Performans ve yetki testleri, özellikle rapor ve toplu işlemlerde ayrı koşulsun.
- Canlıya alma sonrası izleme penceresi ve sorumlu kişi tanımlansın.
İş biriminin onayını almak için yazılım kabul testi (UAT) disiplini modernizasyon projelerinde özellikle değerlidir. Senaryolar gerçek verinin maskelenmiş kopyasıyla koşulursa hem güven artar hem sürpriz azalır.
Devir paketinde en az şunlar bulunmalıdır: mimari özet, ortam erişimleri, yayın runbook’u, bilinen kısıtlar, yedek/geri dönüş adımları ve destek iletişim zinciri. Kod teslim edilip belgesiz bırakılan sistemler, kısa sürede yeni bir legacy’ye dönüşür.
Sık yapılan hatalar
- Önce arayüzü yenileyip veri ve yetki modelini ertelemek
- “Madem yazıyoruz, şunu da ekleyelim” ile kapsamı şişirmek
- Örtük iş kurallarını kullanıcıyla doğrulamadan varsaymak
- Paralel işletme süresini plansız uzatmak
- Başarı ölçütünü yalnızca teknoloji yığını değişimine indirgemek
İyi bir eski yazılım modernizasyonu, teknoloji vitrini değil iş sürekliliği projesidir. Her sprint sonunda “hangi risk azaldı, hangi süreç sadeleşti?” sorusu sorulabilmelidir.
Sıkça Sorulan Sorular
Eski yazılım modernizasyonu ile sıfırdan yazılım aynı şey midir?
Hayır. Sıfırdan yazımda ürün çoğu zaman yeni bir kapsamla kurulur. Modernizasyonda mevcut iş değeri, veri ve entegrasyonlar korunarak kontrollü yenileme yapılır. Bazen sonunda büyük ölçüde yeni bir sistem doğsa da yol, riski parçalayan adımlarla ilerler.
Tüm sistemi bir anda değiştirmek hiç mantıklı olmaz mı?
Ürün stratejisi kökten değiştiyse, eski kod okunamıyorsa ve paralel işletme için bütçe ile ekip hazırsa tek seferlik geçiş düşünülebilir. Yine de veri taşıma, kabul testi ve geri dönüş planı olmadan bu yol yüksek risk taşır.
Hangi modülden başlamalıyız?
İş etkisi yüksek, teknik olarak izole edilebilir ve başarı ölçütü net olan parçadan başlayın. Çekirdek veri modelini ilk günden parçalamak yerine, raporlama, yeni kanal arayüzü veya tek bir entegrasyon hattı gibi sınırları daha net alanlar ilk dalga için uygundur.
Kullanıcıları ne zaman eğitime almalıyız?
Ekran veya süreç değişen her dalgadan önce, mümkünse gerçek senaryolarla. Eğitim yalnızca “menüler nerede” anlatımı olmamalı; istisna durumları ve eski alışkanlıkların yerini neyin aldığı da gösterilmelidir.
İç ekip yoksa modernizasyon yönetilebilir mi?
Evet, ancak iş kuralı sahipliği işletmede kalmalıdır. Dış ekip teknik uygulama ve plan disiplinini sağlar; kritik kararlar (öncelik, kabul, kesme noktası) işletme tarafında netleşmeden ilerlenmemelidir.
Eskimiş ama kritik bir uygulamanız varsa, önce envanter ve öncelik haritasıyla başlamak en güvenli adımdır. KepezWeb olarak web, e-ticaret ve özel yazılım projelerinde kademeli yenileme planını iş hedeflerinize göre netleştirebiliriz. Kapsamı ve yol haritasını konuşmak için teklif al sayfasından bize ulaşabilirsiniz.
