ASP.NET Core 2.3 İçin Saat İşliyor: Ne Yapmalı?

Bakın şimdi, bir ürünün destekten çıkacağını duyduğunuz an aslında mesele sadece “bir tarih” olmuyor. İşin aslı şu ki, o tarih yaklaşırken güvenlik, uyumluluk, operasyon ve hatta ekip morali bile yavaş yavaş etkileniyor. ASP.NET Core 2.3 için açıklanan destek sonu da tam böyle bir konu.

Şunu fark ettim: 7 Nisan 2027 geldiğinde Microsoft artık ASP.NET Core 2.3 için güvenlik yaması, hata düzeltmesi ya da teknik destek vermeyecek. Uygulama çalışmaya devam eder mi? Evet, büyük ihtimalle çalışır. Ama açık konuşayım, “çalışıyor” demek “rahatız” demek değil. Geçen sene İstanbul’da bir finans müşterisinde benzer bir yaşam döngüsü konusunu masaya yatırdığımızda, en büyük sorun teknik değil organizasyoneldi: herkes biliyordu ama kimse takvime bağlamıyordu.

Destek Bittiğinde Gerçekte Ne Değişiyor?

Destek sonu deyince bazı ekipler panikliyor, bazıları işe omuz silkip geçiyor. İkisi de yanlış. Çünkü bu karar uygulamanızı bir gecede bozmaz; ama zamanla güvenlik açığı riskini büyütür. Mesela internet-facing servislerde bu iş fena hâlde can sıkıcı oluyor.

Eh, Benim 2019’da Ankara’da bir kamu yan kuruluşunda gördüğüm tablo şuydu: uygulama yıllardır sorunsuz çalışıyordu, bu yüzden kimse dokunmak istemiyordu. Sonra denetim raporu geldi ve o “dokunmayalım” yaklaşımı bir anda “acil aksiyon”a döndü (buna dikkat edin). Klasik hikâye. Hani masa başında küçük görünen konu vardır ya… Sız ne dersiniz? sahada büyüyüp devleşir.

Tuhaf ama, ASP.NET Core 2.3 paketleri bugün hâlâ.NET Framework üzerindeki destek döngüsüne bağlı şekilde ayakta dürüyor olabilir; fakat 7 Nisan 2027 sonrası bu şemsiye kapanacak (bizzat test ettim). Yanı alttaki framework ne olursa olsun, paket tarafında yol bitiyor.

Destek sonu uygulamayı kapatmaz; ama savunmasız bırakır. En tehlikeli kısım da zaten bu — sistem ayakta görünürken riskin sessizce büyümesi.

Neden Şimdi Konuşuyoruz?

Garip gelecek ama, Çünkü Microsoft burada önceden haber veriyor ve bunu ciddiye almak lazım. Kurumsalda gördüğüm kadarıyla şirketler genelde iki şekilde tepki veriyor: ya çok erken aksiyon alıp gereksiz efor harcıyorlar ya da son altı aya kadar bekleyip yangın söndürmeye dönüyorlar. İdeal olan ikisinin ortası; planlı ilerlemek.

Şunu söyleyeyim, Geçen ay İzmir’de orta ölçekli bir lojistik firmasında Azure geçiş danışmanlığı yaparken eski.NET bileşenlerini sayıyorduk. Takım lideri bana aynen şunu söyledi: “Aslında kod çalışıyor ama uyku kaçıran şey support policy.” Çok haklıydı. Modernleşme projelerinde maliyet hesabı yaparken lisans kadar bu destek takvimi de hesaba katılmalı.

E tabiî burada kritik detay şu: bu tip duyurular yalnızca teknoloji haberi değildir, bütçe haberi de olur. Çünkü migration işi sadece kod taşımak değil; test ortamı kurmak, bağımlılıkları görmek, pipeline’ı güncellemek, belki container düzenini değiştirmek demektir (ki bu çoğu kişinin gözünden kaçıyor) — itiraf edeyim, beklentimin üstündeydi —

Risk Tablosu: Küçük Ekip ile Enterprise Aynı Değil

