.NET 8 ve .NET 9 İçin Son Tarih: 10 Kasım 2026

Şöyle başlayayım: Takviminize bir not düşün, hatta mümkünse şimdiden işaretleyin — 10 Kasım 2026 (ben de ilk duyduğumda şaşırmıştım). O gün hem.NET 8’in hem de.NET 9’un desteği aynı anda bitiyor. Evet, ikisi de. Bu tarihten sonra Microsoft tarafında güvenlik yaması da yok, servis güncellemesi de yok, teknik destek de yok — dürüst olayım, biraz hayal kırıklığı —

Bunu yaşayan biri olarak söyleyeyim, Duyuruyu ilk gördüğümde ben de bir duraksadım. Çünkü.NET 8 LTS,.NET 9 işe STS; normalde bu iki hattın ömrü pek çakışmaz, ama Microsoft STS destek süresini 18 aydan 24 aya çekince işler biraz değişmiş oluyor (yanı takvim kendi içinde gayet düzgün ama ilk bakışta insanı şaşırtıyor). İlginç bir tesadüf gibi dürüyor, fakat işin aslı matematik böyle söylüyor.

Kısaca Ne Oluyor?

Lafı dolandırmadan söyleyeyim. Elinizde.NET 8 ya da.NET 9 üzerinde çalışan bir uygulama varsa — Web API olabilir, Blazor olabilir, Worker Service olabilir, hatta canlıda gayet sakın duran bir sistem de olabilir — 10 Kasım 2026’dan sonra bu uygulamalar bir anda bozulup ortadan kaybolmayacak. Tabiî bilgisayar kendi kendine gidip silmiyor bunu. Ama işin asıl tarafı biraz tatsız:

• Yeni çıkan CVE’ler için yama gelmeyecek.
• Runtime tarafında can sıkıcı bir bug’a denk gelirseniz Microsoft’a destek açamayacaksınız.
• Visual Studio 2022’nın gelecek servis güncellemelerinden birinde.NET 8 ve.NET 9 bileşenleri “out of support” diye işaretlenecek.
• Uyumluluk denetimlerinden geçen kurumlarda (PCI-DSS, ISO 27001, KVKK denetimleri) “desteksiz runtime kullanıyorsunuz” bulgusunu yemeye başlayacaksınız.

Yanı teknik olarak çöp değil. Ama iş açısından bakınca, hani şu “idare eder” dediğimiz şey var ya, onun biraz altına düşüyor.

Bir dakika — bununla bitmedi.

Resmî Takvim Tablosu

10 Kasım aynı zamanda Patch Tuesday’e denk geliyor. Evet, bu önemli. O gün Microsoft hayatı bir açık görürse.NET 8 ve.NET 9 için son bir düzeltme daha atabilir; ama bunu garanti gibi okumayın, çünkü öyle bir söz yok. Açık konuşayım, buna yaslanıp plan yapmak pek akıllıca durmuyor.

Hani, Peki neden?

Cevap basit: destek bitince güvenlik hattı da zayıflıyor. Bir yerde production çalışıyor diye rahatlamak kolay, ama ertesi ay çıkan bir açık yüzünden elinizdeki sürümün artık resmî olarak sahiplenilmemesi can sıkabiliyor; hele kurumsal tarafta audit sorusu geldi mi işin rengi hemen değişiyor.

Evet.

STS ve LTS Farkı — Aslında Yeniden Konuşalım

Bu konuyu ekiplere anlatırken en çok karışan yer burası. Kısa cevap: mesele destek süresi, ama işin içine takvim girince olay biraz dağılıyor.

Ne yalan söyleyeyim, LTS (Long Term Support) sürümleri 36 ay destek görüyor. Çift numaralı olanlar:.NET 6,.NET 8,.NET 10. Kurumsal ortamlar için baya iş görüyor. Bir kere kuruyorsunuz, sonra üç yıl boyunca “acaba bir sonraki büyük geçiş ne zaman” diye düşünmeden devam edebiliyorsunuz.

STS (Standard Term Support) işe eskiden 18 aydı, yeni politikayla 24 aya çıkarıldı. Tek numaralı sürümler:.NET 7,.NET 9,.NET 11 (gelecek) (en azından benim deneyimim böyle). Bunlar daha çok “yeni şeyleri erken deneyeyim, biraz da risk alırım” diyenlere hitap ediyor. Hani test etmek isteyenler var ya, tam onlara göre.

