Eski Yazılım Yenileme: Teknik Borç ve Modernizasyon

Eski yazılım yenileme, çalışan bir sistemi durdurmadan modern altyapıya taşıma işidir. Kapsamlı projelerde bütçe, sıfırdan yapım bedeline oranla %25 ile %110 arasında; süre ise 2 ile 12 ay arasında değişir. Fiyatı etkileyen üç şey: kod kalitesi, veri hacmi ve entegrasyon sayısı.

Çoğu şirket bu kararı bir arıza gecesinde verir. Oysa yaşlanma sessiz ilerler. Ekip küçük bir değişiklik için üç hafta ister. Sunucu güncellemesi her çeyrek ertelenir. Yeni geliştirici kodu okumayı reddeder.

Bu üç belirtinin tek bir adı var: teknik borç.

CISQ'nun 2022 raporuna göre yalnız ABD'de birikmiş teknik borcun değeri ~1,52 trilyon dolar. Stack Overflow'un 2024 geliştirici anketinde teknik borç, profesyonel geliştiricilerin %62,4'ü için işteki bir numaralı sıkıntı.

Yani sorun sizin ekibinize özgü değil. Teknik borç, belirli bir ekibin hatası değil; yazılımın doğal yaşlanma biçimi.

Bu rehber iki soruyu ayrı ayrı yanıtlıyor: eski yazılım yenileme zamanı gerçekten doğru mu, ve doğruysa işi durdurmadan nasıl geçersiniz.

İçindekiler

• Teknik Borç Nedir, Yazılımı Nasıl Yaşlandırır?
• Yenileme Zamanını Gösteren 8 Sinyal
• Altyapınızın 2026 Destek Takvimi
• Yedi Modernizasyon Stratejisi: Hangisi Size Uyar?
• Kademeli Geçiş: Strangler Yaklaşımı
• Veri Taşıma: Projelerin En Çok Battığı Yer
• Eski Yazılım Yenileme Bütçesi ve Takvimi
• Sıkça Sorulan Sorular

Teknik Borç Nedir, Yazılımı Nasıl Yaşlandırır?

Teknik borç, hızlı teslim etmek için kasten ya da farkında olmadan seçtiğiniz kısa yollardır. Her kısa yol faiz işletir: bir sonraki geliştirme biraz daha uzun sürer, test biraz daha zorlaşır, hata ayıklama biraz daha pahalılaşır.

Borç üç yerde birikir. Kodda: kopyalanmış iş kuralları, testsiz modüller, belgelenmemiş kararlar. Bağımlılıklarda: desteği bitmiş framework ve kütüphaneler. Veride: aynı bilgiyi üç farklı tabloda tutan şemalar, tip tutarsızlıkları, kullanılmayan sütun kalabalığı.

Bu üçü birleştiğinde "legacy sistem" dediğimiz tablo doğar. Legacy, eski demek değil; değiştirmekten korktuğunuz yazılım demek. Beş yıllık ama testleri olan bir sistem canlı sayarız. İki yıllık ama kimsenin dokunmaya cesaret etmediği bir sistem çoktan yaşlanmıştır.

Ayrımı somutlaştıran soru şu: son on değişiklikten kaçı plandaki sürede bitti? Yarısından azı bittiyse borcun faizi ürün hızınızı yiyor demektir.

Bu faizi üç kalemde ödersiniz. Birincisi hız: aynı işi yapmak her çeyrek biraz daha uzun sürer. İkincisi risk: testsiz bir modülde yapılan her değişiklik kumara dönüşür. Üçüncüsü insan kaynağı; deneyimli geliştiriciler desteği bitmiş teknolojide çalışmak istemez, ekip kurmanız pahalılaşır. Üç kalem de faturada ayrı satır olarak görünmez, bu yüzden yönetim tarafı borcu genellikle geç fark eder. Fark etme anı çoğu zaman bir müşteri talebinin "bu mimaride mümkün değil" cevabıyla döndüğü gündür.