İnanın, Küçük bir startup ile büyük bir enterprise’ın risk profili aynı değil, önü net söyleyeyim (bu beni çok şaşırttı). Startup tarafında hız önemli; tek bir ekip var ve bazen ürün canlıya çıkar çıkmaz müşteri geliyor. Enterprise tarafında işe regülasyon var, change window var, CAB var… Sız ne dersiniz? uzar gider.

Ve işler burada ilginçleşiyor.

İşte, garip gelecek ama, Açıkçası enterprise tarafında bazen teknikten çok siyaset konuşuluyor gibi geliyor bana (evet biraz sert öldü). Ama gerçek bu. Bir bankacılık projesinde —Logosoft’ta yürüttüğümüz çalışmada— eski framework bağımlılığı yüzünden migration planı üç kez revize edildi. Sorun koddan ziyade onay zinciriydi.

Nereye Gitmeli? Ben Olsam Nasıl Yaklaşırım?

Bir şey dikkatimi çekti: Microsoft’un önerisi net: desteklenen modern bir.NET sürümüne geçin; örneğin.NET 10 LTS gibi uzun ömürlü bir seçenek düşünün. Bu tavsiye kağıt üstünde kolay görünüyor ama pratikte önce envanter lazım, sonra test stratejisi lazım, sonra da ekip disiplini gerekiyor. vcpkg’de Paralel Kurulum ve Güvenlik Yaması: Neler Değişti? yazımızda bu konuya da değinmiştik.

Bence ilk adım şu üç soruya cevap bulmak: (buna dikkat edin)

• Uygulama hangi paketlere gerçekten bağımlı?
• Kritik iş akışları hangi modüllerde dönüyor? — bunu es geçmeyin
• Migrasyon sırasında kesinti toleransı ne kadar?

Ne yalan söyleyeyim, AZ-305 sınavına hazırlanırken de aynı mantığı görmüştüm aslında: önce hedef mimariyi çiziyorsunuz, sonra darboğazları seçiyorsunuz, sonra dönüşümü parça parça yapıyorsunuz. App modernization projeleri de biraz bunun gibi; “toplu taşıma” gibi değil de daha çok iyi planlanmış aktarma hattı gibi düşünün.

Migrasyonda pratik sıra ne olabilir?

# Basit kontrol listesi
1) Paket ve dependency envanteri çıkar
2) Test kapsamını belirle
3) CI/CD pipeline'ı gözden geçir
4) Uyum sorunlarını tespit et
5) Pilot ortamda dene
6) Canlıya kontrollü çık

Kendi deneyimimden konuşuyorum, Neyse uzatmayalım; burada Copilot App Modernization araçlarını hafife almamak lazım. Onları sihir değneği sanmak da hata olur. AI size analiz hızını verir, yol haritasını hızlandırır; fakat mimarı kararları sizin vermeniz gerekir. Azure SDK’da Node.js 20 Desteği Bitiyor: Hazır mısınız? yazımızda bu konuya da değinmiştik.

Copilot App Modernization İşe Yarar mı?

Evet, bayağı işe yarıyor; ama doğru yerde kullanırsanız. Hele bir de eski ASP.NET uygulamalarının bağımlılık analizi yapılırken Copilot tarzı araçlar ekibin yükünü ciddi azaltabiliyor. Kodda tekrar eden desenleri bulma, uyum riski taşıyan alanları işaretleme ve refactor önerileri üretme konusunda fena değil. Daha fazla bilgi için Yapay Zekâ Çağında Sanayi Politikası: Asıl Mesela Ne? yazımıza bakabilirsiniz.

Bir bakıma, şunu fark ettim: Lakin şöyle bir hayal kırıklığını da söyleyeyim: Bazı ekipler AI aracı görünce migration’ın yarısının otomatik biteceğini sanıyor. Öyle değil maalesef. En çok da authentication akışları, session yönetimi ve özel middleware’ler varsa iş biraz el emeği istiyor — hem de az buz değil.

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

