Açık konuşayım: Yıllardır “modernizasyon” deyince aklıma hep aynı şey gelirdi (yanlış duymadınız). Bütçe toplantıları, 40 sayfalık migration planları, bir cuma akşamı yapılan ve pazartesi sabahı kâbusa dönen cutover’lar… Hani şu, üç ayda biterdi dediğin ama bir yılı bulan projeler. Bilen bilir.
Geçen hafta Microsoft Developer Channel’da yeni bir seri yayınlandı — GitHub Copilot Modernize 101. 9 bölümlük bir Java modernizasyon serisi. İlk iki bölümü izledim, üçüncüsünü de bu sabah kahve eşliğinde açtım. Şunu söyleyeyim: Modernizasyona bakış açımız ciddi şekilde değişiyor. Hem de kökten.
Bu yazıda seriden bahsedeceğim ama daha fazlası da var. Çünkü Logosoft’ta son 8 ayda 3 farklı kurumsal müşteride benzer dönüşümleri yaşadık — biri bir sigorta şirketinde Java 8’den Java 21’e geçiş, diğeri bir lojistik firmasında Struts tabanlı eski bir monolitin Spring Boot’a taşınması, üçüncüsü de… neyse önü aşağıda anlatacağım. Sahadan notlarla beraber gidelim.
Durun, bir saniye.
Modernizasyon Artık Proje Değil, Döngü
Eskiden modernizasyon deyince akla tek seferlik bir iş gelirdi. Bir kere girerdik, biraz uğraşırdık, sonra üç yıl kafamız rahat sanırdık; rahat değildi tabii, sadece öyle görünüyordu.
Bakın şimdi neden bu kadar değişti? Çünkü işin içine AI uygulamaları girdi. Müşteri “ChatGPT gıbı bir asistanımız olsun” diyor, sen de gidip Java 5 ile çalışan, Struts 1.3 üstüne kurulmuş, dependency’leri 2014’te kalmış bir kod tabanına bakıyorsun; orada AI’nın koşmasını beklemek biraz hayal ölür, önce o sistemi toparlamak gerekiyor — bence çok yerinde bir karar —
Vallahi, İşte tam burada döngü mantığı devreye giriyor:
- Assess — Elinde ne var, anla
- Upgrade — Önünü tıkayanı güncelle
- Migrate — Taşınması gerekeni taşı
- Validate & Deploy — Doğrula ve dağıt — bunu es geçmeyin
- Tekrarla
Akışın kendisi yeni değil aslında. Yeni olan taraf şu: Bu mekanik işlerin büyük kısmını artık agent’lar yapıyor. Siz oturup 400 tane import statement’ı tek tek `jakarta.*` diye çevirmiyorsunuz, build hatalarını saatlerce kurcalamıyorsunuz, Dockerfile yazarken de boğulmuyorsunuz (neyse ki). Bunları Copilot agent hallediyor, siz de gözden geçirip karar veriyorsunuz.
“Modernizasyon artık ‘bir gün yapacağız’ işi değil. Sprint’in içine giren, her ay biraz daha ilerleyen bir alışkanlık. Kazanan ekipler büyük rewrite yapanlar değil — modern kalmayı sistematik hâle getirenler.”
Evet.
Seride Neler Var? Bölüm Bölüm
Toplam 9 bölüm var. İlk ikisi yayında, kalanlar da önümüzdeki günlerde geliyor. Hızlıca bir özet geçeyim; sonra hangileri gerçekten iş görüyor, ona bakalım.
| Bölüm | Konu | Kime Hitap Ediyor |
|---|---|---|
| 0 | Seri Tanıtımı | Genel izleyici |
| 1 | Java Uygulamalarını Değerlendirme | Mimar, tech lead |
| 2 | Java, Spring, Jakarta EE Yükseltme | Senior dev |
| 3 | Java 5 / Struts 1.3 Monolit Migrasyonu | Eski sistemlerle uğraşanlar |
| 4 | Veritabanı Modernizasyonu | DBA, backend dev |
| 5 | Copilot Modernization Task’ları Özelleştirme | Power user |
| 6 | Container’lama ve Deploy | DevOps |
| 7 | CLI ve CI/CD ile Ölçeklendirme | Platform team |
| 8 | Azure’da End-to-End Modernizasyon | Tam paket isteyenler |
Bence en kıymetli bölüm 3 numara. Çünkü Java 5 ve Struts 1.3 deyince bazıları hemen “ya bunu kim kullanıyor ki” diyor. Ama işin aslı biraz başka; Türkiye’de banka, sigorta ve kamu tarafında hâlâ bu tıp sistemler var, hatta geçen yıl bir devlet bankasının iç sisteminde Struts 1.2 gördüm (evet, yanlış okumadınız), adamlar 2007’den beri patch’leyerek getirmişler. Şaka değil.
Bölüm 5 — Asıl Cevheri Burada Görüyorum
Customize Copilot Modernization Tasks. Adı biraz kuru duruyor, kabul. Ama içerik baya iş görüyor; çünkü her şirketin kendi coding convention’ı, kendi internal library’leri, kendi “biz böyle yapmıyoruz” kuralları var. Generic bir AI agent gelip senin 15 yıllık iç framework’üne göre kod yazamıyor, yanı en azından kutudan çıktığı hâliyle pek yazamıyor. Custom task tanımlamak şart gıbı duruyor.
Logosoft’ta bir telekom müşterimizde bunu yaşadık. Copilot generic Spring Boot kodu üretti; kod fena değildi ama müşterinin internal logging wrapper’ını kullanmadı. Sonra 200 dosyada find&replace yapmak zorunda kaldık, baya uğraştırdı açıkçası (kendi tecrübem). Custom task tanımlasaydık o iş baştan çözülürdü. Ders alındı.
Türkiye’deki Şirketler Açısından Durum
İşte, şimdi açık konuşayım. Bu seri aslında Amerikan piyasasına göre kurulmuş, yanı oradaki “AI uygulaması geliştireceksen modernize ol” mesajı bayağı oturuyor. Türkiye tarafında tablo biraz başka, hatta yer yer bambaşka görünüyor.
Kurumsal müşterilerde gördüğüm şey şu: modernizasyon kararı çoğu zaman AI yüzünden değil, daha gündelik dertlerden çıkıyor. Lisans faturası kabarıyor, ekipte o eski teknolojiyi bilen kişi azalıyor, bir de denetim kapıya dayanıyor; işin aslı, motivasyonlar değişiyor ama sonuç yine aynı yere bağlanıyor (ilk duyduğumda inanamadım)
- Lisans maliyeti — Eski Oracle WebLogic veya IBM WebSphere lisansı tutuyor. Müşteri de dönüp Spring Boot + open source stack’e geçmek istiyor, çünkü rakamlar can sıkmaya başlıyor.
- Personel bulamamak — Junior developer’lar Struts bilmiyor. Bilenler de yavaş yavaş emekli oluyor. Yeni mezunu alıp 6 ay Struts öğreteyim diyorsun, ölmüyor; hani öyle kolay değil.
- KVKK ve denetim — Eski sistemler audit log’u düzgün tutmuyor. BDDK, EPDK gıbı denetçiler artık daha net iz bırakmanızı bekliyor, observability tarafı da burada devreye giriyor. (bence en önemlisi)
AI kısmı genelde dördüncü sıraya düşüyor. Bu kötü bir şey değil, tam tersine bazen çok daha gerçekçi bir başlangıç oluyor; çünkü önce sistemi ayakta tutuyorsun, sonra üstüne AI koyuyorsun, yoksa temel çökükse parlak fikirlerin pek anlamı kalmıyor. Bu konuyla ilgili mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.
Maliyet Tarafı — Açık Konuşalım
Yanı, Bir lojistik firmasında 240 bin satırlık Java 8 monolitini Java 21 + Spring Boot 3’e taşıdık. Dört ay sürdü; ekipte 3 senior vardı, 1 junior vardı ve ben part-time destek verdim (eskiden bu işin 9-12 aya yayılması hiç şaşırtmazdı), yanı fark az buz değil.
Copilot Modernize agent’ı en çok şu işlerde zaman kazandırdı. Hele bir de `javax.*` → `jakarta.*` geçişinde baya iş gördü; eskiden hafta sürer dediğim iş iki günde toparlandı, sonra deprecated API replacement’ları geldi ve JUnit 4’ten JUnit 5’e geçiş de nispeten rahat aktı.
Evet, doğru duydunuz.
- `javax.*` → `jakarta.*` migration’ı (eskiden hafta sürerdi, 2 günde bitti)
- Deprecated API replacement’ları (bu kritik)
- JUnit 4’ten JUnit 5’e geçiş
- Dockerfile ve Helm chart generation
GitHub Copilot Enterprise lisansı kişi başı aylık yaklaşık 39 dolar. Dört kişilik ekipte bu ayda kabaca 156 dolar ediyor; dört ayda da 624 dolar yapıyor. Buna karşılık en az 2-3 ay manuel işi cebimizde tuttuk, yanı hesap çok süslü değil. Net — TL tarafında bakınca da bir senior developer’ın üç aylık maaşının yanında bu lisans neredeyse yuvarlama hatası gıbı kalıyor. copilot konusundaki yazımız yazımızda bu konuya da değinmiştik.
Startup vs Enterprise — Yaklaşım Farkı
Küçük bir ekipseniz ya da startup tarafındaysanız, açık konuşayım: bu seriyi izleyin ama her bölümünü koşup uygulamayın. İşin aslı, sizin için gerçekten lazım olan parçalar şunlar:
Bir dakika — bununla bitmedi.
- Bölüm 2 (Java/Spring upgrade)
- Bölüm 6 (Containerize & deploy)
- Bölüm 8 (End-to-end Azure) — ciddi fark yaratıyor
Geri kalan kısım biraz fazla kaçıyor, yanı overkill oluyor. Çünkü sizde Struts 1.3 monolit falan yok zaten, öyle bir yükle boğuşmuyorsunuz. CI/CD pipeline’ınızda da 200 tane mikroservis dizili değil; hani o yüzden işi sade tutmak daha mantıklı. Daha fazla bilgi için Azure SQL’de AI_GENERATE_EMBEDDINGS GA Oldu: Saha Notları yazımıza bakabilirsiniz.
Açıkçası, Büyük kurumsal yapıda işe tablo değişiyor, burada iş biraz tersine dönüyor — özellikle Bölüm 5 ve 7‘yi dikkatle izlemek lazım. Neden? Çünkü ortada 80 tane uygulama varsa, hepsini tek tek elle modernize etmeye kalkınca insanın günü bitiyor, üstüne bir de CLI ile batch işlemler. CI/CD entegrasyonu yoksa bu iş iyice sürüncemeye giriyor (kendi tecrübem) Azure Avrupa Yatırımları: Egemen Bulut ve AI Yarışı yazımızda bu konuya da değinmiştik.
Bir dakika — bununla bitmedi.
Sahadan Bir Hata Hikâyesi
Geçtiğimiz ay bir sigorta şirketinde POC yaparken, Copilot Modernize agent bana ufak bir sürpriz yaptı. Java 8’den Java 17’ye geçişte, agent `SimpleDateFormat` kullanan yerleri alıp `DateTimeFormatter`’a çevirdi. Kağıt üstünde iyi duruyor, hatta ilk bakışta “tamam işte” dedirtiyor. Ama sonra işin rengi değişti.
// Eski kod (çalışıyordu)
SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
Date d = sdf.parse(input);
// Agent'ın ürettiği yeni kod
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("dd/MM/yyyy");
LocalDate d = LocalDate.parse(input, dtf);Tuhaf ama, Sorun neydi? `Date` ile `LocalDate` aynı şey değil. Biri eski dünyadan geliyor, diğeri daha modern bir tarih tipi. Tıp değişince olay sadece satır değiştirmekle bitmiyor. Bu metodu çağıran 47 yerde return type da değişmesi gerekiyordu, ama agent oraya dokunmadı, sadece bu metodu güncelledi. Build patladı tabii. Ben de üç saat hata ayıkladım. Evet, baya can sıkıcıydı. Bu konuyla ilgili vcpkg Nisan 2026 Güncellemesi: Paralel Build Kilitleri Geldi yazımıza da göz atmanızı tavsiye ederim.
Ders şu: Agent ne kadar iyi görünürse görünsün, type değişikliği isteyen refactor işlerinde tek başına bırakınca tökezleyebiliyor. Mesela de zincirleme etki varsa, bir yerde yapılan küçük dokunuş başka on yeri oynatıyor (ve bunu bazen ilk bakışta fark etmiyorsunuz). Bu konuyu Agent Pull Request’leri Her Yerde: Doğru Review Nasıl? yazımda da açmıştım. PR review disiplini olmadan bu işler yürümüyor. Kısacası bu kadar.
Pratik İlk Adımlar
“Tamam Aşkın, anladık. Ne yapalım şimdi?” diyorsanız, lafı gevelemeden somut gidelim: önce küçük bir POC repo seçin, sonra lisans işini halledin, ardından da agent’ın ne yaptığını gerçekten görün. Evet, ilk bakışta basit duruyor.
- Bir POC repo seçin. Production’a atlamayın. Biraz eski kalmış bir uygulama daha iyi ölür — mesela Java 8 ya da 11 olan bir repo, hem risk az oluyor hem de fark daha net çıkıyor.
- GitHub Copilot Enterprise veya Business lisansı edinin. Free tier tarafında modernize agent’ı yok, yanı orada beklemek biraz boşa gidiyor gıbı. İşe yarayan senaryo için doğru lisans lazım.
- Bölüm 1’i izleyin, assess raporu çıkarın. Bu rapor boş bir çıktı değil; eski kodun ne durumda olduğunu tek bakışta gösteriyor (hangı paketler var, nerede teknik borç birikmiş, hangisi elden geçmeli), baya iş görüyor açıkçası. (bu kritik)
- Küçük bir upgrade ile başlayın. Spring Boot 2.7’dan 3.2’ye geçmek gıbı düşünün mesela; Java sürümüne hiç dokunmadan başlamak çoğu zaman daha mantıklı oluyor, çünkü aynı anda iki cephede savaşmıyorsunuz.
- Sonucu review edin, gerçekten review edin. Agent’ın PR’ına “approve all” basmak iyi fikir değil. Hatta tam tersine, en hızlı patlayan yer orası oluyor; diff’e bakın, testleri kontrol edin, gerekiyorsa geri çevirin.
Bunu yaşayan biri olarak söyleyeyim, Bunları yaptıktan sonra döngü kendi kendine oturuyor. İkinci uygulamada neyin nerede takıldığını zaten sezersiniz. Üçüncüde işe iş CI/CD tarafına kayıyor; orada da GitHub Copilot CLI: Kurumsal Plugin Yönetimi Public yazımdaki yaklaşım işinize yarayacak. Neyse uzatmayayım, temel akış bu.
Eleştirel Bakış — Her Şey Toz Pembe Değil
Şimdi açık konuşayım. Bu seri Microsoft’un kendi kanalından geliyor, hâliyle (söylemesi ayıp) biraz pazarlama kokusu var. Neden önemli bu? Gerçek hayatta iş öyle pürüzsüz akmıyor; bazen agent iyi kod çıkarıyor, bazen de insanın gidip iki satır elle düzeltmesi gerekiyor.
- Agent her zaman doğru kod üretmiyor. Yaklaşık %15-20 oranında manuel müdahale gerekiyor. — bunu es geçmeyin
- Çok büyük monolit’lerde (1M+ satır) agent context limit’lerine takılıyor.
- Hele bir de iç frameworkler veya custom annotation’lar varsa agent yolunu kaybediyor.
- Veritabanı migration’ı (Bölüm 4) henüz yeterince olgun değil — şema değişikliklerinde temkinli olun. (bence en önemlisi)
Evet, can sıkıcı tarafı bu. Ama dür bir saniye — yine de tabloyu bayağı karartmayayım; kağıt üstünde fena görünmüyor, pratikte biraz daha pişmesi lazım, özellikle de büyük kod tabanlarında ve özel framework katmanlarında, yoksa insan “bu niye böyle öldü” diye ekrana bakıp kalabiliyor.
Peki ne oluyor? Üç yıl önce bunların çoğu hayal gıbı duruyordu, şimdi işe en azından konuşabiliyoruz, deniyoruz. Üstüne gerçek kod yazıyoruz. Az şey değil bu.
Sıkça Sorulan Sorular
GitHub Copilot Modernize for Java şu an GA mi?
Hayır, hâlâ public preview aşamasında — Yanı production kritik sistemlerde kullanırken dikkatli olun. Microsoft 2026 başını hedefliyor ama açıkçası bu tarih kesin değil. Preview olduğu için bazı feature’lar değişebilir, bunu göz önünde bulundurun.
Copilot Modernize sadece Java için mi çalışıyor?
Şu an Java odaklı..NET için ayrı bir Copilot upgrade modu zaten var. Python ve Node.js tarafında da çalışmalar yürüyor ama henüz resmî bir duyuru yok. Aslında ekosistem oldukça hızlı genişliyor, takipte kalmakta fayda var.
Hangı Copilot lisansı modernize özelliklerini içeriyor?
Copilot Business ve Copilot Enterprise planlarında mevcut. Individual planda ne yazık ki yok. Bence modernize task’ları için Enterprise daha mantıklı bir seçim — hani policy yönetimi ve audit log tarafı çok daha güçlü orada.
Java 5 gıbı çok eski sürümlerden direkt Java 21’e geçilebilir mi?
Teknik olarak agent bunu yapmaya çalışıyor, ama tecrübeme göre önerilecek bir yol değil. Önce Java 8, sonra 11, ardından 17 ya da 21 şeklinde adım adım gitmeniz çok daha sağlıklı. Mesela sıçrama çok büyük olursa hangı adımda ne kırıldığını anlamak gerçekten zorlaşıyor — her adımda test ortamında doğrulama yapmak şart.
Bu agent’lar veritabanı stored procedure’lerini de modernize edebiliyor mu?
Şunu fark ettim: Kısmen. Basit SQL transformation’larını hallediyor ama karmaşık geçişlerde — mesela Oracle PL/SQL’den PostgreSQL’e — hâlâ insan eli gerekiyor. Bölüm 4’te bu konuya değiniyoruz aslında (ki bu çoğu kişinin gözünden kaçıyor). Yine de beklentilerinizi çok yüksek tutmayın bence, o tarafta hâlâ yol var.
Kaynaklar ve İleri Okuma
Vallahi,
Microsoft Java DevBlog — GitHub Copilot Modernize 101 Duyurusu
Azure Java Migration Resmî Dokümantasyonu
GitHub Copilot Resmî Sayfası ve Feature Listesi
Modernize Java Apps with AI — YouTube Playlist
Ne yalan söyleyeyim, Son olarak şunu söyleyeyim: Modernizasyon gitmiyor, sadece şekil değiştiriyor. Kazananlar en büyük rewrite’ı yapanlar değil — modern kalmayı sistemleştirenler olacak. Bence bu serinin asıl mesajı da tam olarak bu zaten.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
