Pada 10 November 2026, Microsoft berhenti mengirimkan pembaruan keamanan untuk dua versi .NET pada hari yang sama: .NET 8 dan .NET 9. Setelah tanggal itu, celah keamanan apa pun yang ditemukan di platform tidak akan ditambal di kedua versi tersebut. Jika sistem akuntansi, kasir, atau ERP Anda dibangun di atas salah satunya — dan di pasar Saudi banyak yang demikian — Anda punya waktu kurang dari dua bulan untuk memutuskan ke mana Anda akan pindah. Bagi sebagian besar perusahaan, tujuan yang tepat adalah .NET 10, yang didukung hingga 14 November 2028, bukan .NET 11, yang kandidat rilis pertamanya baru keluar dua hari lalu.

Apa yang terjadi pada 8 September

Pada 8 September 2026, Microsoft mengumumkan bahwa .NET 11 telah mencapai Release Candidate 1 dengan lisensi dukungan go-live — artinya Microsoft secara resmi mendukung penggunaannya di lingkungan produksi nyata sebelum rilis final keluar. Pada hari yang sama, pembaruan pemeliharaan rutin dirilis untuk .NET 10, .NET 9, dan .NET 8.

Itulah berita teknisnya. Berita yang penting bagi pemilik bisnis ada di halaman yang sama sekali berbeda: halaman resmi kebijakan dukungan, yang diperbarui pada hari yang sama, yang menyatakan dengan jelas bahwa .NET 8 dan .NET 9 berakhir masa dukungannya pada 10 November 2026. Pengumuman rilis yang mengilap mendapat sorotan; baris yang benar-benar membuat Anda keluar uang tertulis di sebuah tabel yang membosankan.

Mengapa rilis "dukungan jangka panjang" kehabisan dukungan

Microsoft merilis versi utama .NET setiap bulan November. Rilis bernomor genap adalah dukungan jangka panjang dan mendapat tiga tahun patch gratis; rilis bernomor ganjil adalah dukungan standar dan mendapat dua tahun.

.NET 8 dirilis pada 14 November 2023, sehingga tiga tahunnya berakhir pada November 2026. .NET 9 dirilis pada 12 November 2024, sehingga dua tahunnya berakhir kurang lebih pada saat yang sama. Itulah sebabnya keduanya jatuh pada 10 November. Di sinilah tim sering lengah: "dukungan jangka panjang" tidak berarti didukung selamanya. Artinya tiga tahun dihitung sejak hari rilis, dan sebagian besar waktu itu sudah berlalu tanpa ada yang memperhatikan.

Target yang tepat adalah .NET 10, bukan .NET 11

Reaksi spontan terhadap berita seperti ini adalah "kalau begitu kita tingkatkan ke yang terbaru." Bagi sebagian besar sistem bisnis, itu keputusan yang keliru, dan alasannya ada di tabel dukungan yang sama.

.NET 10 dirilis pada 11 November 2025, merupakan rilis dukungan jangka panjang, dan didukung hingga 14 November 2028. Satu kali peningkatan memberi Anda stabilitas sedikit lebih dari dua tahun tanpa perlu membuka berkas ini lagi. .NET 11 adalah rilis bernomor ganjil, sehingga hanya mendapat dua tahun dukungan standar dan akan kehilangan dukungan lebih dulu daripada .NET 10, meskipun lebih baru. Meningkatkan ke versi yang lebih baru tetapi lebih cepat kedaluwarsa bukanlah peningkatan — itu penundaan dengan tagihan tambahan.

Ada pertimbangan kedua. Kandidat rilis .NET 11 itu sendiri hanya didukung hingga 13 Oktober 2026, karena merupakan build transisi yang memang diharapkan Anda tinggalkan — ke kandidat berikutnya, lalu ke rilis November. Siapa pun yang membaca "go-live" sebagai undangan untuk memasang kandidat rilis ke dalam sistem akuntansi lalu membiarkannya di sana justru telah mendaftar ke siklus peningkatan bulanan, bukan lolos darinya.

Aturan praktis bagi perusahaan yang menjalankan perangkat lunak akuntansi atau operasional: selalu targetkan rilis dukungan jangka panjang bernomor genap. Serahkan rilis bernomor ganjil kepada tim produk yang terus-menerus melakukan peningkatan dan ingin mendapatkan fitur lebih awal.

Apa yang sebenarnya dibawa .NET 11

Agar keputusan didasarkan pada pengetahuan dan bukan penghindaran, berikut isi kandidat rilis tersebut. Di C#, versi 15 menstabilkan union type — cara yang lebih jelas untuk menyatakan nilai yang dapat berbentuk lebih dari satu, seperti operasi yang berhasil atau gagal karena alasan tertentu. Di sisi perkakas, perintah pengujian memperbaiki penanganan aplikasi seluler dan menambahkan kontrol di tingkat eksekusi.