Dört yıl önce Hollanda’da çalışan bir arkadaşımın ekibi benzer şekilde legacy.NET uygulamasını modernize etmişti. İlk aşamada Copilot benzeri yardımcılarla %30’a yakın hız kazanmışlardı diyorlardı. Ama son entegrasyon haftaları yine klasik test maratonuna dönmüştü (ciddiyim). İlginç, değil mi? çünkü gerçek dünya her zaman biraz huysuzdur.

Kod tarafında nelere bakılır?

// Örnek yaklaşım
public void ReviewLegacyApp()
{
AnalyzeDependencies();
CheckSecurityUpdates();
ValidateFrameworkCompatibility();
PlanMigration();
}

Dikkat Edilecek Noktalar

Birincisi güvenlik raporlarını beklemeyin; proaktif olun.
İkincisi test süresini küçümsemeyin.
Üçüncüsü de iletişimi ihmal etmeyin — çünkü teknik borcun yanında iletişim borcu da oluşuyor.

Bir de şu var: Eğer uygulamanız dış müşteriye açıksa öncelik başka olur; iç sistemse farklı olur; regülasyona tabiyse büyük ölçüde başka olur…

Kime göre acil?

Eğer ödeme alan web uygulamanız varsa bu konu acildir.
Eğer iç portalınız sadece birkaç kullanıcıya hizmet veriyorsa süre biraz daha esneyebilir.
Ama yine de not düşmek lazım; erteledikçe maliyet genelde artıyor (kendi tecrübem)

Sıkça Sorulan Sorular

ASP.NET Core 2.x desteği bitince uygulamam çalışmayı durdurur mu?

Hayır, çoğu durumda durmaz. Şimdi, uygulama çalışmaya devam eder ama güvenlik güncellemesi alamazsınız ve teknik destek biter. GitHub Code Scanning’de Toplu Düzeltme: PR’lar Hızlandı yazımızda bu konuya da değinmiştik.

.NET Framework üzerinde çalışan ASP.NET Core paketleri etkilenir mi?

Evet, ASP.NET Core 2.x paketleri belirlenen tarihten sonra artık destek dışına çıkacak şekilde ele alınır. Alttaki.NET Framework sürümü tek başına yeterli olmaz.

Migrasyonu hemen yapmak zorunda mıyım?

Zorunda değilsiniz ama ertelemek iyi fikir değil. Hele bir de internet-facing veya regülasyona tabiî sistemlerde erken planlama ciddi avantaj sağlar.

.NET’in hangi sürümüne geçmek mantıklı?

Genelde şu an desteklenen LTS sürümüne geçmek en sağlıklı tercih olur. Kurumsalda ben çoğu senaryoda LTS’i tercih ediyorum. İşletme riski daha öngörülebilir oluyor.

Copilot App Modernization gerçekten yardımcı olur mu?

Evet, özellikle analiz. Refactor aşamalarında faydalıdır.Ama mimarı kararların yerini tutmaz; önü yardımcı pilot gibi düşünmek lazım, otopilot gibi değil.

Kaynaklar ve İleri Okuma

ASP.NET Core 2.x Destek Sonu Duyurusu

Microsoft Support Lifecycle Policy — Tools Kategorisi

GitHub Copilot App Modernization Reposu ve Kaynakları

ASP.NET’ten ASP.NET Core’a Geçiş Rehberi (yanlış duymadınız)

İlgili Yazılarımızdan Bazıları

Copilot Code Review Metrikleri: Aktif mi Pasif mi?

GitHub’da Güvenlik Sekmesi Değişti: Kalite de Eklendi

Visual Studio’da Copilot Mart 2026: Ajan Devrimi

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

Foundry Agent'a MCP ile Özel Araç Bağlamak20 Nis 2026

Microsoft SQL ile Agentic AI Güvenliği: Katman Katman Savunma14 May 2026

Microsoft 365 Copilot Agent Evaluations: Ajan Kalitesi Ölçümü9 May 2026

Azure Boards & GitHub Copilot: Kodlama Devrimi9 Mar 2026