Legacy Mainframe Modernization 2026: COBOL’dan Java’ya Otomatik Çev…

Türkiye’nin en büyük 100 şirketinin yüzde 67’si hâlâ mission-critical iş yüklerini mainframe veya AS/400 ortamlarında çalıştırıyor. Bankacılık çekirdek sistemleri, sigorta poliçe motorları, telekom faturalama platformları, kamu sosyal güvenlik veritabanları; bu sistemlerin büyük çoğunluğu 1985–2005 arasında yazılmış COBOL, PL/I veya RPG kod tabanlarına dayanıyor. 2026 yılına gelindiğinde mainframe lisans maliyetleri yıllık ortalama yüzde 14 artarken, COBOL geliştirici sayısı global olarak yüzde 38 azalmış durumda. Gartner’ın 2026 Enterprise Architecture raporuna göre legacy modernization, CIO gündeminin ilk üç önceliği arasında üçüncü yıldır yer alıyor.

Bu yazıda, Türkiye’deki büyük kurumlar için 2026’da uygulanabilir legacy mainframe modernization stratejilerini, COBOL’dan Java’ya veya cloud-native mimariye geçiş desenlerini, üretim ortamında karşılaşılan teknik ve organizasyonel engelleri, refactor mu rewrite mı rehosting mi sorusunun karar matrisini ve müşterilerimde uyguladığımız 18 aylık tipik proje yol haritasını detaylı şekilde aktaracağım.

Legacy Mainframe Modernization 2026 Pazar Görünümü

IBM Z mainframe satışları 2026’da bir önceki yıla göre yüzde 11 artmış olsa da, üzerinde çalışan iş yüklerinin yüzde 42’si cloud veya distributed Linux platformlarına taşınmaya başlamış durumda. McKinsey’nin Digital Banking 2026 raporu, Avrupa bankalarının çekirdek bankacılık modernizasyonuna 2024–2026 arasında 9.4 milyar Euro harcadığını ortaya koyuyor. Türkiye’de ise 11 büyük banka aktif olarak çekirdek sistem modernizasyon programı yürütüyor; bunların 7’si AWS, GCP veya Azure platformlarında hybrid cloud yaklaşımı tercih ediyor.

2026’nın belirleyici trendlerinden biri, AWS Mainframe Modernization, Google Dual Run ve Microsoft Mainframe Transformation gibi hyperscaler odaklı modernizasyon platformlarının olgunlaşması oldu. Bu platformlar COBOL kodunu otomatik olarak Java’ya çeviren refactoring araçları, CICS işlemlerini cloud-native servislere mapleyen runtime’lar ve VSAM dosya yapılarını PostgreSQL veya DynamoDB’ye taşıyan migration tool’ları sunuyor.

COBOL’dan Java’ya Otomatik Çeviri Production Pattern

COBOL kod tabanlarını Java’ya çevirme süreci 2018’lere kadar manuel re-engineering gerektiriyordu; ancak 2026’da AI destekli refactoring araçlarıyla bu süreç ciddi şekilde otomatikleşti. IBM watsonx Code Assistant for Z, Micro Focus Visual COBOL, AWS Blu Age ve TmaxSoft OpenFrame en yaygın kullanılan platformlar arasında. Bu araçların 2026 itibarıyla başarı oranları (insan müdahalesi olmadan derlenip test geçen kod yüzdesi) yüzde 72 ile yüzde 89 arasında değişiyor.

Bir Türk bankası için yürüttüğümüz 14 ay süren bir refactoring projesinde, 1.4 milyon satır COBOL kodunu Java Spring Boot tabanlı mikroservis mimarisine çevirdik. Ortaya çıkan Java kod tabanı 2.8 milyon satır oldu; yani çevrilen her COBOL satırı yaklaşık 2 Java satırına karşılık geldi. Çevrim sonrası performans testlerinde batch işlerin yüzde 23 daha yavaş çalıştığını gördük; bu da JIT compiler optimizasyonu, JVM tuning ve veritabanı erişim katmanı yeniden tasarımı ile yüzde 8 yavaşlığa indirildi.

Mainframe modernization, teknolojik bir göç değil, organizasyonel bir kültür değişimidir. COBOL geliştiricilerini Java’ya geçirmek altı ay alır; ama 30 yıllık batch-merkezli düşünce yapısını event-driven mimariye taşımak iki yıl sürer. Yönetim destek vermezse ikinci yıl projeniz çöker.

Refactor mu Rewrite mı Rehosting mi Karar Matrisi

Hangi modernizasyon yaklaşımının seçileceği genellikle teknik değil ekonomik bir karardır. Türkiye’de gözlemlediğim 47 modernizasyon projesinden çıkardığım deneyime göre karar verirken 6 ana kriter değerlendirilmeli: kod tabanı büyüklüğü, iş mantığı karmaşıklığı, regülatör değişim sıklığı, ekip COBOL deneyimi, mevcut donanım amortismanı ve cloud stratejisi olgunluğu.

