Kaynak Kodu Kaybolmuş Eski Yazılımı Ne Yapmalı? Tersine Mühendislik, Belgeleme ve Modernizasyon Rehberi

Kısaca: Pek çok işletme, kaynak kodu kaybolmuş, belgesi olmayan ve yazan kişi ya da firmanın ulaşılamadığı bir yazılımla çalışıyor: eski bir masaüstü programı, tek bir kişinin yazdığı bir iç sistem, bakımı bırakılmış bir mobil uygulama. Bu sistemler çalıştığı sürece sorun görünmez; ama güvenlik güncellemesi, yeni işletim sistemi, entegrasyon ya da veri taşıma gerektiğinde riske dönüşür. REA gibi yapay zekâ destekli tersine mühendislik araçları, derlenmiş uygulamaların nasıl çalıştığını anlamayı hızlandırabiliyor, ancak kaynak kodu geri getirmiyor ve çıktıları kısmi bir harita olarak ele alınmalı. İşin doğru yolu: önce sahiplik ve lisansı netleştirmek, sonra sistemi belgelemek, kritik iş kurallarını kullanıcılarla doğrulamak, veriyi güvene almak ve ardından aşamalı modernizasyon yapmak. Bu yazı, yalnızca kendi sahip olduğunuz ya da inceleme yetkinizin bulunduğu yazılımlar için geçerlidir; yasal sınırlar için bu yazıya bakın.

Son güncelleme: 23 Ekim 2026

Bu sorun neden bu kadar yaygın?

• Yazılımı yapan freelancer veya firma ortadan kayboldu, sözleşmede kaynak kod teslimi yoktu (sözleşme kontrol listemizin 7. maddesi).
• Yedekler eksik veya kaynak kod bir kişinin bilgisayarında kaldı.
• Sistem yıllar içinde dokümantasyonsuz büyüdü.
• Altyapı (sunucu, veritabanı, lisans anahtarları) tek kişinin bilgisinde.
• Teknoloji eskidi: destek bitmiş bir çerçeve, eski bir işletim sistemi, güncellenmeyen kütüphaneler (güvenlik açısından en riskli durum).

Bu, bir yarım kalmış proje kurtarma durumunun kardeşidir: bir sistem çalışıyor ama kimse nasıl çalıştığını bilmiyor.

Önce: Hukuki ve sahiplik kontrolü

Hiçbir analize başlamadan:

1. Yazılımın sahibi kim? Sözleşme ve faturalar: yalnızca kullanım lisansı mı aldınız, yoksa kod hakları size mi devredildi?
2. Lisansta tersine mühendislik yasağı var mı? Üçüncü taraf bileşenler (ticari kütüphaneler) için de geçerli olabilir.
3. Üretici hâlâ ulaşılabilir mi? Kaynak kodu teslim almak çoğu zaman tersine mühendislikten ucuz ve güvenlidir; önce ulaşmayı deneyin.
4. Kişisel veri var mı? Analiz sırasında veriyi nereye gönderdiğinize dikkat edin (yapay zekâ kullanım politikası).

Şüpheniz varsa bir hukukçuya danışın.

Tersine mühendislik burada neye yarar?

REA gibi araçlar (bkz. REA nedir?) yapay zekâ ajanlarının derlenmiş bir uygulamanın içine bakmasını, ilgili kod yollarını izlemesini ve bulguları kanıtlarıyla raporlamasını sağlıyor. Resmî belgeye göre hedefler arasında yerel ikili dosyalar, JavaScript/Electron, .NET, Android uygulamaları, web siteleri ve bellenim bulunuyor. Eski bir sistem için pratik kullanımlar:

• Uygulamanın dışarıyla konuştuğu yerleri bulmak: hangi sunuculara, hangi API'lere, hangi dosya ve veritabanlarına bağlanıyor?
• Önemli iş kurallarının nerede hesaplandığını bulmak (fiyat, indirim, vergi, rapor mantığı).
• Veri biçimlerini anlamak: dosya ve veritabanı yapıları.
• Bağımlılıkları çıkarmak: hangi kütüphane ve sürümlerle çalışıyor, hangileri güvenlik riski taşıyor?

Beklentiyi doğru koymak

• Kaynak kod geri gelmez. Araç davranışı ve ilgili kod yollarını gösterir; orijinal proje yapısı, yorumlar, değişken adları kurtarılmaz.
• Çıktı eksik olabilir. Bağımsız bir testte REA, bir Electron uygulamasında bulduğu 30 iletişim işleminin konumlarının hepsini doğru verdi; ama bazı yanıt gönderme yerlerini, kodun yarattığı pencerelerin çoğunu ve açık bırakılmış bazı güvenlik ayarlarını özetinde göstermedi. Yazarın önerisi: çıktıyı kısmi harita olarak kullanın, boşlukları elle doğrulayın (test özeti).
• Uygulama türü önemli. JavaScript tabanlı (Electron) ve .NET uygulamalarında statik analiz daha kolay; derlenmiş yerel kodda ek araçlar (Ghidra, IDA, Hopper) ve uzmanlık gerekir.
• İş kuralı ≠ kod. Bir hesaplamanın neden öyle yapıldığını kod söylemez; bunu kullanıcılarla ve eski verilerle doğrulamak gerekir.

Adım adım plan

1. Envanter ve risk haritası