Peki Hangisini Seçmeli?

Sahada gördüğüm kadarıyla ekipler burada ikiye ayrılıyor. İlginç olan şu: teknik karar gibi dürüyor ama çoğu zaman organizasyon alışkanlığı belirliyor.

Hani, Startup’lar ve ürün odaklı ekipler genelde STS’e daha sıcak bakıyor. Çünkü yeni Minimal API detayları, performans tarafındaki küçük iyileştirmeler, yeni C# dil sürümleri… bunların çoğu ilk önce STS’te geliyor ve orada biraz pişiyor (evet, doğru duydunuz). Erken kalkan yol alır derler ya, burada o mantık çalışıyor; tabiî bazen sabah erken kalkanın kahvesi de eksik olmuyor.

Büyük kurumsal ekiplerdeyse tablo tersine dönüyor. Bir bankanın core sistemini her 24 ayda bir majör upgrade’e sokmak pek kolay değil — hatta dürüst olayım, çoğu yerde kimse böyle bir ritme gönüllü girmiyor. LTS’te kalıp 36 ay boyunca sadece patch geçmek daha sakın ilerliyor; üstüne bir de.NET 10 gibi bir sürüme geçtiyseniz, yeni özelliklerin önemli kısmını. Cebinize koymuş oluyorsunuz.

Evet.

.NET 10’a Geçiş: Gerçekten Ne Kadar Zor?

Açık konuşayım —.NET 8’den.NET 10’a geçiş, bugüne kadar gördüğüm majör sıçramalar içinde baya idare eder bir yerde dürüyor..NET Core 2.x’ten 3.x’e geçenler ne demek istediğimi anlar; host builder değişti, DI tarafı başka bir havaya girdi, insanın elinde kahveyle ekrana bakıp kaldığı günlerdi. Hatta.NET Framework’ten.NET Core’a geçişi yaşamış biriyseniz… işte orası ayrı bir macera.

Şimdi çoğu projede tablo çok daha sakın:

<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

Bu kadar mı? Keşke hep öyle olsa. Çünkü iyi senaryoda gerçekten tek satırla ilerliyorsunuz. Kötü tarafa da bakalım: NuGet paketleri eski sürümlere çakılı kalabiliyor, üçüncü parti kütüphaneler.NET 10’u daha koklamadıysa beklemek zorunda kalıyorsunuz (evet, can sıkıyor), üstüne bir de ASP.NET Core tarafındaki davranış değişiklikleri her sürümde ufaktan yoklayıp geliyor.

Adım Adım Geçiş Yolu

1. Envanter çıkarın: Önce ortada ne var önü görün. Hangi projede.NET 8, hangisinde.NET 9 çalışıyor, solution’lar nereye dağılmış, CI/CD hangi image’ı çekiyor… Ben genelde önce dotnet --list-runtimes ile başlıyorum, sonra pipeline tarafında hangi container ya da agent kullanılıyor diye bakıyorum; küçük gibi dürüyor ama bazen asıl sorun oradan çıkıyor. — ciddi fark yaratıyor
2. Bağımlılıkları kontrol edin: Kullandığınız NuGet paketlerinin.NET 10 desteği var mı, ona bakın. Hele bir de EF Core, Serilog, MediatR gibi omurga paketlerde sürüm işi can alıcı oluyor; bir tanesi geri kalırsa zincirin geri kalanı da biraz tökezliyor.
3. Test ortamında deneyin: Bir feature branch açın, TargetFramework değerini değiştirin, derleyin ve testleri koşturun. Burada uyarıları hafife almayın; deprecated API’ler çoğu zaman tam da bu aşamada yüzünü gösteriyor ve sonra prod’da küçük sürprizlere dönüşebiliyor.
4. .NET Upgrade Assistant kullanın: Microsoft’un aracı özellikle büyük çözümlerde fena iş görmüyor. Her şeyi sihir gibi çözmüyor tabiî ama yol gösteriyor, nerede elle müdahale etmeniz gerektiğini az çok belli ediyor.
5. Runtime image’larını güncelleyin: Dockerfile içinde mcr.microsoft.com/dotnet/aspnet:8.0 yazıyorsa bunu 10.0‘a çekmeniz gerekiyor. Basit görünüyor ama açık söyleyeyim, sadece bunu unutup pipeline’da patlayan ekip sayısı az değil.
6. Staging’de yük testi yapın: Her sürümde JIT ve GC tarafı biraz farklı nefes alıyor gibi davranabiliyor. Prod’a çıkmadan önce staging ortamında yük altında nasıl tepki verdiğini görün; aksi hâlde canlıda “neden böyle öldü şimdi?” sorusu kapınızı çalabilir. (bence en önemlisi)