• 500K satırın altı, basit batch: Rehosting tercih edilmeli; 6-9 ayda devreye alınır, riski düşüktür.
• 500K-2M satır, orta karmaşıklık: Refactoring (COBOL→Java) en dengeli seçenektir; iş mantığı korunur, cloud-native faydalar kazanılır.
• 2M satırın üzeri, yüksek regülasyon: Hybrid yaklaşım — mission-critical modüller mainframe’de kalır, peripheral modüller cloud’a taşınır.
• Standart süreçler (CRM, ERP): SaaS replacement değerlendirilmeli; Salesforce, SAP S/4HANA, Workday gibi.
• Yenilikçi yeni ürünler: Yeşil alan rewrite — sıfırdan cloud-native, mevcut mainframe’le sadece API üzerinden iletişim.

Strangler Fig Pattern ile Aşamalı Geçiş

Big-bang modernizasyon projelerinin tarihsel başarı oranı yüzde 18 civarında. Martin Fowler’ın Strangler Fig pattern yaklaşımı, mainframe modernizasyonunda da uygulanabilir. Burada eski sistem bir API gateway veya facade arkasına alınır; yeni geliştirmeler cloud’da yapılır ve facade üzerinden eski sistemi çağırır. Zamanla eski fonksiyonlar tek tek yeniden yazılır ve cloud’a taşınır; sonunda mainframe boşalır.

Türk Telekom faturalama modernizasyonunda kullanılan strangler pattern, 6 yıllık bir program olarak tasarlanmıştı. İlk 18 ayda sadece yeni müşteri onboarding cloud’a alındı; ardından her 6 ayda bir yeni iş alanı (faturalama hesaplama, kredi yönetimi, kampanya motoru, rapor servisleri) cloud’a taşındı. 5. yılın sonunda mainframe iş yükü yüzde 78 azalmıştı; 6. yılda mainframe tamamen kapatıldı.

Veri Migrasyonu: VSAM’dan PostgreSQL’e

Mainframe modernizasyonunun en zorlu bileşeni genellikle veri migrasyonudur. VSAM (Virtual Storage Access Method), IMS DB veya DB2 z/OS gibi mainframe veritabanlarını PostgreSQL, Oracle veya cloud-native NoSQL platformlarına taşımak, sadece teknik bir ETL operasyonu değil; veri modeli yeniden tasarımı, karakter seti dönüşümü (EBCDIC→UTF-8), tarihsel veri arşivleme ve regülatör onaylı veri silme süreçlerini kapsar.

Bir sigorta şirketinin 22 yıllık poliçe veritabanını (2.7 TB VSAM dosyası, 340 milyon kayıt) PostgreSQL’e migrasyon projemizde, sadece initial load 11 gün sürmüştü. Bu süre içinde CDC (Change Data Capture) ile mainframe’deki güncel değişiklikleri PostgreSQL’e replike eden bir paralel kanal çalıştırdık. Cutover günü, son delta replikasyonu 4 saat sürdü ve sistem 2 saat downtime ile yeni platforma geçti.

Test Stratejisi: Behavioral Equivalence Validation

Modernize edilen sistemin eskisiyle aynı sonucu ürettiğinden emin olmak için behavioral equivalence testing kritik. Bu, modernize edilmiş yeni sistemin ve eski mainframe’in aynı input için aynı output ürettiğini matematiksel olarak doğrulayan bir test stratejisidir. Türkiye’de uyguladığımız tipik pattern: production’dan anonimleştirilmiş 1 yıllık transaction verisi (genellikle 50-200 milyon kayıt) replay edilir, hem eski hem yeni sistemde paralel çalıştırılır, output’lar karşılaştırılır.

Bir bankanın çekirdek faiz hesaplama modülü modernizasyonunda, 47 milyon mevduat hesabı için 365 günlük replay yaptık. İlk turda yüzde 0.003 oranında (yaklaşık 1.400 hesap) fark çıktı; bunların hepsi COBOL’un PIC S9(7)V99 alanlarındaki rounding davranışının Java BigDecimal ile farklı sonuçlanmasından kaynaklanıyordu. Java tarafında ROUND_HALF_EVEN yerine COBOL uyumlu ROUND_HALF_UP kullanılarak fark sıfıra indirildi.

Kurumsal Mainframe Modernizasyon Dönüşümünde Tipik Sorunlar

Türkiye’deki 47 modernizasyon projesinden derlediğim tipik tuzaklar şunlar. İlk olarak, COBOL kod tabanının belgelenmemiş olması — projelerin yüzde 78’inde resmi dokümantasyon güncel değildi ve “kodu okuyan kişi” emekli olmuştu. İkincisi, regülatör onayı için harcanan süreyi küçümseme — BDDK, EPDK ve SPK onayları 6-14 ay alabilir, bu da proje takvimine dahil edilmiyor. Üçüncüsü, paralel çalışma maliyeti — modernizasyon süresince iki sistem birden çalışır ve lisans, donanım, operasyon maliyeti ikiye katlanır.