Pazarın büyüklüğü bu sıkışmanın ölçüsünü veriyor. Grand View Research verilerine göre uygulama modernizasyonu hizmetleri pazarı 2025'te 24,3 milyar dolardı; 2026 beklentisi 28,3 milyar dolar, 2033 projeksiyonu ise 83,5 milyar dolar (%16,7 yıllık bileşik büyüme). Bu rakam, şirketlerin yeni ürün yapmak yerine mevcut ürünü kurtarmaya ne kadar bütçe ayırdığını gösteriyor.

Yenileme Zamanını Gösteren 8 Sinyal

Tek sinyal gerekçe sayılmaz. Üç ve üzeri sinyal aynı anda görünüyorsa, yamayla ilerlemek genellikle daha pahalıya patlar. Aşağıdaki sekiz maddeyi kendi sisteminizde tek tek işaretleyin.

1. Çalıştığı sürüm artık güvenlik yaması almıyor. En sert sinyal budur; bir alt bölümde takvimi veriyoruz.
2. Küçük bir değişiklik haftalar sürüyor. Fiyat alanına bir ondalık eklemek sprint konusu olduysa mimari sizi engelliyor.
3. Yeni geliştirici üç ayda devralamıyor. Devralma süresi, kodun ne kadar anlaşılır olduğunu en dürüst şekilde ölçer.
4. Entegrasyon imkânsızlaşıyor. Sistem modern bir ödeme sağlayıcısına ya da e-belge servisine bağlanamıyorsa yalıtılmış demektir. API entegrasyonunun nasıl kurulduğunu ayrı bir yazıda anlattık.
5. Tek bir kişi her şeye hakim. O kişi izne çıktığında proje duruyorsa, risk teknik değil kurumsaldır.
6. Tedarikçi lisansı ya da sözleşmesi sizi kilitliyor. Kaynak kodun kimde olduğunu netleştirmeden yenileme planı yapmayın.
7. Raporları Excel'e aktarıp elde hazırlıyorsunuz. Veriyi dışarı taşıyıp manuel işlemek, yazılımın artık yetmediğini gösterir.
8. Sunucu maliyeti düşmüyor, artıyor. Eski sürümler modern donanımı verimli kullanmaz; fatura büyür, performans aynı yerde durur.

Sistemin teknik tarafını hızlı taramak için ücretsiz site analizi aracımızı çalıştırın, çıkan başlıkları bu listeyle karşılaştırın. İki liste örtüşüyorsa karar zaten verilmiş sayılır.

Sinyalleri sayarken bir ayrımı koruyun: can sıkıcı olan ile riskli olan aynı şey değil. Eski bir arayüz can sıkar ama şirketi durdurmaz; yamasız bir kütüphane ise tek bir gecede veri sızdırır. Önce ikinci gruptaki maddeleri kapatın, estetik tarafı aynı projenin ikinci fazına bırakın. Bu sıralama bütçeyi de rahatlatır, çünkü güvenlik tarafı genellikle toplam kapsamın küçük bir dilimidir.

Güvenlik tarafı artık teorik bir risk değil. Verizon'un 19 Mayıs 2026 tarihli DBIR duyurusuna göre tüm ihlallerin yaklaşık üçte biri (%31) güvenlik açığı sömürüsüyle başlıyor. Rapor, 19 yıllık geçmişinde ilk kez açık sömürüsünü çalınmış kimlik bilgilerinin önüne, bir numaralı giriş yolu konumuna yerleştirdi.

ABD siber güvenlik ajansı CISA ise desteği bitmiş yazılım kullanımını doğrudan "kötü uygulamalar" kataloğuna aldı ve bu tercihi internete açık sistemlerde "özellikle vahim" diye tanımladı.

Türkiye'de tablonun hukuki tarafı da var. KVKK'nın Kişisel Veri Güvenliği Rehberi, "yama yönetimi ve yazılım güncellemeleri" ile sistemlerin düzenli kontrolünü teknik tedbirler arasında açıkça sayıyor. Desteği bitmiş bir sürümde kişisel veri işleyen şirket, bu tedbiri gösteremez.

