GitHub Copilot Upgrade Canvas: .NET Modernizasyonu Yeni Boyutta

Bir.NET uygulamasını modernize etmek… Kulağa basit geliyor değil mi? Prompt yazıyorsun, ajan koşuyor, bitti — Keşke öyle olsaydı.

Gerçek hayatta işler pek öyle yürümüyor. Bir upgrade projesi başlayınca önce uygulamayı anlamaya çalışıyorsunuz, sonra bağımlılıkları tarıyorsunuz, ardından plan çıkarıyorsunuz, kod dönüşümlerini uyguluyorsunuz, build hatalarını ayıklıyorsunuz, en sonda da test tarafına dalıyorsunuz; üstelik her adım bir öncekini bozabiliyor, yanı iş biraz domino taşı gibi ilerliyor. Bir NuGet paketini güncelliyorsunuz, hop breaking change çıkıyor. Build patlıyor. Sonra bir bakmışsınız task sırası bile değişmiş.

İşte GitHub Copilot Upgrade agent tam bu dağınık akışı biraz olsun toparlamak için var. Şimdi bunun üstüne bir de upgrade canvas geldi; yanı sohbet penceresinde kaybolan mesajları, sağa sola serpiştirilmiş Markdown dosyalarını ve PR yorumlarını tek tek kovalamadan modernizasyon sürecini tek ekrandan yönetebiliyorsunuz. Fena değil açıkçası.

Bunu biraz açayım.

Evet.

Peki, peki neden?

Çünkü upgrade işleri çoğu zaman “bir komut verelim bitsin” seviyesinde kalmıyor. Asıl mesele şu: neyi değiştirdiğinizi bilmek istiyorsunuz, hangi dosyada ne öldü görmek istiyorsunuz. Bir yerlerde sessizce kaçan detayları sonradan avlamak istemiyorsunuz. Hani insan bazen bakıyor da, “ben bunu az önce nerede gördüm?” diye kendi kendine soruyor ya, işte o karmaşa azalıyor — valla güzel iş çıkarmışlar —

Şey var bir de: Canvas tarafı sadece görsel rahatlık sağlamıyor gibi dürüyor; akışın parçalarını yan yana tutunca karar vermek kolaylaşıyor. Mesela bir yerde dependency uyarısı görüyorsunuz, başka yerde ajan önerisi dürüyor (arada küçük bir not da düşülmüş oluyor), sız de “tamam burası mantıklı. Şu kısmı ben elle geçeyim” diyebiliyorsunuz. Yanı kontrol hissi geri geliyor.

İnanın, Tabiî her şey güllük gülistanlık değil. Bu tip araçlar işi hızlandırıyor ama düşünmeyi sizin yerinize yapmıyor; zaten iyi tarafı da burada. Az önce anlattığım o kaos var ya, işte önü düzenli hâle getiriyor ama karar anında hâlâ sizin kafa çalıştırmanız gerekiyor. Burada, sız ne dersiniz?

Neden Upgrade Canvas Fark Yaratıyor?

Şimdi açık konuşayım. Copilot Upgrade agent ilk çıktığında da iş görüyordu, bunda laf yok. Ama bir pürüz vardı: agent çalışırken ne yaptığını izlemek pek kolay değildi; bir yandan sohbette “özet çıkar” diyordunuz, sonra dönüp Markdown raporlarına bakıyordunuz, ardından kod diff’ine göz atıyordunuz. Üç ayrı yer, üç ayrı bilgi. Dağınık yanı.

İlginç olan şu ki, Canvas bu işi tek ekrana topluyor. Assessment (değerlendirme), plan, tasklar, execution durumu, kod değişiklikleri, build hataları — hepsi canlı canlı aynı görünümde dürüyor. Hani bir müzik prodüktörünün mixing console’u olur ya, işte öyle düşünün; hangi kanalda ne var, anında görüyorsunuz, biraz kurcalayınca da tablo daha netleşiyor.

