Mevcut Yazılımı Yenilemek mi, Baştan Yapmak mı? Rewrite ve Modernizasyon Kararı Nasıl Verilir?

Kısa cevap

Mevcut bir yazılım eskidiğinde ilk çözüm sistemi baştan yazmak olmamalıdır. Sorun yalnızca eski runtime, yavaş deployment, teknik borç veya belirli modüllerdeki karmaşıklıksa; replatform, refactor veya kademeli modernizasyon daha düşük riskli olabilir. Baştan geliştirme — yani rebuild/rewrite — daha çok mevcut mimarinin yeni iş ihtiyaçlarını ciddi biçimde engellediği, teknolojinin sürdürülemez hale geldiği veya mevcut kodu modernize etmenin maliyeti yeni sistem kurmaktan daha yüksek olduğu durumlarda değerlendirilmelidir. Microsoft’un güncel modernizasyon rehberi de rebuild’i tek seçenek olarak değil; rehost, replatform, refactor, rebuild, retire ve retain gibi birden fazla stratejiden biri olarak ele alıyor. (Microsoft Learn) En önemli prensip şudur: “Kod eski” bir rewrite gerekçesi değildir.

Önce şu soruyu cevaplayın:

Mevcut sistem iş hedeflerimizi karşılamayı neden zorlaştırıyor ve bu problemi en düşük riskle hangi müdahale çözer?

“Eski yazılım” ne demek?

Bir sistem 8 yıllık olabilir ama:

• stabil,
• güvenli,
• test edilebilir,
• geliştirilebilir,

business ihtiyaçlarını karşılıyor olabilir. Başka bir sistem yalnızca 2 yıllık olmasına rağmen:

• dependency’leri güncellenemiyor,
• her deployment yeni hata çıkarıyor,
• bütün modüller birbirine bağlı,
• dokümantasyon yok,

production tek kişinin bilgisine bağlı olabilir. Dolayısıyla yazılımın yaşı: Takvim yaşı ≠ Teknik sağlık dır. Modernizasyon kararı sistemin kaç yılında yazıldığına değil, bugünkü teknik ve ticari durumuna göre verilmelidir. Microsoft’un application modernization değerlendirme rehberi de modernizasyon öncesinde uygulamanın mevcut performansı, stabilitesi, ölçeklenebilirliği, kullanılan teknoloji stack’i, dependency’leri ve destek durumu gibi faktörlerin değerlendirilmesini öneriyor. (Microsoft Learn) Baştan yazmak tek seçenek değil: 6 temel strateji

Modernizasyon konuşmalarında en sık yapılan hata iki seçenek varmış gibi davranmaktır:

1. Böyle bırak

2. Baştan yaz

Gerçekte çok daha fazla seçenek vardır. Microsoft’un modernizasyon çerçevesindeki 6R yaklaşımı bu kararları şu şekilde ayırıyor: Rehost, Replatform, Refactor, Rebuild, Retire ve Retain. (Microsoft Learn)

Strateji

Ne anlama gelir?

Retain

Şimdilik mevcut sistemi koru

Rehost Büyük kod değişikliği olmadan yeni altyapıya taşı Replatform Az kod değişikliğiyle daha modern çalışma platformuna geçir Refactor Mevcut kodu davranışı büyük ölçüde koruyarak iyileştir Rebuild Sistemi baştan geliştir Retire Artık değer üretmeyen sistemi kapat Bazı kaynaklarda ayrıca rearchitect ayrı bir kategori olarak kullanılır: uygulamanın mimarisini daha köklü biçimde yeniden tasarlamak. Microsoft’un güncel Cloud Adoption Framework rehberi replatform, refactor ve rearchitect’i ayrı modernizasyon stratejileri olarak ele alıyor. (Microsoft Learn)

1. Retain — Hiçbir şey yapmamak bazen doğru karar olabilir

Her eski sistemi modernize etmek zorunda değilsiniz. Örneğin sistem:

• yılda birkaç kez kullanılıyor,
• stabil,
• internete açık değil,
• yeni özellik ihtiyacı yok,

bakım maliyeti düşük ise: Şimdi modernize et yerine: Retain + Monitor daha ekonomik olabilir. Microsoft da retain stratejisini maliyet, dependency, risk veya organizasyonun henüz modernizasyona hazır olmaması durumlarında geçerli bir seçenek olarak tanımlıyor. (Microsoft Learn)

“Eski olduğu için değiştirelim” neden kötü yatırım olabilir?

Çünkü modernizasyonun kendisi de:

• geliştirme,
• test,
• migration,
• kullanıcı eğitimi,

geçiş riski oluşturur. Eğer elde edilen business değeri bu maliyetin altında kalıyorsa teknik olarak daha modern bir sistem kurmuş olursunuz ama ticari olarak kötü yatırım yapmış olabilirsiniz. Bu nedenle modernizasyon kararı: Teknik problem + Business impact + Maliyet + Risk birlikte değerlendirilmelidir. Microsoft’un modernizasyon planlama rehberi de modernizasyon için problem tanımı, cost-benefit analizi, business value ve ROI değerlendirmesinin yapılmasını öneriyor. (Microsoft Learn)