Bir ihlal yaşandığında ilk sorulacak soru da tam burada: yamalar güncel miydi?

Altyapınızın 2026 Destek Takvimi

Yazılımınız yalnız sizin kodunuzdan oluşmaz. Altında dil, veritabanı, işletim sistemi ve arayüz kütüphanesi durur. Bunların her birinin bir son kullanma tarihi var ve bu tarihler sizin yayın takviminizi sormaz.

Tarihleri resmi kaynaktan doğrulayın: php.net destek takvimi, Microsoft .NET destek politikası, Node.js sürüm takvimi ve bileşen bazında endoflife.date.

Tablonun pratik okuması şu: .NET 8 üzerinde duran bir kurumsal uygulamanın güvenlik yaması akışı Kasım 2026'da sona eriyor. PHP 8.1 kullanan bir yönetim paneli ise zaten yamasız çalışıyor. Bu iki durum "ileride bakarız" kategorisine girmez.

Bir uyarı daha: destek tarihi geçmiş bir bileşen tek başına sistemi çökertmez. Tehlike bileşik etkide. Eski PHP sürümü yeni kütüphaneyi kabul etmez, yeni kütüphane olmadan modern ödeme entegrasyonu çalışmaz, böylece iş tarafındaki bir istek teknik bir duvara çarpar. Yenileme kararının asıl tetikleyicisi genellikle bu zincirdir.

Takvimi yönetmenin pratik yolu bir envanter tablosu tutmak. Üç sütun yeter: bileşen adı, çalışan sürüm, destek bitiş tarihi. Tabloyu her çeyrek açın ve 12 ay içinde biteceklere bakın. Bu alışkanlık yenilemeyi bir krize değil, planlanmış bir bakım kalemine dönüştürür. Maliyet farkı da buradan doğar: zamanında yapılan sürüm yükseltmesi haftalarla ölçülür, yıllarca ertelenmiş olanı ise mimari değişikliğe dönüşür ve aylara yayılır.

Yedi Modernizasyon Stratejisi: Hangisi Size Uyar?

Yenileme "sıfırdan yazmak" demek değil. AWS'nin göç stratejileri rehberinde tanımlanan yedi yol (7R), kararı ucuzdan pahalıya sıralar ve her birinin kendi tetikleyicisi var.

AWS'nin kendi uyarısı önemli: refactor en karmaşık ve en pahalı yoldur. Çok sistemli göçlerde önce taşıma, sonra modernizasyon öneriyor. Pratikte sağlıklı bir plan karma çıkar — raporlama modülü retire, ödeme servisi refactor, muhasebe entegrasyonu replatform.

Yanlış strateji seçmenin tipik sonucu şudur: ekip her şeyi refactor eder, 9 ay sürer, bu sürede ürün hiçbir yeni özellik kazanmaz ve iş tarafı projeye olan güvenini kaybeder. Oysa aynı sistemde modüllerin yarısı rehost ile üç haftada taşınabilirdi.

Doğru stratejiyi masa başında seçemezsiniz; iki haftalık bir değerlendirme gerekir. O iki haftada şu dört çıktıyı üretin: modül envanteri ve her modülün son 12 aydaki değişiklik sayısı, bağımlılık listesi ve destek durumu, veri hacmi ve şema sağlığı raporu, bir de kritik iş akışlarının uçtan uca haritası. Değişiklik sayısı en yüksek modüller refactor adayı, hiç değişmeyenler ise rehost ya da retire adayıdır. Bu tabloyu çıkarmadan verilen her tahmin, sonradan "kapsam büyüdü" diye adlandırılan sürprizin kaynağı olur.

Karar tablosunu tamamlarken iki kaynağa daha bakın: hazır ürüne geçiş düşünüyorsanız KOBİ için ERP karşılaştırmamız, hazır platformdan özel koda çıkıyorsanız WordPress'ten özel kodlanmış siteye geçiş rehberimiz yol gösterir. Mobil tarafta aynı kararın karşılığını mobil uygulama yenileme yazımızda işledik; arayüz ve arama motoru tarafı için web sitesi yenileme rehberi daha uygun.

