Eski (Legacy) Yazılımı Modernleştirme: Yeniden Yazmak mı, Kademeli Geçiş mi?

İşinizi yıllardır döndüren o eski yazılım artık yavaş, kimse dokunmaya cesaret edemiyor ve onu bilen tek kişi emekliliğe yaklaşıyor. Bu noktada iki yol belirir: her şeyi sıfırdan yazmak ya da kademeli geçiş. Sahadaki deneyimimiz net: kritik ve büyük sistemlerde kademeli (strangler fig) yaklaşım, big-bang yeniden yazıma göre neredeyse her zaman daha düşük riskli ve daha öngörülebilirdir; komple yeniden yazım ise ancak belirli koşullarda doğru tercihtir. Bu yazıda kararı hangi kriterlere göre vereceğinizi anlatıyoruz.

Bir yazılım ne zaman “legacy” sayılır?

Yaş tek başına ölçüt değildir; on yıllık ama bakımlı bir sistem sorunsuz çalışabilir. Asıl işaretler şunlardır:

• Küçük bir değişiklik bile haftalar sürüyor ve başka yerleri bozuyor.
• Teknolojisi (dil, veritabanı, işletim sistemi) artık destek almıyor; güvenlik yamaları gelmiyor.
• Sistemi bilen 1-2 kişiye kritik bağımlılık var; belgeler eksik veya güncel değil.
• Yeni sistemlerle entegrasyon (e-fatura, e-ticaret, mobil) zorlama çözümlerle yürüyor.
• Donanım veya lisans kısıtları büyümeyi engelliyor.

Bu belirtiler biriktikçe asıl maliyet, görünen bakım gideri değil, kaçan fırsatlar ve büyüyen risktir. Bu birikimin mekanik tarafını teknik borç yazımızda ele almıştık.

Big-bang yeniden yazım neden risklidir?

“En temizi sıfırdan yazalım” cazip gelir; ama büyük sistemlerde bu yolun bilinen tuzakları vardır. Eski sistemin içinde yıllarca birikmiş, hiçbir belgede yazmayan iş kuralları vardır; yeniden yazım bunların tamamını bir kerede keşfetmek zorundadır. Proje süresi uzadıkça iş tarafının ihtiyaçları değişir ve hedef sürekli kayar. En kritiği: aylarca süren geliştirme boyunca işletmeye hiçbir ara değer teslim edilmez ve geçiş günü her şey aynı anda değişir — hata da o gün, en pahalı hâliyle ortaya çıkar.

Bir de psikolojik tuzak vardır: yeniden yazım projeleri “madem sıfırdan yapıyoruz, şunu da ekleyelim” cümlesiyle kapsamını sürekli büyütür. Eski sistemi birebir karşılamak zaten büyük iştir; üstüne eklenen her yeni istek, geçiş gününü biraz daha uzağa iter. Disiplinli kural şudur: önce mevcut işlevi karşıla ve geç, yeni özellikleri geçişten sonraki fazlara bırak.

Strangler fig yaklaşımı nasıl işler?

Strangler fig deseni, adını konak ağacın üzerinde büyüyüp onu zamanla saran incirden alır. Yazılımda karşılığı şudur: eski sistem çalışmaya devam ederken, işlevleri parça parça yeni sisteme taşınır ve eski sistem yavaşça “kurur”.

1. Ara katman kurulur: Kullanıcı ve entegrasyon trafiği bir yönlendirme katmanının (API/proxy) arkasına alınır; kimin eski, kimin yeni sisteme gideceğini bu katman belirler.
2. İlk modül seçilir: Genellikle sınırları net, riski düşük ama görünür fayda üreten bir modül (ör. raporlama veya müşteri ekranları) ile başlanır.
3. Modül modül geçilir: Her yeni modül hazır oldukça trafik ona yönlendirilir; eski modül bir süre yedekte tutulur.
4. Eski sistem emekli edilir: Son modül taşındığında eski sistem güvenle kapatılır.