2. Rehost — Sistemi değiştirmeden altyapıyı modernize etmek

Bazen uygulamanın kodunda ciddi sorun yoktur. Problem: eski fiziksel sunucu veya: bakımı zor VM olabilir. Bu durumda sistemi büyük ölçüde aynı bırakıp daha modern altyapıya taşımak mümkündür. Bu yaklaşıma genellikle: rehost / lift and shift denir. Microsoft, rehost’u uygulamanın kodunda büyük değişiklik yapmadan modern cloud altyapısına taşıma stratejisi olarak tanımlıyor. (Microsoft Learn)

Rehost ne zaman mantıklı?

Örneğin:

• mevcut uygulama stabil,
• kısa sürede eski veri merkezinden çıkmak gerekiyor,
• altyapı operasyonu pahalı,

kod modernizasyonu daha sonra yapılacak ise. Avantaj: Sistemin iş mantığına dokunmadan altyapı sorununu çözebilirsiniz. Ancak: Rehost teknik borcu ortadan kaldırmaz. Eski application architecture yalnızca yeni sunucuda çalışmaya devam eder.

3. Replatform — Kodu minimum değiştirerek çalışma ortamını yenilemek

Replatform, rehost’tan bir adım daha ileri gider. Örneğin: Eski VM üzerinde PostgreSQL yerine: Managed PostgreSQL

• kullanmak;

veya: manuel deployment yerine: managed application platform + CI/CD geçmek düşünülebilir. Microsoft’un güncel rehberinde replatform, workload component’lerini minimal code change ile daha modern platform servislerine taşıma stratejisi olarak tanımlanıyor. (Microsoft Learn)

Replatform neyi çözebilir?

Örneğin:

• server bakım yükünü,
• manual deployment’ı,
• scaling zorluklarını,

backup operasyonunu azaltabilir. Ama yine: Kötü application code kendi kendine düzelmez. Bu nedenle bazen: Replatform + Selective Refactor birlikte kullanılır.

4. Refactor — Sistemi atmadan içini düzeltmek

Refactor:

uygulamanın dış davranışını tamamen değiştirmeden mevcut kodun yapısını iyileştirmek olarak düşünülebilir. Microsoft refactor stratejisini; mevcut kodu maintainability, performance veya cloud best practices açısından iyileştiren, ancak uygulamanın dış davranışında büyük değişiklik yaratmayan yaklaşım olarak tanımlıyor. (Microsoft Learn)

Refactor ile neler yapılabilir?

Örneğin: 1 adet 6.000 satırlık service parçalara ayrılabilir. SQL her yerde yerine kontrollü data-access katmanı oluşturulabilir. manuel deploy yerine CI/CD kurulabilir. test yok olan kritik akışlara test eklenebilir. eski dependency kademeli olarak güncellenebilir. Bu işlemler sırasında kullanıcı açısından uygulamanın temel davranışı büyük ölçüde aynı kalabilir.

Ne zaman refactor daha mantıklıdır?

Şu durumda özellikle:

• business logic doğru,
• veri modeli kullanılabilir,
• uygulamanın kullanıcıları memnun,
• problem geliştirilebilirlik,
• deployment çok riskli,

bazı modüller aşırı karmaşık ise. Bu durumda çalışan iş mantığını çöpe atmak yerine sorunlu bölgeleri iyileştirmek çok daha ekonomik olabilir.

5. Rearchitect — Koddan çok mimari sınırları değiştirmek

Bazen problem tek tek fonksiyonlarda değildir. Örneğin: Frontend Backend Reporting Notifications Background jobs tamamen birbirine bağlı olabilir. Bir modüldeki küçük değişiklik bütün application’ın yeniden deploy edilmesini gerektiriyorsa, mimari sınırlar problem haline gelmiş olabilir. Rearchitect: sistemi baştan yazmadan architecture’yı daha köklü biçimde yeniden düzenlemek anlamında kullanılabilir. Microsoft, rearchitect’i mevcut tasarımın scalability, agility veya cloud-native kullanımını sınırladığı durumlarda architecture’nın yeniden tasarlanması olarak tanımlıyor. (Microsoft Learn)

Rearchitect = microservice olmak zorunda mı?

Hayır. Bu önemli. Şu denklem yanlıştır: Monolith = Eski / Kötü Microservices = Modern / İyi Küçük ve orta ölçekli birçok sistem için iyi tasarlanmış modüler monolith daha doğru olabilir. AWS’in Strangler Fig rehberi bile bu pattern’in özellikle büyük ve karmaşık monolith’lerde faydalı olduğunu; küçük sistemlerde complete refactoring veya farklı bir yaklaşımın daha verimli olabileceğini belirtiyor. (AWS Dokümantasyonu) Dolayısıyla architecture modernizasyonu: “Microservice kullanalım.”