“Migration’ı ertelemek en pahalı karardır. Bir sonraki LTS’e atlayacağım derken üç sürüm birden atlamak zorunda kalanları çok gördüm — o zaman gerçekten acı çekiliyor.”

Neyse uzatmayayım, işin özü şu:.NET 10 geçişi korkutucu değil ama “nasıl olsa kolaydır” diye de geçilmez. Küçük bir hazırlık yaparsanız süreç gayet temiz akar. Yapmazsanız… hmm, sonra gece yarısı log kovalamaya başlarsınız.

Evet.

Türkiye’deki Şirketler Açısından Ne Anlama Geliyor?

Hani, Bu kısmı özellikle ayrı tutuyorum, çünkü Türkiye’de.NET tarafı biraz kendi ritminde ilerliyor. Sahada gördüğüm tablo şu: kurumsal ekiplerin epey bir kısmı hâlâ.NET Framework 4.8’de oyalanıyor ya da.NET 6 LTS’ten çıkamamış durumda,.NET 8’e geçmiş olanlar işe açık konuşayım,. Işin nispeten rahat tarafında sayılıyor. Bu konuyla ilgili SharePoint Copilot Apps Geliyor: SPFx’in AI Dönemine Giriş yazımıza da göz atmanızı tavsiye ederim.

Yanı bu duyuru aslında iki farklı grubu vuruyor:

Daha açık söyleyeyim, bunu yaşayan biri olarak söyleyeyim, Birinci grup:.NET 8 veya 9 kullanan, günceli takip eden ekipler. Bunlar için haber fena değil; bir yıl civarı zaman var ve.NET 10’a geçişi makul bir planla halledebilirler. Panik yapmaya gerek yok.

İkinci grup: Hâlâ.NET 6 LTS’te duranlar ya da daha eski sürümlerde kalanlar..NET 6’nın desteği zaten Kasım 2024’te bitti, yanı bu ekipler şimdiden iki adım geriden geliyor ve doğrudan.NET 10’a sıçramak zorunda kalacaklar. İşte hayatı nokta burası.

Bu arada Azure App Service, AKS ve Container Apps tarafında da sinyaller gelmeye başladı. Azure App Service, desteği biten runtime’ları belli bir süre sonra tamamen kaldırıyor. “deploy ediyoruz, canlıda çalışıyor, sorun yok” diye rahat davranmayın (bulut sağlayıcısı bir sabah kalkıp “kardeşim ben bunu artık host etmiyorum” diyebilir), o yüzden runtime takibini hafife almak baya pahalıya patlayabiliyor. Daha fazla bilgi için Gemini 2.5 Pro ve Gemini 3 Flash Copilot’tan Çıkıyor yazımıza bakabilirsiniz.

Maliyet Perspektifi

Bir kurumsal müşteride bunu bir kere hesaplamıştım.NET 6’dan.NET 8’e geçiş, ortalama bir mikroservis mimarisinde (20-30 servis) yaklaşık 2-4 haftalık iş çıkarıyordu, testleri de içine kattığınızda adam-gün olarak bakınca aslında çok büyük bir yatırım değildi. Ama aynı ekip bunu iki yıl erteleyince, iş değişiyor, çünkü bu sefer.NET 6’dan doğrudan.NET 10’a atlamak gerekiyor. E peki, sonuç ne öldü? Aradaki breaking change’lerin hepsini tek seferde toparlamak zorunda kalıyorsunuz.

Yanı işin ekonomik tarafı da var; her LTS geçişini vaktinde yapmak genelde daha az maliyetli oluyor. Bu biraz ev bakımı gibi, küçük tamiratları sürekli ertelerseniz sonunda kapı kolu değil de komple tadilat çıkıyor. Bu konuyla ilgili Git’te NTLM Kapanıyor: Azure DevOps Server İçin Kritik Uyarı yazımıza da göz atmanızı tavsiye ederim.