Her adımda geri dönüş mümkündür ve işletme her fazda ölçülebilir fayda görür. Bu yaklaşım, mimari kararlarla da iç içedir; modül sınırlarının nasıl çizileceğini mikroservis mi, monolit mi? yazımızda tartışmıştık.

Big-bang mı, kademeli mi: karşılaştırma

Veri taşıma neden projenin en hassas kısmı?

Modernizasyonda kod yazmaktan daha çok sorun çıkaran alan veridir. Yıllarca birikmiş kayıtlar tekrar, tutarsızlık ve eksik alanlarla doludur. Sağlıklı bir taşıma şu adımlarla ilerler: veri envanteri ve kalite denetimi, alan eşleştirmesi, otomatik taşıma betikleri, gerçek veriyle en az 2-3 deneme taşıması ve geçiş sonrası mutabakat raporları. Kademeli geçişte ayrıca eski ve yeni sistemin bir süre aynı veriyi tutması gerekir; senkronizasyon stratejisi (tek yönlü mü, çift yönlü mü, hangi sistem “doğrunun kaynağı”) baştan netleşmelidir. Bu konuyu ERP veri taşıma yazımızda derinlemesine işledik.

Ne zaman komple yeniden yazım doğru olur?

Kademeli geçiş varsayılan yol olmalı; ama şu durumlarda sıfırdan yazım daha mantıklıdır:

• Sistem küçük ve sınırları net; toplam kapsam birkaç ayda yeniden üretilebilir.
• Teknoloji tamamen ölü: çalıştıracak ortam, uzman veya güvenlik yaması bulunamıyor.
• Veri modeli iş modelinizle temelden uyumsuz hâle gelmiş; ara katman maliyeti yeniden yazımı aşıyor.
• Yasal/güvenlik zorunlulukları mevcut mimaride karşılanamıyor.

Bu durumda bile “big-bang” olmak zorunda değildir: yeni sistem önce pilot bir birimde canlıya alınıp eski sistemle kısa süre paralel yürütülebilir.

Modernizasyona hangi modülden başlanmalı?

İlk modül seçimi, projenin kaderini belirler; çünkü organizasyonun yeni sisteme güveni bu ilk fazda kurulur. Doğru ilk aday üç özelliği taşır: sınırları net (başka modüllerle bağı az), teknik riski düşük ve faydası görünür. Pratikte en sık raporlama/dashboard katmanı, müşteri veya bayi portali gibi salt-okur ekranlar ya da eski sistemin hiç kapsamadığı yeni bir ihtiyaç (mobil saha uygulaması gibi) seçilir.

Kaçınılması gereken ise tersini yapmak: en karmaşık ve en kritik modülle (ör. faturalama veya üretim planlama çekirdeği) başlamak. O modüller, ekip ara katmanda ve veri senkronizasyonunda tecrübe kazandıktan sonra, genellikle orta fazlarda ele alınmalıdır.

İş sürekliliği için pratik kurallar

• Yoğun sezonu geçiş takviminden çıkarın; geçişleri düşük tempolu dönemlere planlayın.
• Her faz için yazılı geri dönüş (rollback) planı ve karar kriteri belirleyin.
• Kullanıcı eğitimini geçişten önce tamamlayın; ilk haftalarda destek kapasitesini artırın.
• Başarıyı ölçün: işlem süresi, hata oranı, kullanıcı memnuniyeti fazdan faza raporlansın.

QuantKOD olarak modernizasyon projelerine her zaman bir keşif fazıyla başlıyoruz: mevcut sistemin envanteri, gizli iş kurallarının dokümantasyonu ve faz planı çıkarılmadan tek satır kod yazılmıyor. Maliyet tarafında küçük bir iç uygulamanın modernizasyonu 2026 Türkiye koşullarında kabaca ₺300.000'den başlıyor; çok modüllü kurumsal sistemlerde bütçe kapsamla birlikte büyüyor ve faz faz onaylanabiliyor. Yönetim tarafındaki iyi pratikler için özel yazılım projesi nasıl yönetilir? rehberimize, çalışma modelimiz için süreç sayfamıza göz atabilirsiniz.