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.
| Senaryo | Ana Risk | Pratik Yaklaşım |
|---|---|---|
| Küçük startup | Sınırlı kaynak, hızlı teslim baskısı | .NET LTS sürüme hızlı geçiş planı + otomatik test + sadeleştirilmiş deployment |
| Orta ölçekli şirket | Bağımlılık kalabalığı ve ekip koordinasyonu | Kademeli migration + modül bazlı geçiş + feature flag kullanımı |
| Enterprise | Uyumluluk, audit ve kesinti riski | Mimarı envanter çıkarma + FinOps değerlendirmesi + pilot ortam + değişiklik yönetimi |
İş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.
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.
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
.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
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.
3 comments