Evet.

Visual Studio Tarafı

Visual Studio 2022 kullanıyorsanız, ki büyük ihtimalle kullanıyorsunuz, yakın zamanda gelecek bir servis güncellemesiyle.NET 8 ve 9 bileşenleri “out of support” diye işaretlenecek. Kurulu olanlar çalışmaya devam ediyor, burada panik yok; ama VS Installer bir noktada size dönüp “bunları temizleyelim mi?” diye soracak.

Küçük bir not düşeyim. “Remove out of support components” seçeneğine gözünüz kapalı basmayın. Eğer hâlâ eski projelerle uğraşıyorsanız — ben mesela bazı legacy işlerde hâlâ.NET Framework 4.7.2 açıyorum, evet biraz eski okul — o SDK’lar lazım olabilir, yanı silmeden önce projelere bakmakta fayda var. Önce kontrol edin, sonra temizlik yapın. Bu konuyla ilgili Pure Virtual C++ 2026 Konuşmaları Açıklandı: Program Belli yazımıza da göz atmanızı tavsiye ederim.

İşte tam da bu noktada devreye giriyor.

Third-Party Bağımlılıklar: Görünmez Tuzak

Şimdi buraya dikkat. Kendi kodunu.NET 10’a taşımak, açık konuşayım, çoğu zaman sandığın kadar dert değil. Ama uygulama 30-40 tane NuGet paketine yaslanıyorsa, iş biraz kayıyor; hele bunlardan biri hâlâ.NET 8 target’lıysa, runtime uyumluluğu ile bugün çalışır gibi görünür ama yarın başka yerden patlar.

Peki neden? Çünkü dış paketlerde mesele sadece “çalışıyor mu” değil, sürüm ritmi de var, bağımlılık zinciri de var, bazen de paket sahibi iki yıldır dokunmamış oluyor; yanı sen upgrade yapıyorsun ama arkadaki parça kıpırdamıyor.

Mesela şu kategorilerdeki paketlere göz atmak lazım:

• ORM ve veri erişim: EF Core her.NET sürümüyle ana sürüm atıyor. Uyumlu sürüme geçmek gerekiyor, yoksa bir yerde query davranışı değişip kafanı karıştırabiliyor.
• Auth kütüphaneleri: IdentityServer, Duende, Microsoft.Identity.Web — bunlar runtime’la sıkı çalışıyor. Hani küçük bir değişiklik var sanıyorsun, sonra token akışı tarafında garip bir sessizlik başlıyor.
• Serialization: System.Text.Json, Newtonsoft, MessagePack. Performans farkı burada hemen belli oluyor; bazen güzel hızlanıyor, bazen de beklemediğin bir köşe çıkıyor.
• gRPC ve iletişim: Grpc.Net.Client sürüm uyumsuzlukları can sıkıcı olabiliyor. Evet, çalışıyor gibi dürüyor. Sonra bir bakmışsın proto tarafında ince bir kırılma var.

Tuhaf ama, Şirket içi paketleriniz varsa (private NuGet feed’de), onları da tek tek elden geçirmek gerekiyor. Bu kısım biraz sıkıcı, çünkü yalnızca kod güncellemesi olmuyor; ekipler arası haberleşme, paket yayınlama sırası. Iş takibi de devreye giriyor (işin aslı bazen paketten çok insan yönetiyorsun). Erken başlamak lazım.

Eh, Maalesef.

Bence, Neyse uzatmayalım, bu tip bağımlılıkları en sona bırakınca tablo daha da dağılıyor. Önce kritik paketleri çıkarın, sonra hangisi gerçekten güncelleme istiyor görün; bazıları idare eder, bazıları işe direkt yol keser. Sız ne dersiniz?

Ben Ne Yapıyorum Bu Aralar?

Kendi tarafta, özellikle Azure workload’larında, bir süredir şu yolu izliyorum: LTS’ten LTS’e atlıyorum. Yanı.NET 6’dan.NET 8’e, sonra da.NET 10’a gidiyorum. STS sürümlerini (7 ve 9) işe daha çok test ya da POC tarafında kurcalıyorum; prod’a taşımıyorum. Bana bu daha rahat geliyor, ama tabiî sizin ekip başka türlü de ilerleyebilir.