• ile değil;

“Mevcut architecture hangi business ihtiyacını karşılayamıyor?” ile başlamalıdır.

6. Rebuild / Rewrite — Baştan geliştirmek

Rewrite en radikal seçenektir. Mevcut kodun büyük bölümünü kullanmayıp yeni sistem geliştirilir. Microsoft’un 6R rehberi rebuild’i, replatform/refactor maliyetinin sağlayacağı faydanın üzerine çıktığı veya legacy sorunların ve yeni işlevlerin mevcut sistem üzerinde sağlıklı biçimde çözülemeyeceği durumlarda değerlendirilecek yaklaşım olarak tanımlıyor. (Microsoft Learn)

Baştan geliştirmek hangi durumlarda mantıklı olabilir?

Örneğin:

• mevcut teknoloji artık desteklenmiyor,
• güvenli güncelleme yolu yok,
• mimari yeni iş modelini ciddi biçimde engelliyor,
• codebase anlaşılması aşırı zor,
• mevcut platform ölçeklenemiyor,
• refactor maliyeti rewrite’a çok yaklaşıyor,

ürün zaten tamamen farklı bir iş modeline dönüşecek. Ancak bu faktörlerin biri tek başına otomatik rewrite kararı oluşturmaz. En tehlikeli gerekçe: “Kod kötü” Şu cümle tek başına yeterli değildir: “Kod çok kötü, yeniden yazalım.” Bunun yerine ölçülebilir problem istenmelidir. Örneğin:

Kritik security vulnerability neden düzeltilemiyor?

Yeni feature neden 2 gün yerine 4 hafta sürüyor?

Framework neden upgrade edilemiyor?

Deployment failure rate nedir?

Hangi modüller değiştirilirken sürekli regression çıkıyor?

Production incident’ların kaynağı ne?

“Bunu beğenmedik” ile “bu mimari sürdürülemez” aynı şey değildir. Rewrite'ın en büyük gizli riski: Mevcut sistem düşündüğünüzden daha fazla şey biliyor olabilir 10 yıllık bir uygulamanın içinde yalnızca: code yoktur. Yıllar içinde oluşmuş yüzlerce küçük business rule olabilir. Örneğin: Belirli müşteri tipi + belirli ülke + belirli tarih → farklı hesaplama gibi. Bunların bir kısmı:

• dokümantasyonda yoktur,
• yalnızca kodda vardır,

yalnızca kullanıcıların alışkanlıklarında vardır. Yeni sistem tasarlanırken bunlardan biri unutulursa yeni sistem teknik olarak çok temiz ama business açısından yanlış olabilir.

“Aynı sistemi yeniden yapacağız” neden zor?

Çünkü eski sistemin gerçek specification’ı çoğu zaman:

Dokümantasyon

• değil;

Kod + Database + Kullanıcı davranışı +

Edge case'ler

toplamıdır. Bu nedenle rewrite projesinin önemli bir bölümü: reverse specification haline gelebilir. Rewrite paradoksu Mevcut sistem: Eski Ama çalışıyor durumunda olabilir. Yeni sistem: Temiz Ama henüz production'da kanıtlanmadı durumundadır. Bu nedenle: Old system off ↓ New system on şeklindeki big-bang geçiş yüksek risk taşıyabilir. AWS de büyük ve karmaşık monolith’i tek seferde rewrite/refactor edip geçirmek yerine Strangler Fig gibi kademeli yaklaşımın transformation riskini ve business disruption’ı azaltabileceğini belirtiyor. (AWS Dokümantasyonu)

Strangler Fig yaklaşımı nedir?

Adım adım eski sistemin fonksiyonlarını yeni sistemle değiştirmektir. Örneğin mevcut sistem: Legacy System ``` ├── Customers ├── Orders ├── Reporting └── Billing ``` olsun. İlk olarak: Customers yeni sisteme taşınabilir. Sonra: Reporting Sonra: Orders En sonunda legacy sistemde ihtiyaç kalmayınca kapatılır. AWS bunu üç temel aşamayla açıklıyor: Transform ↓ Coexist ↓ Eliminate Yani yeni component geliştirilir, eski ve yeni sistem bir süre birlikte çalışır, ardından eski fonksiyon kademeli olarak devreden çıkarılır. (AWS Dokümantasyonu)

Bu yaklaşımın en büyük avantajı ne?

Eski sistem migration boyunca:

çalışmaya devam eder. Örneğin 12 aylık modernizasyon projesinde müşteriler: “12 ay boyunca yeni özellik gelmeyecek.” demek zorunda kalmaz. AWS, Strangler Fig yaklaşımını özellikle büyük monolith’lerde business’ın yeni özellik geliştirmeye devam etmesi gerektiğinde ve kullanıcı etkisinin minimum tutulmasının önemli olduğu durumlarda öneriyor. (AWS Dokümantasyonu)