Kademeli Geçiş: Strangler Yaklaşımı

Tek seferde devreye alma ("big bang") en riskli yöntem. Modern standart, Microsoft'un strangler fig deseni adıyla belgelediği kademeli geçiş. Mantığı sade: eski sistemin önüne bir yönlendirici (facade) koyarsınız, işlevleri parça parça yeni tarafa taşırsınız.

Dört aşamada yürür:

1. Facade devreye girer. İstekler artık doğrudan eski sisteme değil, araya giren katmana ulaşır. İlk gün trafiğin tamamı yine eski tarafa gider; kullanıcı hiçbir fark görmez.
2. İşlevleri tek tek taşırsınız. Her sprint bir modülü yeni tarafa geçirir, yönlendirme kuralını günceller. Hata çıkarsa tek kuralı geri çevirirsiniz — tüm projeyi değil.
3. Eski sistemi kapatırsınız. Son bağımlılığı da taşıdığınızda eski taraf devreden çıkar.
4. Facade'ı kaldırırsınız. İstemci doğrudan yeni sistemle konuşur.

İki sistem bir süre yan yana çalışır. Microsoft bu dönem için anti-corruption layer (yalıtım katmanı) öneriyor: yeni sistemin tasarımını eski sistemin alışkanlıklarından koruyan bir çevirici. Bu katman olmadan yeni taraf, eskinin kurallarını miras alır ve bir süre sonra ikinci bir legacy sistem doğar.

Kaynak koda hiç dokunamadığınız durumlar için belge ikinci bir yol anlatıyor. İş mantığı saklı yordamlara gömülüyse, veritabanının kendisi yeni servislere mesaj yollar; alternatifi ise işlem kaydını okuyan change data capture akışı. Bu iki teknik, "kodu değiştiremiyoruz" cevabının yenileme projesini bitirmesini engeller.

Yöntemin sınırları da belgeli. Strangler yaklaşımı şu dört durumda uygun değil: istekleri araya girip yakalayamıyorsanız, eski sistemin kaynak kodu elinizde yoksa, sistem zaten küçük ve toptan değiştirmek kolaysa, ya da eski tarafı hızla tamamen kapatmanız gerekiyorsa. Dördüncü madde en sık atlanan: bir sözleşme ya da lisans sizi altı ay içinde çıkışa zorluyorsa kademeli plan yetişmez.

Veri Taşıma: Projelerin En Çok Battığı Yer

Yenileme projeleri kodda değil, veride batar. Oracle'ın veri taşıma rehberinin aktardığı Bloor Group verilerine göre veri taşıma projelerinin %80'inden fazlası süreyi ve/veya bütçeyi aşıyor; maliyet aşımı ortalama %30, süre aşımı ortalama %41. Aynı belgede Gartner'a atfedilen oran %83.

Neden bu kadar yüksek? Çünkü veri taşımayı genellikle projenin sonuna bırakırsınız ve sorunlar ancak canlıya geçiş haftasında görünür. O hafta ekip panikler, bütçe sıçrar.

Önleyici plan şu beş adımdan oluşur:

• Önce profilleme yapın. Hangi tabloda kaç kayıt var, kaçı boş, kaçı tekrar ediyor? Bu sayıları projenin ilk haftasında çıkarın, son haftasında değil.
• Temizliği eski tarafta bitirin. Bozuk veriyi yeni şemaya taşıyıp orada düzeltmek iki kat emek demek.
• Çift yazma dönemi kurun. Microsoft'un desen belgesi burada ETL ile ilk yükleme, ardından CDC ile sürekli eşitleme öneriyor.
• Mutabakat sayılarını karşılaştırın. Kayıt adedi, tutar toplamı ve tarih aralıkları iki tarafta eşleşmeden geçişi onaylamayın.
• Geri dönüş yolunu açık tutun. Eski tablolar ve eşitleme süreçleri yerinde durduğu sürece geri dönüş mümkün; sildikten sonra maliyeti katlanır. Bu yüzden eski nesneleri kaldırmak her modülde en son adımdır.