Bir de Azure DevOps pipeline’larında SDK sürümünü sabitlemek var, işte orası küçük gibi durup büyük dert çıkarıyor. global.json ile pin’lediğinizde CI/CD’nın bir sabah durduk yere patlamasını baya azaltıyorsunuz; çünkü hosted agent üstündeki SDK değişince build’in davranışı da kayabiliyor, sonra herkes “dün çalışan şey bugün niye bozuldu?” diye birbirine bakıyor (ciddiyim). Evet, tam o klasik sahne.

Açık konuşayım, Container tarafında da durum çok farklı değil. GitHub Actions üzerinden yayın yaparken — itiraz edebilirsiniz tabi — base image’ları muhtemelen açık tag’lerle çekmek lazım; :latest ile yürüyen bir Dockerfile, özellikle.NET 10 çıktığında, beklemediğiniz bir yere sapabiliyor. Açık konuşayım, çoğu zaman sorun koddan değil, alttaki imajın sessizce değişmesinden çıkıyor. Şey yanı, insan önce kendi uygulamasını suçluyor ama mesele bazen sadece etiket oluyor.

Bir dakika — bununla bitmedi.

Sıkça Sorulan Sorular

.NET 8 uygulamam 10 Kasım 2026’dan sonra çalışmayı durduracak mı?

Hayır, durdurmayacak. Uygulama çalışmaya devam ediyor. Ama şunu bil: Microsoft artık güvenlik yaması yayınlamıyor, yanı yeni bir açık çıktığında kaderinize terk ediliyorsunuz. Bir de denetim süreçlerinde “unsupported runtime” bulgusu alırsınız ki açıkçası o da başlı başına bir baş ağrısı.

.NET 9 neden.NET 8 ile aynı gün destekten çıkıyor?

Aslında biraz hesap işi var burada. Microsoft, STS sürümlerinin destek süresini 18 aydan 24 aya çıkardı..NET 9 Kasım 2024’te yayınlandığı için üstüne 24 ay eklince Kasım 2026 çıkıyor. Bu tarih de tesadüfen.NET 8’in 36 aylık LTS süresinin bitimine denk geliyor. Yanı kötü bir zamanlama, ama kasıtlı değil.

Doğrudan.NET 6’dan.NET 10’a geçebilir mıyım?

Teknik olarak evet. Ama bence gözünüzü korkutmadan söyleyeyim: arada iki majör sürüm atladığınız için breaking change sayısı ciddi oluyor. ASP.NET Core, EF Core ve System.Text.Json tarafında biriken değişiklikleri hepsini birden yönetmeniz gerekiyor. Zorlu bir migration olur. Yapılabilir tabiî, ama test kapsamınız iyi değilse tecrübeme göre sürprizlerle karşılaşırsınız.

Azure App Service üzerinde.NET 8 çalıştırıyorum, ne yapmalıyım?

Şunu fark ettim: Şunu bilmekte fayda var: destek biten runtime’lar Azure App Service’ten bir süre sonra kaldırılıyor. Yanı uygulamanızı.NET 10’a upgrade edip yeniden deploy etmeniz gerekiyor. App Service’in runtime deprecation politikasını hem Azure portalından hem de Microsoft Learn üzerinden takip etmenizi öneririm, hani sürprizle karşılaşmamak için.

Durun, bir saniye.

.NET 10 ne kadar destekleniyor?

.NET 10 bir LTS sürümü. Kasım 2028’e kadar, yanı tam 36 ay destekleniyor. Bugün migration yaparsanız 2028 sonuna kadar rahat ediyorsunuz. Bence bu, geçiş için oldukça makul bir güvence.

Kaynaklar ve İleri Okuma

.NET 8 and.NET 9 will reach End of Support on November 10, 2026 (Orijinal Duyuru)

.NET Support Policy — Resmî Destek Politikası

Upgrade to a New.NET Version — Microsoft Learn

.NET İndirme Sayfası

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 Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım10 May 2026

Azure DevOps Remote MCP Server: Hibrit Takımlarda Yepyeni Bir Dönem18 Mar 2026

PowerShell'de MSI Dönemi Bitiyor: MSIX'e Geçiş Rehberi12 Nis 2026

Copilot CLI'da Auto Model Seçimi: Ne İşe Yarıyor?19 Nis 2026