Strangler Fig her projede doğru mu?

Hayır. AWS rehberindeki önemli sınırlamalar arasında:

• küçük sistemlerde gereksiz karmaşıklık,
• request’lerin intercept/routing edilememesi,
• proxy katmanının failure/performance noktası olabilmesi,

sistem domain’inin net olmaması bulunuyor. (AWS Dokümantasyonu) Yani: “Kademeli modernizasyon her zaman en iyidir.” demek de doğru değildir.

Branch by Abstraction ne zaman kullanılabilir?

Legacy sistemde değiştirmek istediğiniz component:

uygulamanın içinde derinde ve birçok başka modül tarafından kullanılıyorsa dışarıdan proxy ile değiştirmek zor olabilir. AWS bu gibi durumlarda Branch by Abstraction yaklaşımını öneriyor. Temel mantık: Eski implementation ``` │ ▼ ``` Abstraction ▲ ``` │ ``` Yeni implementation Önce eski component etrafına abstraction yerleştirilir. Sonra eski ve yeni implementation aynı abstraction üzerinden çalışabilir. Yeni implementation doğrulandıktan sonra eski taraf kaldırılır. (AWS Dokümantasyonu) Bu teknik detay özellikle büyük legacy codebase’lerde big-bang rewrite alternatifi oluşturur.

Kullanıcının gördüğü arayüzü yenilemek rewrite mıdır?

Hayır. Örneğin eski sistem: Eski UI + Çalışan backend olabilir. Problem yalnızca:

• mobil uyumsuzluk,
• kötü UX,

eski frontend teknoloji ise yalnızca frontend modernize edilebilir. Backend bir süre korunabilir. Örneğin: New Frontend ↓ Existing API ↓ Existing Database oluşturulabilir. Bu durumda bütün sistemi yeniden yazmak gereksiz olabilir. Tam tersi de mümkün Public veya kullanıcı arayüzü iyi olabilir. Ama backend:

• performans sorunu,
• eski framework,

maintenance problemi yaşıyor olabilir. Bu durumda kullanıcı deneyimini koruyup backend kademeli değiştirilebilir. Modernizasyonu: “Tek paket.” olarak görmek yerine: Frontend Backend Database Infrastructure Integrations ayrı ayrı değerlendirmek daha doğrudur.

Database rewrite kararında neden en kritik alanlardan biridir?

Çünkü application yeniden yazılabilir. Ama: 10 yıllık müşteri sipariş finans operasyon verisinin tamamı taşınmak zorundadır. Yeni data model ile eski data model aynı olmayabilir. Veri migration'ı yalnızca export/import değildir Örneğin eski sistem:

customer_status = 7

tutuyor. Yeni sistem: ACTIVE INACTIVE SUSPENDED bekliyor. Mapping gerekir. Ayrıca:

• duplicate kayıt,
• bozuk tarih,
• orphan relation,
• eksik veri,

encoding problemleri çıkabilir. Microsoft’un modernizasyon assessment rehberi de application modernizasyonunda data integration, data cleansing, transformation ve validation ihtiyacının plana dahil edilmesini öneriyor. (Microsoft Learn)

Yeni ve eski database bir süre birlikte çalışabilir mi?

Evet, ama dikkat gerektirir. Örneğin kademeli migration sırasında: Legacy → Old DB New module → New DB olabilir. Bu durumda aynı business entity iki tarafta kullanılıyorsa:

• synchronization,
• consistency,

ownership problemleri ortaya çıkar. AWS Strangler Fig rehberi de monolith ve yeni service’lerin bir süre farklı data store’lar kullanması halinde veri senkronizasyonunun redundancy ve eventual consistency oluşturabileceğini belirtiyor. (AWS Dokümantasyonu) Bu nedenle data migration genellikle modernizasyonun en zor parçalarından biridir.

Rewrite kararı verirken bakılması gereken 9 faktör

1. Business uyumu

Mevcut sistem şirketin iş modelini hâlâ destekliyor mu?

2. Teknoloji desteği

Runtime/framework/database hâlâ destekleniyor mu?

3. Değişiklik maliyeti

Basit özellikler bile aşırı uzun mu sürüyor?

4. Güvenlik

Açıklar güvenli biçimde kapatılabiliyor mu?

5. Test edilebilirlik

Değişiklikten sonra sistemin bozulmadığını doğrulayabiliyor musunuz?

6. Architecture

Yeni ihtiyaçları architecture mı engelliyor?

7. Veri

Migration ne kadar riskli?

8. Entegrasyonlar

Kaç sistem legacy application’a bağlı?

9. ROI

Modernizasyonun iş değeri maliyetinden yüksek mi?

