Eski yazılım yenileme (legacy modernizasyon), bir uygulamanın iş kurallarını ve verisini koruyarak teknolojisini, mimarisini ya da çalıştığı ortamı güncellemektir. Doğru yöntem her zaman sıfırdan yazmak değildir: bazı modüller olduğu gibi kalır, bazıları API ile dışarı açılır, bazıları yeniden yazılır. Karar, her modülün iş değerine ve teknik riskine bakılarak verilir.
Kısaca
- Eski yazılım yenileme, iş kurallarını ve veriyi koruyarak uygulamanın teknolojisini, mimarisini ya da çalıştığı ortamı güncellemektir.
- Yöntem modül bazında seçilir: koru, sarmala, yeniden barındır, platform yükselt, yeniden yapılandır, yeniden yaz ya da değiştir.
- Kademeli geçişte (strangler fig deseni) eski ve yeni sistem bir süre yan yana çalışır; iş durmadan modül modül geçilir.
- Verizon DBIR 2026'ya göre zafiyet istismarı %31 ile ihlallerde en yaygın ilk erişim yolu; desteği biten bileşenler bu riski büyütür.
- Yeni projede kaynak kodun, veritabanı şemasının ve belgelerin şirkete devri sözleşmeyle güvenceye alınmalıdır.
Eski yazılım nasıl "eski" olur? Tanıdık belirtiler
Çoğu şirkette bu yazılımın bir hikâyesi vardır: on yıl önce bir çalışan ya da küçük bir yazılım evi yazmıştır, işin tam ortasındadır ve "çalışıyor, dokunmayalım" denir. Sipariş, üretim takibi, cari hesap ya da servis kayıtları bu programda tutulur. Sorun, programın bozulması değil; etrafındaki dünyanın değişmesidir.
Belirtiler genellikle şunlardır:
- Program yalnızca belirli bir işletim sistemi sürümünde ya da tek bir sunucuda çalışıyor; o makineye kimse dokunmaya cesaret edemiyor.
- Kodu bilen tek kişi ayrıldı ya da emekliliğe yaklaşıyor; kaynak kodun tamamının şirkette olup olmadığı belli değil.
- Yeni bir alan eklemek haftalar sürüyor, çünkü her değişiklik başka bir yeri bozuyor.
- e-Fatura, pazaryeri ya da banka ile bağlantı için ara çözümler, Excel aktarımları ve elle kopyalama kullanılıyor.
- Uygulama sahadan, telefondan ya da tarayıcıdan erişilemiyor; uzaktan çalışma için ekran paylaşımı kullanılıyor.
Eski yazılımın bu belirtilerinin çoğu, Excel ile iş takibinin sınırlarına takılan şirketlerin yaşadıklarına benzer. Fark şudur: burada elinizde işleyen, iş kurallarını taşıyan ve yıllarca biriken veriye sahip bir sistem vardır. Bu birikim, yenilemenin hem en değerli varlığı hem de en büyük riskidir.
Eski yazılımı yenilemeyi ertelemenin maliyeti nedir?
Eski yazılımı yenilemeyi ertelemenin ilk maliyeti kişiye bağımlılıktır. Türkiye İstatistik Kurumu'nun Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2026 sonuçlarına göre girişimlerin yalnızca %15,2'si bilgi ve iletişim teknolojileri (BİT) uzmanı istihdam ediyor; 10-49 çalışanlı girişimlerde bu oran %10,8. BİT uzmanı arayanların %31,7'si işe alımda güçlük yaşadığını bildirmiş. Yani eski teknolojiyi bilen kişi ayrıldığında yerine birini bulmak kolay değildir.
İkinci maliyet güvenliktir. Desteği bitmiş bir çalışma zamanı, eski bir veritabanı sürümü ya da güncellenemeyen bir kütüphane artık yama almaz. Verizon 2026 Veri İhlali Araştırmaları Raporu (DBIR) zafiyet istismarının %31 ile ihlallerde en yaygın ilk erişim yolu olduğunu gösteriyor. Eski bileşenler envanterde görünür olmadıkça yama yönetimi süreci de onlara ulaşamaz.
Verizon DBIR 2026'ya göre Şubat 2026 itibarıyla ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı'nın (CISA) Bilinen İstismar Edilen Zafiyetler (KEV) kataloğunda 1.526 CVE (kamuya açık zafiyet kaydı) vardı ve bunların 991'inde son 12 ayda istismar faaliyeti görüldü. Eski zafiyetler kendiliğinden emekli olmuyor.
Üçüncü maliyet veri ve entegrasyon baskısıdır. Dış sistemlerle veri alışverişi hızla yaygınlaşıyor: Gelir İdaresi Başkanlığı'nın 2025 Yılı Faaliyet Raporuna göre e-Fatura uygulamasından yararlanan mükellef sayısı 2021'deki 532.910'dan 2025 sonunda 1.937.308'e çıktı. Temiz veri alışverişi yapamayan eski uygulamalar bu yükü insanlara aktarır. Üstelik eski sistemlerde aynı müşteri üç farklı yazımla kayıtlıdır, alanlar amacından farklı kullanılmıştır ve kurallar kodun içine gömülüdür. Bu dağınıklık sonradan yapılacak her geçişi zorlaştırır; bu yüzden mükerrer kayıt temizliği planın başına konmalıdır.
Eski yazılım yenileme seçenekleri nelerdir? 7 yolun karşılaştırması
Eski yazılım modernizasyonu tek bir karar değil, her modül için ayrı verilen bir dizi karardır. Aşağıdaki tablo sektörde yaygın kullanılan seçenekleri özetliyor; bir projede genellikle birkaçı birlikte kullanılır.
| Seçenek | Ne yapılır? | Ne zaman uygun? | Başlıca risk |
|---|---|---|---|
| Koru | Kod değişmez, yalnızca ortam güvenceye alınır | Az değişen, kritik olmayan modüller | Sorun ertelenir, çözülmez |
| Sarmala (API ile dışa aç) | Eski sistemin önüne API katmanı konur | Veri ve kural doğru, erişim sorunlu | Eski çekirdeğin kırılganlığı sürer |
| Yeniden barındır | Uygulama değişmeden yeni sunucuya ya da buluta taşınır | Donanım eskidi, kod hâlâ sağlam | Eski mimari yeni ortamda da aynı kalır |
| Platform yükselt | Çalışma zamanı, veritabanı ya da çerçeve sürümü güncellenir | Destek süresi biten bileşenler var | Beklenmedik uyumsuzluklar |
| Yeniden yapılandır | Kod davranış değişmeden temizlenir, modüllere ayrılır | Kod bilinir, ekip içeride | Test yoksa gerileme hataları |
| Yeniden yaz | Modül güncel teknolojiyle baştan geliştirilir | İş kuralları net, eski kod bakılamaz | Kapsam kayması, gizli kuralların kaybı |
| Değiştir ya da emekliye ayır | Hazır ürün alınır ya da modül kapatılır | Süreç standart ya da artık kullanılmıyor | Veri taşıma ve alışkanlık direnci |
"Yeniden yaz" ile "değiştir" arasındaki seçim, özel yazılım mı hazır paket mi sorusunun modernizasyondaki karşılığıdır. Yeni sistemin nerede çalışacağına ise SaaS mı kurulu yazılım mı karşılaştırması üzerinden karar vermek gerekir.
Eski yazılım nasıl modernize edilir? 8 adımlı yol haritası
Aşağıdaki sekiz adım bir eski yazılım yenileme projesini "tek seferde her şeyi yeniden yazalım" tuzağından uzak tutar. Her adımın çıktısı bir sonrakinin girdisidir.
- Envanter çıkarın. Modülleri, ekranları, raporları, zamanlanmış işleri, dış bağlantıları ve veritabanı tablolarını listeleyin. Kaynak kodun ve kurulum bilgisinin gerçekten elinizde olduğunu doğrulayın.
- Gizli iş kurallarını yazıya dökün. İskonto hesabı, stok düşme sırası, onay limitleri gibi kurallar çoğu zaman yalnızca kodda yaşar. Kullanıcılarla oturup "program bunu neden böyle yapıyor?" sorusunu sorun; bu, bir yazılım ihtiyaç analizinin modernizasyona uyarlanmış hâlidir.
- Her modülü puanlayın. İş değeri (ne kadar kullanılıyor, gelire etkisi) ve teknik risk (destek durumu, bilen kişi sayısı, hata sıklığı) üzerinden basit bir matris kurun. Yüksek risk ve yüksek değer taşıyan modüller önceliklidir.
- Her modüle bir seçenek atayın. Yedi seçeneği karşılaştıran tabloyu kullanın; tümüne aynı yöntemi uygulamak nadiren doğrudur.
- Veri taşıma planını erkenden yapın. Alan eşlemesi, temizlik kuralları, deneme taşımaları ve karşılaştırma raporları projenin sonuna bırakılmamalıdır.
- Kademeli geçişi tasarlayın. Eski ve yeni sistem bir süre yan yana çalışır; aradaki köprü API ya da ortak veri katmanıdır. Hangi işlemin hangi sistemden yürüyeceği her aşamada açıkça yazılır.
- Kabul testlerini eski sistemin davranışına göre yazın. Aynı girdiyle eski ve yeni sistemin aynı sonucu ürettiğini gösteren test setleri, güvenilir bir kabul ölçütüdür.
- Eski modülü planlı kapatın. Kullanıcıların yeni sisteme geçtiği doğrulandıktan sonra eski modül salt okunur yapılır, verisi arşivlenir ve sonra kapatılır.
Bütçe tarafında bu adımların hangi kalemleri doğurduğunu yazılım projesi maliyeti yazımızda ayrıntılı anlatıyoruz. Sözleşme aşamasında da kaynak kodun, veritabanı şemasının ve belgelerin size devrini yazılım sözleşmesinde kaynak kodu başlıklı rehberdeki maddelerle güvenceye alın; aksi hâlde bugünkü sorunu on yıl sonra yeniden yaşarsınız.
Büyük patlama mı, kademeli geçiş mi? Strangler fig deseni
"Her şeyi baştan yazıp bir hafta sonu geçelim" diye özetlenen büyük patlama (big-bang) geçişi cazip görünür ama risklidir. Boston Consulting Group'un (BCG) 2020'de yayımladığı, üst düzey yöneticilerle yapılan dijital dönüşüm araştırması, dijital dönüşümlerin %70'inin hedeflerinin gerisinde kaldığını ortaya koyuyor. Büyük tek seferlik geçişlerde gizli iş kuralları çoğu zaman ancak canlıya geçince fark edilir ve geri dönmek zordur. Modernizasyonu şirket genelindeki önceliklerle hizalamak için dijital dönüşüm yol haritası rehberimize de bakabilirsiniz.
Kademeli yöntemde (literatürde "strangler fig" yani sarmaşık deseni olarak geçer) yeni sistem eski sistemin etrafında büyür. Önce bir modül yenilenir, trafik ona yönlendirilir, eski karşılığı kapatılır; sonra sıradakine geçilir. Bu yaklaşımın ön koşulu iki sistemin veri paylaşabilmesidir, bu yüzden API entegrasyonu çoğu modernizasyon projesinin ilk teknik işidir.
Kademeli geçişin bedeli, bir süre iki sistemi birlikte işletmektir. Bu dönemde senkronizasyon hataları, kullanıcı kafa karışıklığı ve çift bakım yükü oluşur. Yine de riskin küçük parçalara bölünmesi, ERP projelerinin neden başarısız olduğuna bakınca görülen kapsam ve takvim kaymalarına karşı güçlü bir korumadır.
Aynı mantık yazılım dışında da geçerlidir. Makinelerde eski makineleri dijitalleştirme yaklaşımı ekipmanı atmadan veri toplamayı, geçiş kontrol sistemi değiştirme rehberi ise kart ve donanımı koruyarak yazılımı yenilemeyi anlatır.
Digital Bridge'de eski yazılımı nasıl yeniliyoruz
Hazır bir "modernizasyon paketi" satmıyoruz; önce mevcut sistemi tanıyoruz. Keşif aşamasında kaynak kodu, veritabanını, kullanıcı iş akışlarını ve dış bağlantıları inceliyor, modül bazında bir envanter ve risk tablosu çıkarıyoruz. Bu çalışmanın sonunda kapsamı, aşamaları ve bedeli belirten yazılı bir teklif sunuyoruz.
Uygulamada genellikle en çok acı veren tek bir modülle başlıyoruz. Bu modülü firmaya özel web yazılımı olarak yeniden geliştiriyor, eski sistemle API entegrasyonu üzerinden konuşturuyor ve gerçek kullanıcılarla pilot olarak çalıştırıyoruz. Pilot başarılı olunca sıradaki modüle geçiyoruz; kaynak kodu, veritabanı şeması ve teknik belgeler size teslim ediliyor.
ERP, muhasebe, e-Fatura ve üretim sistemleriyle konuşan yapılarda entegre yazılım sistemleri ekibimiz veri akışını tek bir düzene oturtuyor. Barındırma ortamı değişecekse bulut geçiş ve altyapı danışmanlığı kapsamında hedef mimariyi, yedekleme ve geri dönüş planını birlikte kuruyoruz; bu aşamada buluta geçiş maliyetinin görünmeyen kalemlerini de masaya koyuyoruz.
Eski bileşenler geçiş süresince açık kaldığı için güvenliği ayrı ele alıyoruz. Desteği biten bileşenler için ağ ayrımı, erişim kısıtlaması ve izleme gibi telafi edici önlemleri siber güvenlik danışmanlığı kapsamında planlıyoruz. Proje boyunca yükleniciden hangi ara çıktıları talep etmeniz gerektiğini yazılım projesi yüklenici denetimi yazımızda anlattık.
Sonraki adım
Eski yazılımınızın hangi modülünün önce ele alınması gerektiğini birlikte netleştirelim. Mevcut sistemin kısa bir tanımını, kullanılan teknolojiyi ve en çok zorlandığınız süreci iletişim sayfamızdan paylaşın; keşif görüşmesinde modül envanteri ve öncelik sırası üzerine konuşalım. Diğer rehberler için Yazılım Geliştirme yazılarımıza göz atabilirsiniz.