Türkiye'ye özgü bir not: e-belge tarafında şema ve zorunluluklar dönem dönem güncellenir. Taşıma planınızı yaparken e-fatura entegrasyonunun yeni sistemde hangi gün devreye gireceğini mali dönem başına denk getirin. Ay ortasında yapılan geçişler mutabakatı gereksiz yere zorlaştırır, çünkü aynı dönemin belgeleri iki sistemde parçalanır.

Eski Yazılım Yenileme Bütçesi ve Takvimi

Bütçeyi, mevcut sistemi sıfırdan yeniden yapmanın bedeline oranla konuşuruz. Aşağıdaki bantlar piyasa fiyat analizlerinden ve kendi proje kapsamlarımızdan çıkıyor; kesin teklifi her zaman kod incelemesinden sonra veririz.

Üç kalemi bütçeye baştan ekleyin, çünkü ilk tekliflerde en sık atlanan maddeler bunlar:

• Çift bakım dönemi. Geçiş sürerken iki sistem birlikte yaşar; bu dönemin bakım yükü ayrı bir maliyet. Kapsamı yazılım bakım sözleşmesinde yazılı hale getirin.
• Eşitlik (parity) çalışması. Eski sistemin belgelenmemiş küçük davranışlarını yeni tarafta tekrar üretmek, kalemlerin en çok şaşırtanı. "Şu rapor cuma günleri farklı sıralanıyordu" cümlesi bir sprint demek.
• Eğitim ve geçiş desteği. Kullanıcılar yeni ekranları öğrenirken destek talebi geçici olarak artar; ilk ayı buna göre planlayın.

Yeni bir sistem kurma senaryosunu da masaya koymak istiyorsanız, web sitesi fiyat hesaplayıcımızla referans bir bütçe çıkarıp yukarıdaki oranlarla karşılaştırın. Daha geniş bir çerçeve için yazılım yaptırma maliyeti rehberimiz kalem kalem ilerliyor.

Takvim tarafında tek kural var: eski yazılım yenileme projesini mali dönem sonuna, yoğun sezona ya da denetim haftasına denk getirmeyin. Perakendede kasım, muhasebede ocak, turizmde haziran en kötü geçiş ayları. Bir e-ticaret müşterisinin siparişten faturaya giden hattını kasımdan şubata ertelemek, aynı kapsamı yarı riskle teslim etmeyi sağlar.

Somut bir örnek: Türkiye'de bayi ağıyla çalışan bir üretici firmanın sipariş paneli PHP 7 üzerinde duruyordu ve yeni sanal POS entegrasyonunu kabul etmiyordu. Sıfırdan yazım teklifi 8 ay öngördü. Bunun yerine önce sürüm yükseltme ve ödeme modülünün strangler ile ayrılması yapıldı; panel üç ayda yeni ödeme altyapısına kavuştu, kalan modüller sonraki iki çeyreğe dağıtıldı. Aynı bütçenin üçte biriyle iş tarafının asıl ihtiyacı ilk çeyrekte çözüldü. Bayi panellerinde sık karşılaşılan bu kalıbı B2B bayi yönetim sistemi yazımızda ayrıca ele aldık.

Son bir ölçek notu: Türkiye'de 10 ve üzeri çalışanı olan girişimlerin yalnız %15,2'si bilgi ve iletişim teknolojileri uzmanı istihdam ediyor; uzman almaya çalışanların oranı ise %6,4 (TÜİK 2026 araştırması). Yani şirketlerin büyük bölümü eski yazılım yenileme projesini iç kaynakla yürütemez. Dış ekiple çalışmanın kuralları yazılım dış kaynak kullanımı yazımızda duruyor.

Sıkça Sorulan Sorular

Eski yazılım yenileme mi, sıfırdan yazmak mı daha ucuz?