Microsoft da assessment aşamasında application health, technology stack, dependencies, security, data, cost ve business importance gibi faktörlerin birlikte değerlendirilmesini öneriyor. (Microsoft Learn)

Rewrite puanlaması nasıl yapılabilir?

InoviqLab açısından örnek bir karar matrisi:

Çok zor

Güvenlik Yönetilebilir Borçlu Kapatılamayan açıklar Mimari Esnek Karmaşık Yeni iş modelini engelliyor Veri Temiz Karmaşık Migration çok riskli Deployment Otomatik Kısmi Tek kişiye bağlı Business fit Güçlü Sınırlı Temelden değişti Tek bir “kritik” kutu: rewrite kararı değildir. Ancak kritik alanların çoğu aynı anda bulunuyorsa rebuild ihtimali güçlenir.

En önemli soru: Sorun kodda mı, süreçte mi?

Bazen şirket:

“Yazılım kötü.” der. Gerçekte problem: Onay süreci çok karmaşık olabilir. Yeni yazılım yaparsınız. Ama aynı workflow’u yeni sisteme taşırsanız: Yeni teknoloji + Eski kötü süreç elde edersiniz.

Modernizasyon öncesinde:

Sistemi mi modernize ediyoruz, iş sürecini mi?

sorusu cevaplanmalıdır. Modernizasyon projesi bir yazılım projesi değil, business projesidir Çünkü kararlar:

• çalışanların nasıl iş yapacağını,
• müşterilerin nasıl hizmet alacağını,
• hangi verinin tutulacağını,

hangi sürecin otomatikleşeceğini etkileyebilir. Microsoft da uygulama modernizasyonunu yalnızca teknoloji upgrade’i değil, çalışma ve değer üretme biçimini etkileyen daha geniş bir dönüşüm olarak ele alıyor. (Microsoft Learn) Big Bang Rewrite'ın 7 temel riski Kapsam olduğundan küçük tahmin edilir. Gizli business rule’lar unutulur. Eski sistem geliştirilmezken business beklemek zorunda kalabilir. Data migration son aşamada problem çıkarabilir. İki sistem arasında feature parity yakalamak uzun sürebilir. Yeni sistem production yükünde henüz kanıtlanmamıştır. Proje uzadıkça mevcut ve yeni sistem arasındaki fark büyüyebilir. AWS, büyük monolith’in tamamen rewrite/refactor edilmesini “huge undertaking” ve big-bang migration’ı transformation risk/business disruption kaynağı olarak değerlendiriyor. (AWS Dokümantasyonu)

Peki full rewrite hiç mi yapılmamalı?

Elbette yapılabilir. Örneğin küçük uygulama: 20 ekran küçük database az entegrasyon iyi anlaşılmış business ise kademeli strangler architecture kurmak gereksiz olabilir. AWS de küçük ve düşük karmaşıklıktaki sistemlerde kademeli Strangler Fig yaklaşımı yerine complete rewrite/refactor’ın daha verimli olabileceğini belirtiyor. (AWS Dokümantasyonu) Yani risk sistemin büyüklüğüne ve karmaşıklığına göre değerlendirilmelidir.

Modernizasyonu fazlara bölmek neden daha güvenli?

Microsoft modernizasyon planlama rehberi de risk ve business disruption’ı azaltmak için uygulama component’lerini değer, dependency, risk ve complexity’ye göre değerlendirip fazlı implementation öneriyor. (Microsoft Learn) Örneğin: Faz 1 Authentication + CI/CD Faz 2 Customer module Faz 3 Reporting Faz 4 Operations Faz 5 Legacy retirement şeklinde olabilir.

Hangi modülden başlanmalı?

En kritik modülden başlamak her zaman doğru değildir. İlk modernizasyon parçası:

• yeterince değerli,
• sınırları anlaşılır,
• test edilebilir,

düşük/orta migration riski olan bölüm olabilir. AWS’in Strangler Fig rehberi de başlangıç component’i için iyi test coverage bulunan, daha az technical debt taşıyan veya bağımsız scalability/deployment değeri yaratabilecek alanları değerlendiriyor. (AWS Dokümantasyonu)

Proof of Concept ne zaman değerli?

Örneğin plan:

Legacy .NET → New architecture ise bütün sistemi dönüştürmeden önce tek bir vertical flow üzerinde PoC yapılabilir. Microsoft da modernizasyon stratejisini doğrulamak için end-to-end proof of concept ile başlamayı; böylece teknik ve operasyonel sorunların erken ortaya çıkarılmasını öneriyor. (Microsoft Learn)

PoC şu soruları test edebilir:

Yeni architecture gerçekten çalışıyor mu?

Latency kabul edilebilir mi?

Deployment kolaylaştı mı?

Database migration mümkün mü?

Ekip yeni stack’i yönetebiliyor mu?

PoC ile production modülü aynı şey değil

PoC:

Teknik yaklaşım çalışıyor mu?

sorusunu cevaplar.

Production:

Bu yaklaşım güvenli, izlenebilir, desteklenebilir ve ölçeklenebilir mi?

sorusunu cevaplar. Bu ayrım korunmalıdır.

Rewrite sırasında feature freeze gerekli mi?

Her zaman değil. Big-bang rewrite’ın önemli problemlerinden biri budur. Örneğin eski sisteme: 6 ay boyunca yeni özellik eklenmez denirse business yeni ürünü beklemek zorunda kalabilir. Ama eski sistem geliştirilmeye devam ederse: Legacy v1 ↓ Yeni özellik ↓ Legacy v1.1 Bu arada new system ↓ eski specification üzerinden ilerliyor feature parity sürekli uzaklaşabilir. Kademeli migration bu problemi azaltabilir.

“Yeni sistem eski sistemin birebir aynısı olacak” doğru hedef mi?

Çoğu zaman hayır. Eğer eski sistemde: 10 yıldır kimsenin kullanmadığı 17 rapor varsa hepsini yeniden yapmak gereksizdir. Rewrite/modernizasyon öncesinde: Keep Improve Remove Replace kararı verilmelidir. Microsoft’un modernizasyon çerçevesinde Retire seçeneğinin ayrıca bulunmasının nedeni de budur: artık değer üretmeyen application veya fonksiyonları taşımak yerine kapatmak bazen daha doğru olabilir. (Microsoft Learn) Kullanım verisini modernizasyon kararında kullanın Örneğin eski panelde: 85 ekran var. Analytics gösteriyor: 52 ekran → son 12 ayda neredeyse hiç kullanılmamış. O zaman yeni sistem specification’ı: 85 ekran olmamalıdır. Modernizasyon aynı zamanda: gereksiz complexity’yi bırakma fırsatıdır.

Security problemi varsa mutlaka rewrite gerekir mi?

Hayır. Örneğin sorun: outdated dependency ise upgrade yeterli olabilir. secret'lar source code'da ise secret-management refactor yapılabilir. authorization architecture temelden yanlış ise daha geniş rearchitecture gerekebilir. Security: Rewrite gerekçesi olabilir ama: Rewrite zorunluluğu değildir.

Performans problemi varsa rewrite gerekir mi?

Yine hayır. Önce ölçün. Sorun:

• tek SQL query,
• yanlış index,
• büyük image,
• N+1 request,

cache eksikliği olabilir. Bütün sistemi yeniden yazıp aynı data-access hatasını tekrarlamak mümkündür. Bu nedenle: Measure ↓ Find bottleneck ↓ Fix önce gelir.

Cloud'a geçmek rewrite demek mi?

Hayır. Microsoft’un modernizasyon yaklaşımında:

• rehost,
• replatform,
• refactor,

rearchitect ayrı seçeneklerdir. (Microsoft Learn) Dolayısıyla: On-prem → Cloud geçişi: Full rewrite gerektirmeyebilir. Cloud migration ile application modernization ayrı kararlar olabilir.

Monolith kötü mü?

Hayır. Monolith birçok proje için gayet doğru mimaridir. Problem: Monolith olması

• değil;

değiştirilemez, test edilemez, ölçeklenemez hale gelmesi dir. AWS’in kendi Strangler Fig guidance’ı bile pattern’i özellikle büyük/karmaşık monolith’lere yönlendiriyor ve küçük sistemlerde gereksiz complexity oluşturabileceğini belirtiyor. (AWS Dokümantasyonu) Rewrite kararında microservice heyecanına dikkat Örneğin mevcut: 1 application + 1 database + 5 developer var. Rewrite sonunda: 18 microservice + 8 database + Kafka + Service mesh oluşturmak teknik olarak etkileyici görünebilir. Ama:

• deployment,
• observability,
• distributed transaction,
• network,

operational complexity ciddi biçimde artabilir. Modernizasyon: maksimum dağıtık mimari

• değil;

iş ihtiyacı için gereken minimum sürdürülebilir mimari hedeflemelidir. Modernizasyon öncesi envanter çıkarın Microsoft’un güncel modernization guidance’ı ilk adımlardan biri olarak application, database, infrastructure ve dependency envanteri çıkarılmasını öneriyor. (Microsoft Learn) Örneğin tablo: Varlık Durum Frontend React eski sürüm Backend .NET legacy DB PostgreSQL Payment Third-party API Reporting Aynı backend Storage S3 Deployment Manual Tests Çok sınırlı Monitoring Yok Bu tablo olmadan rewrite tartışması spekülasyon haline gelir. Teknik modernizasyon audit checklist'i

Business

Sistem hangi kritik süreçleri çalıştırıyor?

Hangi fonksiyonlar gerçekten kullanılıyor?

Sonraki 3 yılın business ihtiyacı nedir?

En büyük kullanıcı şikâyeti ne?

Code