Bu neden önemli? Çünkü modernizasyon steer edilmesi gereken bir süreç. Agent’ı tamamen salarsanız, hayatı bir yerde yanlış tarafa kaydığını çoğu zaman en sonda fark ediyorsunuz; o noktada da iş işten geçmiş olabiliyor. Canvas sayesinde ortada yakalıyorsunuz, müdahale ediyorsunuz, hatta bazen yönü baştan çeviriyorsunuz.

Modernizasyon bir prompt değil, bir workflow. Ve workflow’lar sohbet penceresine sığmıyor. Canvas’ın en büyük katkısı da bu farkı kabullenmiş olması.

Assessment’tan Execution’a: Süreç Nasıl Işliyor?

Canvas açıldığında agent önce bir tür atıyor, hani etrafi kokluyor gibi (evet, doğru duydunuz). Su soruların peşine düşüyor:

• Uygulama hangi.NET sürümünü hedefliyor? (Hâlâ.NET Framework 4.7.2’de mi takılı, yoksa.NET 6’da mi?)
• Hangi NuGet paketleri guncellenmeli, hangileri artık deprecated?
• Breaking API değişiklikleri neler? Kod tarafında nereleri kirar?
• Hangi projeler birbirinden bağımsız yukseltilebilir?
• Neyi önce, neyi sonra yapmak lazım?

Bir bakıma, peki neden? Çünkü bu sorulara net cevap üretmek, modernizasyonun en can sıkıcı yeri oluyor. Yıllardır sahada gördüğüm en yaygın hata su: ekipler direkt “hadi TargetFramework’u degistirelim” diye başlıyor. Sonra üç gün build hatalariyla bogusuyorlar; bazen tek bir paket yüzünden bütün plan dağılıyor (ve kimse ilk gün bunu konusmamis oluyor) (ki bu çoğu kişinin gözünden kaçıyor)

Assessment bitince agent düzgün bir upgrade planı cikartiyor. Planı da executable implementation tasklarina boluyor. Yanı “su paketi güncelle, su API’yi değiştir, su proje referansını yenile” gibi somut adımlar geliyor ortaya. Execution başladığında canvas her task’in durumunu canlı gösteriyor. Basariliysa yeşil, patlarsa kırmızı; üstüne tıklayıp diff’e bakabiliyorsunuz (inanın bana)

Hmm, bunu nasıl anlatsamdı…

Şöyle ki, Tam da öyle.

Küçük Bir Örnek Akış

Diyelim ki elinizde.NET 6 üzerinde koşan bir ASP.NET Core Web API var ve sız bunu.NET 9’a taşımak istiyorsunuz. Canvas’ta görünen tipik akış şöyle olabilir:

[Assessment]
✓ Detected:.NET 6.0 (net6.0)
✓ 14 NuGet paketi tarandi
⚠ 3 paket.NET 9 uyumsuz sürümde
⚠ 2 breaking API kullanımı bulundu
[Plan]
1. Central Package Management'a gecis
2. TargetFramework'u net9.0 yap
3. EF Core 6 → EF Core 9 migration
4. Deprecated IHostingEnvironment kullanimlarini degistir
5. Build & test
[Execution]
▶ Task 1/5 çalışıyor...

Bunun sohbet penceresinde nasıl görüneceğini bir düşünün; biraz kalabalık ama idare eder bir akış var aslında. Her satır bir mesaj, aralara “peki devam edelim mi?” soruları giriyor, ekran kaydirarak son durumu takip ediyorsunuz (ve açık konuşayım, bu tek görünüm bazen insana rahat nefes aldirtıyor). Canvas ile olay tam olarak bu.

Nerede Kullanabilirsiniz? Her Yerde Aslında

Canvas özelliği GitHub Copilot uygulamasının içinde dürüyor, ama işin aslı Upgrade agent artık epey yayılmış durumda. Kısaca toparlayayım: aynı akış, farklı kapılar; bazen Visual Studio’dan giriyorsunuz, bazen terminalden, bazen de Copilot App içinden ilerliyorsunuz. Garip değil mi?