Çoğu durumda kademeli yenileme daha ucuz. Sıfırdan yazım, mevcut sistemin bedelinin %80-%110'una çıkar ve geçiş dönemi boyunca iki sistemin bakımını birlikte gerektirir. Kaynak kod yoksa ya da hiç test yoksa denge sıfırdan yazım tarafına kayar. Karar verirken toplam sahip olma maliyetine bakın: kademeli yenileme bütçeyi birkaç çeyreğe yayar ve ürün bu süre boyunca canlı kalmaya devam eder.

Teknik borcu nasıl ölçersiniz?

Üç ölçü yeter: bir özelliğin fikirden canlıya geçme süresi, yeni geliştiricinin ilk anlamlı katkıyı yapma süresi ve desteği bitmiş bağımlılıkların sayısı. Üçünü üç ay üst üste kaydedin; eğilim size borcun yönünü verir. Soyut puanlar yerine bu üç sayıyı yönetim raporuna koyun, çünkü bütçe kararını veren kişi satır sayısıyla değil teslim süresiyle ilgilenir.

Yenileme sırasında sistem kapanır mı?

Kademeli geçişte kapanma gerekmez. Strangler yaklaşımında istekler bir yönlendirme katmanından geçtiği için modülleri tek tek devreye sokarsınız. Kapanma yalnız veri kesme (cutover) anında, genellikle mesai dışı birkaç saatlik pencerede yaşanır. Bu pencereyi müşterilere önceden duyurun ve geri dönüş kararını kim verecek, hangi dakikada verecek, baştan yazın.

Legacy sistem ile eski yazılım aynı şey mi?

Tam olarak değil. Legacy, yaşına değil değiştirilebilirliğine bakar: testleri ve belgeleri olan on yıllık bir sistem canlı sayarız, iki yıllık ama kimsenin dokunamadığı bir sistem legacy'dir.

Desteği bitmiş bir sürümde çalışmak yasal risk yaratır mı?

Kişisel veri işliyorsanız evet. KVKK'nın Kişisel Veri Güvenliği Rehberi yama yönetimi ve yazılım güncellemelerini teknik tedbirler arasında sayar. Yamasız bir sürümde çalışan sistem bu tedbiri karşılamaz ve ihlal durumunda kusur değerlendirmesini ağırlaştırır.

Veri kaybı riskini nasıl sıfıra yaklaştırırız?

Üç kuralla: eski tabloları ve eşitleme süreçlerini geçişten sonra en az bir mali dönem boyunca silmeyin, mutabakat sayılarını (kayıt adedi, tutar toplamı, tarih aralığı) iki tarafta eşleyin, ve geri dönüş adımını yazılı bir plan olarak hazırlayın.

Yenileme projesinde ajanstan ne istemelisiniz?

Dört belge isteyin: mevcut sistemin teknik değerlendirme raporu, modül modül geçiş sırası, veri taşıma ve mutabakat planı, ve devir paketi (kaynak kod, altyapı erişimleri, çalıştırma belgeleri). Bu dördü yoksa teklif fiyat değil tahmindir. Teknik değerlendirme raporunu ayrı bir iş olarak satın almak da mümkün; böylece yenileme işini aynı firmaya vermek zorunda kalmadan elinizde karşılaştırılabilir bir kapsam dokümanı olur.

Eski yazılım yenileme kararının zor tarafı teknik değil, zamanlama. Sistem hâlâ çalışıyorken başlayan projeler kademeli yürür, bütçesi sapmaz ve kullanıcıyı sarsmaz. Arıza gecesinde başlayan projelerde ise seçenek sayısı bire düşer: her şeyi aynı anda değiştirmek.

Mevcut sisteminizin hangi bantta durduğunu bilmiyorsanız, kod ve veri tarafını birlikte değerlendiren kısa bir inceleme en hızlı yol. Web yazılım geliştirme hizmetimizi inceleyin, eski yazılım yenileme yol haritanız için bizimle iletişime geçin.