Kaynak kod mevcut. Repository güncel. Framework/runtime destek durumu biliniyor. Dependency sağlık durumu biliniyor. Test kapsamı ölçüldü. Kritik technical debt listelendi. Architecture Modül sınırları belli. Kritik coupling noktaları belli. Background jobs envanterlendi. External APIs listelendi. Scale bottleneck’leri ölçüldü. Data Database schema analiz edildi. Veri hacmi biliniyor. Veri kalitesi kontrol edildi. Migration complexity değerlendirildi. Backup/restore doğrulandı. Operations Deployment süreci biliniyor. Monitoring var. Incident history incelendi. Performance metric’leri mevcut. Cloud/infrastructure maliyeti ölçüldü. Security Authentication incelendi. Authorization incelendi. Vulnerable dependencies tarandı. Secrets değerlendirildi. Kullanılan destek dışı platformlar belirlendi. Rewrite Karar Matrisi Durum İlk değerlendirilecek yaklaşım Sistem stabil, sadece sunucu eski Rehost / Replatform Kod çalışıyor ama bakım zor Refactor Bazı modüller problemli Selective refactor Mimari yeni ihtiyaçları engelliyor Rearchitect Büyük legacy sistem, business duramıyor Incremental modernization Küçük ama tamamen eskimiş uygulama Rewrite değerlendirilebilir Uygulamanın business değeri kalmamış Retire Risk/maliyet şu an yüksek Retain + roadmap Mevcut sistem iş modelinden tamamen kopmuş Rebuild güçlü aday Bu tablo InoviqLab değerlendirme çerçevesidir. Rewrite'a karar verirseniz eski sistemi hemen kapatmayın Geçiş planı oluşturun. Örneğin: Old 100% traffic ↓ New pilot 5% ↓ 20% ↓ 50% ↓ 100% ↓ Old system retired Her proje traffic splitting kullanmaya uygun değildir. Ancak prensip: cutover'ı geri dönüşü mümkün şekilde tasarlamak olmalıdır. AWS’in Strangler Fig modeli de eski sistemi migration sırasında rollback amacıyla bir süre çalışır durumda tutmayı öneriyor. (AWS Dokümantasyonu)

Rollback planı neden gerekli?

Yeni modül production’a çıktı. Sonra: unexpected data bug çıktı. Rollback: Traffic → old module veya: Previous deployment yapılabiliyorsa incident etkisi azaltılabilir. AWS, incremental modernization sırasında her refactored service için güvenli geri dönüş planının bulunmasını özellikle önemli bir consideration olarak belirtiyor. (AWS Dokümantasyonu)

Modernizasyon başarısını nasıl ölçmelisiniz?

Proje hedefi:

“Yeni teknolojiye geçtik.” olmamalıdır. Ölçülebilir hedefler:

• deployment süresi,
• change lead time,
• incident sayısı,
• error rate,
• latency,
• infrastructure cost,
• development cycle,

kullanıcı memnuniyeti olabilir. Microsoft da modernizasyon ROI’sini değerlendirirken performans, maliyet, kullanıcı deneyimi ve operational metrics’in izlenmesini öneriyor. (Microsoft Learn) Örneğin başarı kriteri Önce: Release → ayda 1 Sonra: Release → haftada 3 veya: P95 response 1.8 s → 600 ms olabilir. Böylece modernizasyon: “Daha modern stack.”

• değil;

ölçülebilir business/operational improvement haline gelir.

Maliyet hesabı nasıl yapılmalı?

Yalnızca:

Rewrite geliştirme fiyatı ile: Refactor geliştirme fiyatı karşılaştırılmaz. Ayrıca: Rewrite maliyeti

• yeni development,
• data migration,
• parallel operations,
• user migration,
• training,

testing. Mevcut sistemi koruma maliyeti

• bakım,
• incident,
• yavaş development,
• lisans,
• altyapı,

güvenlik. Kademeli modernizasyon

• iki sistemin geçici operasyonu,
• integration/proxy,

migration. birlikte düşünülmelidir. En doğru karşılaştırma: 3 yıllık perspektif Örneğin:

Kontrollü

Full rewrite Yüksek Potansiyel düşük Yüksek Gerçek rakamlar projeye göre hesaplanmalıdır.

En sık yapılan 8 modernizasyon hatası

1. Teknoloji modasıyla rewrite kararı vermek

“Yeni framework çıktı.”

Rewrite gerekçesi değildir.

2. Mevcut business rule'ları küçümsemek

Eski kod düşündüğünüzden fazla bilgi taşıyabilir.

3. Data migration'ı sona bırakmak

Migration projenin başından test edilmelidir.

4. Mevcut sistemi ölçmeden “yavaş” demek

Önce latency ve bottleneck ölçülmeli.

5. Microservice'i otomatik hedef yapmak

Architecture ihtiyaçtan doğmalıdır.

6. Yeni sistem hazır olana kadar feature development'ı tamamen durdurmak

Business maliyeti yaratabilir.