Sistem ne iş yapıyor, kim kullanıyor, hangi verilere erişiyor, nerede çalışıyor (sunucu, PC, bulut)? Güvenlik açısından kritik mi? Çalışmayı bırakırsa işletmeye maliyeti ne?

2. Yedekle ve koru

Program dosyalarını, veritabanlarını, yapılandırma ve lisans bilgilerini bağımsız kopyalara alın. Her şeyden önce: hiçbir şeyi değiştirmeden yedek. (Kopya üzerinde çalışın; üretimdeki sisteme dokunmayın.)

3. Davranışı belgeleyin

Ekranları, akışları, raporları, entegrasyonları ve kullanıcı rollerini kullanıcılarla birlikte belgeleyin. Kullanıcıya “bu ekranda ne yapıyorsun, neye göre?” diye sorun; kod analizinden önce gözlemle başlamak çoğu zaman en değerli bilgiyi verir.

4. Teknik analiz (yetkili ve kontrollü)

Gerekirse tersine mühendislik araçlarını kopya üzerinde, izole bir ortamda kullanın: dış bağlantılar, veri yapıları, bağımlılıklar, kritik hesaplamalar. Çıktıları eşleştirin ve doğrulayın: gerçek girdilerle sistemden beklenen sonuçları alıp bulguların doğruluğunu test edin.

5. Veriyi güvene alın

Asıl değer çoğu zaman koddan çok veridedir. Veri yapısını anlayıp temiz bir şekilde dışa aktarmak, modernizasyonun ön koşuludur. Ayrıntılı plan için veri taşıma rehberimize bakın.

6. Karar: koru, yeniden yaz, ya da değiştir

7. Yeni sistemi doğru kurun

Yeni sistemde bu sorunun tekrarını önleyin: kaynak kod ve hesaplar sizin adınıza, belge ve test altyapısı, düzenli yedek ve bakım planı. Bkz. teslim ve kabul testi rehberi ve bakım ve SLA rehberi.

Kırmızı bayraklar

• “Bu sistemi sadece bir kişi biliyor.”
• Sunucu veya işletim sistemi destek dışı.
• Lisans anahtarları veya hesaplar kişisel e-postalarda.
• Hiç yedek alınmıyor ya da geri yükleme hiç denenmemiş.
• Kritik veriler tek bir dosyada ve kopyası yok.
• “Dokunmayalım, çalışıyor” tavrı. (Çalışan ama kimsenin anlamadığı sistem, ne zaman bozulacağı belli olmayan bir saatli bombadır.)

Aktaş Digital ile modernizasyon

Eski bir sistemi anlamak, belgelemek ve yeni bir mimariyle aşamalı olarak değiştirmek için süreci yetki, veri güvenliği ve iş sürekliliği gözeterek planlıyoruz. Kapsam ve maliyet dökümü almak için teklif formumuzu kullanabilirsiniz. İlgili hizmetlerimiz: web çözümleri, CRM, ERP ve stok takip sistemleri.

Sık Sorulan Sorular

Kaynak kodu olmayan bir programı yapay zekâ ile yeniden yazdırabilir miyim?

Yapay zekâ araçları analizi hızlandırabilir, ama çıktı doğrulanmadan güvenilmemeli. Kaynak kod kurtarılmaz; davranışı kullanıcılarla, eski verilerle ve testlerle doğrulayarak yeniden yazmak gerekir.

Yazılımı yapan firma kaynak kodu vermiyor; ne yapmalıyım?

Önce sözleşmenizi ve fatura/lisans şartlarını inceleyin; kod hakları devredilmiş olabilir. Hukuki seçenekleri bir avukatla değerlendirin. Bu, tersine mühendislikten önce denenmesi gereken yoldur.

Tersine mühendislik yasal mı?

Amaca, yetkiye ve lisansa bağlıdır. Kendi yazılımınızı anlamak genellikle en düşük riskli senaryodur. Ayrıntı için hukuki sınırlar yazımıza bakın ve bir hukukçuya danışın.

Sistem eski ama çalışıyor; neden değiştireyim?

Güvenlik güncellemesi alamayan, bakımı yapılamayan ve tek bir kişiye bağlı sistemler beklenmedik anda iş sürekliliği riski oluşturur. Değiştirme zorunlu olmayabilir; ama yedek, izolasyon ve bir modernizasyon planı en azından şarttır.

Ne kadar sürer ve ne kadar tutar?

Sistemin büyüklüğüne, karmaşıklığına ve belge durumuna göre çok değişir; tek bir rakam vermek yanıltıcı olur. Küçük bir keşif ve belgeleme aşamasıyla başlamak, kapsamı netleştirir.

Sonuç

Kaynak kodu olmayan eski yazılım, “çalıştığı sürece” görünmez bir risktir. Yapay zekâ destekli tersine mühendislik araçları anlamayı hızlandırır ama kaynak kodu geri getirmez ve çıktılarının doğrulanması gerekir. Doğru sıra: sahiplik ve lisans, yedek, gözlemle belgeleme, kontrollü analiz, veriyi güvene alma ve aşamalı modernizasyon. Bugün yapabileceğiniz ilk iş: kaynak kodu olmayan sistemlerinizi listelemek ve her biri için tek bir yedek ile “sistemi bilen kişi” bilgisini yazılı hale getirmek.