Garip gelecek ama, Evet.

İşte tam da bu noktada devreye giriyor.

Aynı workflow her yerde çalışıyor gibi düşünün. Sabah Visual Studio’da başlattığınız bir upgrade’i öğleden sonra Copilot CLI tarafında devam ettirebiliyorsunuz; yanı kağıt üstünde güzel, hatta baya iş görüyor. Ama dur bir saniye — pratikte ufak pürüzler çıkabiliyor, özellikle çok büyük solution’larda VS Code extension bazen yavaşlıyor (hmm, orada biraz nefes almak gerekiyor), bunu da açıkça söylemek lazım.

Burada, peki neden? Çünkü modernizasyon işi tek bir araca sıkışınca tuhaflaşıyor; biri editörde rahat ediyor, diğeri terminalde daha hızlı koşuyor. Sız ne dersiniz?

Tam da öyle.

Türkiye’deki Kurumsal Ekipler İçin Ne Anlama Geliyor?

Açıkçası, Sahada gördüğüm tablo şu: Türkiye’de, özellikle bankacılıkta, sigortada ve kamu tarafında, hâlâ hatırı sayılır miktarda.NET Framework 4.x kodu dönüp dürüyor. Bunu.NET 8 ya da 9’a taşımak yıllardır konuşuluyor; peki neden bir türlü bitmiyor? İki ana sebep var: zaman yok. risk yüksek.

Bir bakıma, copilot Upgrade agent bu iki derdi de sihirli şekilde yok etmiyor, açık konuşayım. Ama işin temposunu baya değiştiriyor. Daha önce bir senior developer’ın 2 hafta harcayacağı assessment işi, agent ile 1-2 saate inebiliyor; karar vermek, planı süzmek ve riskli yerleri işaretlemek yine insana kalıyor, fakat mekanik yük ciddi biçimde azalıyor — bence çok yerinde bir karar —

Ve işler burada ilginçleşiyor.

Açıkçası, Bir de raporlama kısmı var, hani en can sıkıcı taraflardan biri. Yönetim “nerede kaldık?” diye sorduğunda elinizde çoğu zaman ya bir Jira board oluyor ya da güncellenmemiş bir Excel kalıyor. Canvas’ın ürettiği yapılandırılmış çıktı — plan, tasklar, execution durumu — bu işi epey rahatlatıyor; steering committee’ye ekran görüntüsü atmak bile bazen yetiyor.

Küçük Ekip mi, Kurumsal Yapı mı?

Aslında, Bu tool herkese aynı tonda konuşmuyor aslında. Küçük startup’larda hikâye başka gidiyor, büyük enterprise tarafında işe bambaşka bir oyun oynanıyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Küçük ekipseniz (5-10 developer, birkaç mikroservis) Copilot Upgrade’i direkt VS Code ya da CLI üzerinden çalıştırıp bir günde toparlayabilirsiniz. Assessment sonucuna bakıp “evet devam” demek gayet makul; çünkü risk düşük. Kod tabanı da öyle çok dallanıp budaklanmış değil.

Kurumsal yapıda işe (50+ proje, iç içe geçmiş dependency graph’ler, compliance gereksinimleri) canvas’ı açıp her adımı tek tek onaylayarak ilerlemek daha mantıklı geliyor. Üstelik agent’ın önerdiği paket sürümlerini kendi iç NuGet feed’inizle karşılaştırmak, güvenlik ekibinin onay listesindeki sürümlerle eşleştirmek şart; bu son kısım hâlâ manuel kalıyor. Copilot sizin approved package list’ınızı bilmiyor.

Ne Kadar Tutar? FinOps Cephesi