Dalam penerbitan kontainer, pembuatan image kini dapat direproduksi dan tidak lagi mengunggah ulang lapisan yang sudah ada, sehingga mempersingkat waktu deployment dan memudahkan audit atas apa yang Anda kirimkan. Dalam manajemen paket, memperbarui paket dengan celah keamanan yang diketahui kini berfungsi bahkan ketika peringatan diperlakukan sebagai error — hambatan lama yang dulu memaksa tim mematikan pemeriksaan keamanan hanya agar build bisa lolos. Di ASP.NET Core, API penyegaran autentikasi SignalR telah difinalkan, dan sirkuit Blazor Server kini memperbarui statusnya setelah penyegaran alih-alih mempertahankan identitas yang usang. Pelaporan crash dalam proses hadir di sistem Unix, yang berarti diagnostik lebih baik ketika server tumbang pada pukul tiga pagi.

Ini adalah perbaikan yang nyata. Namun tidak satu pun yang sebanding dengan risiko menjalankan sistem keuangan di versi yang kedaluwarsa lebih cepat daripada alternatifnya.

Mengapa ini urusan kepatuhan, bukan urusan teknis

Menjalankan platform yang tidak lagi menerima patch keamanan bukanlah soal selera teknis. Undang-Undang Perlindungan Data Pribadi (PDPL) mewajibkan setiap organisasi yang menangani data pelanggan untuk menerapkan langkah perlindungan yang memadai, dan setiap tinjauan keamanan yang serius akan menanyakan versi platform mana yang Anda jalankan dan kapan dukungannya berakhir. "Kami memakai versi yang sudah tidak didukung sejak delapan bulan lalu" bukanlah jawaban yang dapat Anda pertahankan di hadapan auditor, klien korporat yang mengirimkan kuesioner keamanan sebelum menandatangani kontrak, atau perusahaan asuransi siber.

Hal yang sama berlaku untuk sistem faktur elektronik yang terhubung ke platform Fatoora. Sistem yang menandatangani faktur secara digital dan mengirimkannya ke otoritas pemerintah harus berjalan di platform yang masih menerima patch kriptografi. Ini bukan detail internal — ini bagian dari rantai kepercayaan yang menjadi landasan faktur Anda.

Rencana aksi dari sekarang hingga November

  • Minggu ini — ketahui posisi Anda. Mintalah vendor atau tim teknis Anda membuat inventaris versi .NET di balik setiap sistem yang Anda jalankan, termasuk alat internal kecil dan layanan latar belakang yang tidak pernah dipikirkan siapa pun. Di server, dotnet --list-runtimes menampilkannya; di dalam proyek, itu adalah entri target framework di berkas proyek.
  • Minggu depan — lakukan triase. Tandai semua yang berjalan di .NET 8 atau lebih lama dan semua yang berjalan di .NET 9. Apa pun yang sudah di .NET 10 aman hingga 2028. Apa pun yang di .NET 6 atau 7 sudah bertahun-tahun tidak didukung dan memerlukan penanganan mendesak, bukan jadwal.
  • Dalam dua minggu — baca daftar perubahan yang merusak kompatibilitas. Microsoft menerbitkan daftar perubahan yang merusak kompatibilitas untuk setiap rilis. Berpindah dari 8 ke 10 biasanya lancar, tetapi membacanya sebelum mulai menghemat berhari-hari.
  • Dalam sebulan — tingkatkan lingkungan pengujian terlebih dahulu. Ubah target framework, lakukan build, jalankan pengujian, lalu jalankan sistem dengan salinan data nyata sebelum hal lainnya.
  • Sebelum November — lakukan deployment. Sisakan margin keamanan setidaknya dua minggu sebelum 10 November, dan jangan melakukan deployment saat tutup buku akhir bulan atau di puncak musim penjualan.
  • Sekali, untuk seterusnya. Catat 14 November 2028 di kalender perusahaan hari ini dan tetapkan aturan: setiap peningkatan menuju rilis bernomor genap berikutnya. Dengan begitu, urusan ini berubah dari kejutan tahunan menjadi pos anggaran yang sudah diketahui.

Jika sistem berasal dari vendor

Banyak perusahaan tidak memiliki kode sumbernya; mereka membeli sistem jadi dari pemasok. Dalam hal ini, satu-satunya email yang Anda kirim hari ini menanyakan tiga hal: sistem berjalan di versi .NET berapa, kapan Anda akan mengirimkan build di .NET 10, dan apakah peningkatan ini tercakup dalam kontrak dukungan kami atau ditagih terpisah. Cara vendor Anda menjawab memberi tahu Anda lebih banyak tentang produknya daripada presentasi mana pun. Dan vendor yang tidak tahu jawabannya, atau mengulur-ulur waktu, adalah vendor yang sama yang akan Anda telepon pada 11 November.

Sumber

  • Microsoft — Announcing .NET 11 Release Candidate 1, 8 September 2026: devblogs.microsoft.com
  • Microsoft — kebijakan dukungan resmi .NET dan tanggal akhir dukungan: dotnet.microsoft.com
  • Microsoft — Perubahan yang merusak kompatibilitas di .NET 11: learn.microsoft.com
  • Otoritas Data dan Kecerdasan Buatan Saudi (SDAIA) — Undang-Undang Perlindungan Data Pribadi (PDPL): sdaia.gov.sa