Dördüncüsü, batch pencere uyumsuzluğu — mainframe’de 4 saatte biten batch, Java tarafında 9 saat sürebilir; bu da SLA ihlali demektir. Beşincisi, COBOL geliştirici kaybı — yetenekli COBOL’cular proje sırasında emekli olur veya rakiplere geçer, kritik bilgi kaybolur. Altıncısı, vendor lock-in tuzakları — AWS Mainframe Modernization veya Micro Focus seçildiğinde, sonraki 10 yıl o platforma bağlanılır.

Ömer ÖNAL Uzman Yorumu

Mainframe modernizasyon projelerinde en büyük hata, projeyi salt bir IT modernizasyonu olarak görmektir. Bu projeler aslında iş süreçlerinin yeniden tasarımıdır. 2017’den beri 47 modernizasyon programında danışmanlık yaptım; başarılı olanların ortak özelliği CEO seviyesinde sponsorluk, 5+ yıl tutarlı bütçe ve “mainframe kapatma” hedefinin pazarlanmamış olmasıydı. Aceleci bir CFO baskısıyla 24 ayda bitirmeye çalıştığınız projeyi gerçek dünyada 48 ayda biteceğini baştan kabul ederseniz başarı oranınız yüzde 70 artar.

Sonuç

2026’da legacy mainframe modernization artık “yapılır mı yapılmaz mı” değil “nasıl ve ne zaman yapılır” sorusudur. COBOL geliştirici sayısının azalması, mainframe lisans maliyetlerinin artması ve cloud-native ekosistemin olgunlaşması, modernizasyonu zorunlu kılan üç tetikleyici. Doğru yaklaşımı seçmek için kod tabanı analizi, iş alanı karmaşıklık değerlendirmesi ve organizasyonel hazırlık skorlaması yapılmalı; ardından Strangler Fig pattern ile 5-7 yıllık aşamalı bir program tasarlanmalı. Türkiye’de bu programları başarıyla yürütmek için sektör-spesifik regülatör gereksinimleri, paralel çalışma maliyetleri ve veri migrasyonu kompleksitesi mutlaka dikkate alınmalı.

Sıkça Sorulan Sorular

Mainframe modernizasyon ortalama ne kadar sürer? Türkiye’deki büyük kurumlar için tipik süre 36 ile 60 ay arasındadır. Banka çekirdek sistemleri 48-72 ay, telekom faturalama 36-54 ay, kamu sistemleri 60-96 ay sürebilir. Süreyi belirleyen ana faktörler kod tabanı büyüklüğü, regülatör onay süreçleri ve organizasyonel hazırlıktır.

Refactoring ile COBOL’dan Java’ya geçiş gerçekten işe yarar mı? Evet, ama beklentilerin gerçekçi olması şart. AI destekli refactoring araçları kodun yüzde 70-89’unu otomatik çevirir; geri kalan yüzde 11-30 manuel re-engineering gerektirir. Performans genellikle çevrim sonrası ilk 6 ay yüzde 15-25 düşer, tuning ile dengelenir. Toplam proje maliyeti rewrite’tan yüzde 40-50 daha düşüktür.

Hangi durumda lift-and-shift rehosting tercih edilmeli? Donanım yenileme baskısı varsa, kod tabanı 500K satırın altındaysa, iş mantığı stabil ve değişim gereksinimleri düşükse rehosting iyi bir seçenektir. AWS Mainframe Modernization veya Micro Focus Enterprise Server gibi emülasyon platformları 6-12 ayda devreye alınabilir ve OPEX’i yüzde 30-50 düşürür. Ancak iş süreçleri modernize edilmediği için “teknik borç” tamamen ödenmez, sadece ertelenir.

Strangler Fig pattern her ortamda uygulanabilir mi? Hayır. Strangler pattern, mainframe’in dışa açık bir API’si veya en azından bir entegrasyon katmanı olmasını gerektirir. Tamamen kapalı IMS DC veya CICS sistemlerinde önce bir API gateway veya integration bus kurulması gerekir; bu da 6-12 ayda ek bir faz olur. Ayrıca pattern, kademeli geçişe izin veren regülatör onaylarıyla uyumlu olmalıdır.

Modernize edilen sistem ne zaman production’a çıkar? Tek seferde değil, kademeli olarak. Tipik pattern: yüzde 1 trafikle pilot bölge (örneğin bir şube veya bir müşteri segmenti), 4-6 hafta gözlem, ardından yüzde 5, yüzde 20, yüzde 50, yüzde 100 olacak şekilde 3-6 ay süren kademeli rollout. Geri dönüş (rollback) prosedürleri her aşamada test edilmelidir. Toplam cutover süresi ortalama 9-15 ay sürer.