Bu soruyu Türkiye’de neredeyse herkes soruyor, o yüzden lafı dolandırmadan gireyim. GitHub Copilot lisansı zaten var mı, yok mu? Varsa, Upgrade agent için ekstra bir kalem açılmıyor; aynı lisansın içinde dönüyor (bizzat test ettim). Ama işin bir de premium request tarafı var, hani asıl sürpriz orada çıkıyor: agent uzun süre çalışınca ve büyük context yutunca, plan bazlı kota beklediğinizden hızlı eriyebiliyor.

Bunu detaylı ele aldığım VS Code Haziran 2026 Copilot: Paralel Ajanlar ve Maliyet Netliği yazısına da bakabilirsiniz — orada yeni maliyet modelini örneklerle anlattım, bir de nerede ne kadar can yakıyor önü biraz kurcaladım.

Kaba bir hesap yapayım: orta büyüklükte (30 proje, 200 bin satır kod) bir.NET Framework 4.8 ->.NET 9 upgrade’ını agent ile koşturduğunuzda, plan bazlı request tüketimi Business plan’de tek seferde %5-10 bandına geliyor. Az değil ama abartılacak gibi de durmuyor. Yanı ayda birkaç kez böyle büyük upgrade yapıyorsanız bile lisans genelde yetiyor. Fakat işi sürekli ajana (söylemesi ayıp) bırakıyorsanız, işte orada üst plana göz atmak gerekebilir;. Tablo bir noktadan sonra değişiyor.

Sınırları ve Eksikleri: Dürüst Değerlendirme

Doğrusu, Şimdi biraz frene basalım. Burada, copilot Upgrade agent iyi hoş, ama kusursuz değil; bunu baştan söylemezsem içim rahat etmez.

Şunu söyleyeyim, Birincisi: custom framework’lerde zorlanıyor. Şirket içinde yazılmış, dokümanı az, hatta bazen kimsenin tam sahiplenmediği iç framework’ler varsa (Türkiye’de bu durum sandığınızdan daha sık çıkıyor), agent oralarda biraz tökezliyor, çünkü bağlamı görüyor ama niyeti tam çözemiyor.

İkincisi: test coverage’ı olmayan projelerde riskli. Agent kodu dönüştürüyor, build yeşile dönüyor, sonra da “tamamdır” havasına giriyor;. Runtime tarafında ufak bir kayma — itiraz edebilirsiniz tabi — olmuş olabilir, test yoksa bunu yakalamak zor. O yüzden modernizasyona girişmeden önce en azından temel bir integration test seti hazırlamak şart gibi dürüyor.

Üçüncüsü: plan bazen aşırı iyimser. “Beş taskta biter” diyor, sız de fena olmayan bir hızla başlıyorsunuz, sonra üçüncü taskta dependency conflict patlıyor ve planın yarısı yeniden şekilleniyor; açık konuşayım, bu kötü bir şey değil ama beklentiyi baştan ona göre ayarlamak gerekiyor.

Şöyle söyleyeyim, Dördüncüsü ve belki en çok can sıkan tarafı: WPF ve WinForms migration tarafında hâlâ zayıf. Agent server-side.NET işlerinde daha rahat ediyor (ASP.NET Core, Worker Service, Console App gibi senaryolarda baya iş görüyor), desktop tarafına gelince biraz ham kalıyor. Evet, burada ilerleme lazım.

İşin garibi, Tam da öyle.

Pratik Rehber: İlk Denemeyi Nasıl Yapmalı?

Yanı, Diyelim ki ikna oldunuz, denemek istiyorsunuz. Neden önemli bu? İlk işi production kritik olmayan bir yerde yapın, yoksa işler karışıyor; ben genelde küçük bir servisle başlıyorum (tek başına duran, birkaç bin satırlık bir microservice gayet yeterli), monolite girince insanın kafası çabuk doluyor.