7. Rollback düşünmemek

Cutover tek yönlü olmamalıdır.

8. Başarıyı yalnızca yeni technology stack ile ölçmek

Business sonucunu ölçmek gerekir.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın modernizasyon yaklaşımıdır. Mevcut sistemi incelemeden: “Baştan yapalım.” demek çoğu zaman erken verilmiş bir karardır. Bizim için modernizasyon kararının sırası şöyle olmalıdır: ASSESS ↓ MEASURE ↓ IDENTIFY BOTTLENECK ↓

SELECT STRATEGY

↓ PROVE ↓ MIGRATE ↓ MEASURE AGAIN Birinci prensip: Rewrite son seçeneklerden biri olmalı, yasak seçenek değil Rewrite kötü değildir. Ama en pahalı ve riskli seçeneklerden biri olduğu için gerekçelendirilmelidir. Şu ifade: “Eski proje kötü.” yeterli değil. Daha iyi: “Mevcut architecture nedeniyle yeni ülke/tenant desteği eklemek sistemin %70’ini değiştirmeyi gerektiriyor; mevcut framework destek dışı ve test coverage bulunmadığı için kademeli upgrade maliyeti yeni platform maliyetine yaklaşıyor.” Bu ölçülebilir gerekçedir. İkinci prensip: Çalışan business logic'i mümkünse koruyun Örneğin 10 yılda oturmuş: pricing logic tax logic approval logic varsa bunları yalnızca eski teknolojiyle yazılmış oldukları için yeniden icat etmek gerekmez. Bazı bölümler: API arkasına alınabilir. Bazıları refactor edilebilir. Bazıları gerçekten yeniden yazılabilir. Modernizasyon: ya hep ya hiç değildir. Üçüncü prensip: En problemli değil, en doğru sınırdan başlayın İlk modernizasyon modülünün tamamen kritik olması migration riskini büyütebilir. Tamamen önemsiz olması ise business value göstermez. İyi ilk aday: anlaşılır sınır + anlamlı değer + yönetilebilir risk kombinasyonudur. Dördüncü prensip: Veri migration'ını ilk sprintlerden test edin En büyük migration risklerinden biri: “Kod tamam, şimdi veriyi taşıyalım.” yaklaşımıdır. Daha iyi: Early sample data ↓ Migration prototype ↓ Validation ↓ Repeated rehearsal ↓ Final cutover modelidir. Microsoft’un modernizasyon envanteri ve data readiness guidance’ı da migration planına data cleansing, transformation ve validation’ın dahil edilmesini öneriyor. (Microsoft Learn) Beşinci prensip: Modernizasyon sırasında yeni sistem kadar eski sistem de yönetilmeli Migration aylar sürebilir. Bu sırada legacy sistem:

• security patch,
• monitoring,

backup açısından ihmal edilmemelidir. Çünkü müşteriler hâlâ onu kullanıyor olabilir. Altıncı prensip: Eski sistemi kapatmak proje milestone'ıdır Legacy sistem: trafik 0 oldu diye hemen silinmemelidir. Önce:

• data doğrulama,
• audit gereksinimleri,
• rollback süresi,
• backup,

retention kontrol edilmelidir. Sonra controlled decommission yapılabilir. Microsoft da application retirement için kullanım, teknik viability, compliance ve operasyon maliyetleri gibi kriterlerle yapılandırılmış karar verilmesini öneriyor. (Microsoft Learn)

Sonuç

Mevcut yazılım eskidiğinde karar:

Tut veya Baştan yap kadar basit değildir. Modernizasyon seçenekleri: Retain ↓ Rehost ↓ Replatform ↓ Refactor ↓ Rearchitect ↓ Rebuild ↓ Retire arasında değişebilir. Microsoft’un güncel modernizasyon çerçevesi de benzer biçimde her application için business value, effort ve technical constraints’e göre farklı strateji seçilmesini öneriyor. (Microsoft Learn) Büyük ve aktif legacy sistemlerde ise bütün ürünü tek seferde değiştirmek yerine eski ve yeni sistemin bir süre birlikte çalıştığı kademeli modernizasyon yaklaşımı riski azaltabilir. AWS’in Strangler Fig pattern’i bunun en bilinen teknik modellerinden biridir. (AWS Dokümantasyonu) Bu nedenle şirketlerin ilk sorması gereken soru: “Sistemi baştan mı yapalım?”

• değil;

“Bugünkü sistemde bizi gerçekten sınırlayan şey nedir ve bunu çözmek için gereken en küçük güvenli değişiklik nedir?” olmalıdır. Bazen cevap küçük bir dependency upgrade olur. Bazen database modernizasyonu. Bazen birkaç modülün yeniden tasarlanması. Bazen de gerçekten tamamen yeni bir sistem. Ama bu karar kodun yaşına göre değil, ölçülmüş teknik durum ve business değeri üzerinden verilmelidir.