1. Küçük bir servis seçin. Tek başına duran, birkaç bin satırlık bir microservice ideal. Monolitle başlamayın; ilk denemede kaybolursunuz, sonra da “biz nerede yanlış yaptık” diye bakakalırız.
2. Branch açın. “modernize/net9-upgrade” gibi net bir işim verin. Main’e asla direkt işlem yapmayın, çünkü sonra geri dönüşü toparlamak uğraştırıyor.
3. Assessment’i okuyun. Agent’ın ürettiği raporu satır satır gözden geçirin. Anlamadığınız bir öneri varsa, çekinmeden doğrudan agent’a sorun; bazen ilk okuduğunuz şey başka, aslında kastettiği şey bambaşka çıkıyor.
4. Planı onaylayın. Sıralamayı değiştirmek isteyebilirsiniz. Canvas üzerinden bunu yapabiliyorsunuz; burada ufak bir dokunuş bazen tüm akışı daha mantıklı hâle getiriyor, bazen de tam tersi oluyor açık konuşayım.
5. Execution’ı adım adım koşturun. Her taskten sonra build’i ve testi manuel doğrulayın. “Tak tak hepsi geçsin” modu tehlikeli, çünkü küçük bir sapma sonradan büyüyüp can sıkabiliyor. — bunu es geçmeyin
6. PR açın. Code review’da diğer developer’ların gözüyle bir daha bakılsın. Agent’ın kararları her zaman idiomatic değil; yanı kağıt üstünde doğru görünen şey, pratikte biraz yamuk durabiliyor.

Daha açık söyleyeyim, peki neden? Çünkü ilk turda amacınız hız değil, güven kazanmak. Biraz yavaş gidin ama ne yaptığınızı bilin; aksi hâlde otomasyon var diye rahatlayıp sonradan ekstra iş çıkarabiliyorsunuz.

Bu arada.NET LTS sürümleri konusunda da hatırlatmak isterim: .NET 8 ve.NET 9 İçin Son Tarih: 10 Kasım 2026 yazısında detaylı yazdım. Yanı upgrade’i sonsuza kadar erteleyemezsiniz; takvim bir yerden sonra kapıya dayanıyor, hoşunuza gitse de gitmese de böyle.

Evet.

Visual Studio 2026 Entegrasyonu

Bu tarafa da hızlı bir not bırakayım. Visual Studio 2026’nın modernizasyon akışı, canvas mantığını IDE’nın içine de taşıyor; yanı o iş ayrı bir ekranda dolaşmıyor, doğrudan editörün içinde elinizin altında dürüyor. Visual Studio Build 2026: Ajanlar, Modernizasyon ve Yeni Akış yazısında buna biraz daha detaylı girmiştim.

Size bir şey söyleyeyim, Kısaca şöyle: ekip. VS 2026 kullanıyorsa, ayrıca GitHub Copilot uygulamasını kurup uğraşmanız gerekmiyor. IDE içinden aynı deneyimin daha kısa bir versiyonunu alıyorsunuz, fena değil yanı. Ama uzun süren, birden fazla developer’ın el attığı büyük modernizasyon işlerinde canvas’ın merkezî görünümü daha kullanışlı oluyor; çünkü herkes aynı noktaya bakıyor, konu dağılmıyor. Peki neden? Çünkü böyle işlerde ekranın ortasında tek bir referans görmek bazen yarım saat kazandırıyor, bazen de saçma sapan sürtüşmeleri baştan kesiyor.

Peki Sonuç?

Bi saniye — Modernizasyon eskiden bir developer’ın haftalarca boğuştuğu, sonra da “keşke hiç başlamasaydım” dediği işlerden biriydi. Şimdi işe iş biraz değişti; agent yön veriyor, developer da arada dümeni tutuyor,. Workflow bambaşka bir yere kayıyor. Bu iyi mi? Bence evet, ama öyle koşulsuz falan değil.

Şartı net: agent’ın kararına gözünüz kapalı güvenmezseniz iyi. Ürettiği planı, önerdiği paket sürümlerini, yaptığı kod dönüşümlerini gerçekten okur ve sorgularsanız baya iş görüyor. Ama “AI yapsın, ben başka işle uğraşayım” derseniz, günün sonunda deprecated API’lerle dolu, üstünkörü bir upgrade kalıyor elde. Sonra 6 ay geçiyor, security taramasında tokadı yiyorsunuz.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Upgrade canvas benim gözümde en işe yarar parçalardan biri öldü, çünkü tam da bu steer etme işini kolaylaştırıyor. Görebildiğin şeyi yönetirsin; bu kadar basit. Sohbette kaybolan bir süreci işe yönetmek zor, hatta bazen imkansız gibi geliyor.

Sıkça Sorulan Sorular

GitHub Copilot Upgrade agent’ı ücretsiz mi?

Şöyle ki, Ayrı bir ücret ödemiyorsunuz, mevcut GitHub Copilot lisansınız (Business, Enterprise veya Pro) altında çalışıyor. Ama şunu söyleyeyim — agent uzun süreli koştuğunda premium request kotanızı yiyebiliyor. Yoğun kullanıyorsanız plan yükseltmesi gerekebilir, bunu göz önünde bulundurun.

.NET Framework 4.x uygulamalarını.NET 9’a taşıyabilir mi?

Evet, agent bu senaryoyu destekliyor. Ancak WPF/WinForms gibi desktop uygulamalarında server-side projelere kıyasla biraz daha ham kalıyor. ASP.NET WebForms gibi tamamen kaldırılan teknolojilerde işe migration değil, rewrite yapmanız gerekiyor — aslında bunu agent’ın kendisi de söylüyor.

Upgrade canvas ile Visual Studio’daki Modernize özelliği aynı mı?

Temelde aynı agent’ı kullanıyorlar, ama deneyim oldukça farklı. Canvas, GitHub Copilot bir düşüneyim… uygulamasında interaktif ve çok görünümlü bir his veriyor. Visual Studio içindeki Modernize işe daha entegre ama görünüm olarak daha kısıtlı kalıyor (şaşırtıcı ama gerçek). Tecrübeme göre uzun soluklu projeler için canvas çok daha rahat, kısa upgrade işleri için VS içi seçenek yeterli.

Peki neden?

Agent’ın yaptığı değişiklikleri nasıl geri alırım?

Şahsen, Her task’in ayrı bir commit veya PR olarak açılmasını sağlayın. Böylece hatalı bir değişikliği revert etmek çok kolay oluyor. Bir de şunu ekleyeyim: (belki yanılıyorum ama) upgrade’e her zaman ayrı bir branch’te başlayın, asla main üzerinde direkt çalıştırmayın. Bu ne anlama geliyor? Açıkçası agent commit stratejisini kendisi belirlemiyor, o disiplini sız kuracaksınız.

Türkçe prompt’larla çalışıyor mu?

Teknik olarak evet, agent Türkçe prompt anlıyor (ben de ilk duyduğumda şaşırmıştım). Ama assessment ve plan bir düşüneyim… çıktıları genellikle İngilizce üretiliyor, yanı biraz karma bir deneyim çıkıyor ortaya. Peki bunu neden söylüyorum? Ekip içinde İngilizce rahat okunabiliyorsa sorun yok, aksi hâlde bence promptları da İngilizce vermek çok daha tutarlı sonuç veriyor.

Kaynaklar ve İleri Okuma

Modernize.NET applications in the GitHub Copilot app (Microsoft.NET Blog)

.NET Porting and Upgrade Guide (Microsoft Learn)

Peki, garip gelecek ama, GitHub Copilot Resmî Sayfası

.NET Developer Blog

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Claude Microsoft Foundry'de GA: Azure Faturasında Tek Satır4 Tem 2026

Veritabanı Federasyonu: Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek26 Mar 2026

azure-functions-skills: Azure Functions İçin Yapay Zekâ Çalışma Alanı3 Haz 2026

.NET MAUI Geliştirme Sürecinde Yapay Zekâ Ajanlarıyla Hız Artışı: Gerçekten Fark Yaratıyor mu?20 Mar 2026