オリジナルソース: .NET 8 and .NET 9 will reach End of Support on November 10, 2026
このアナウンスメントは明確であり、チームは同様の明確さで応答すべきである: 2026年11月10日以降も .NET 8 または .NET 9 で出荷し続ける計画なら、あなたは意図的にサポート対象外のランタイム決定をしていることになる。
アプリケーションは動作し続ける。それが問題ではない。問題はセキュリティとサービス更新が停止することである。それが発生すると、バックポートパスのない既知の脆弱性はすべて、あなたの運用上の責任になる。
私の意見を明確に述べる:組織はフレームワークのアップグレードをオプションのメンテナンスとして扱い、その後、緊急ウィンドウ、監査結果、慌てたベンダーエスカレーションでその代償を払うことが多い。アップグレード計画はプロダクトロードマップの項目であるべきであり、サイドクエストではない。
.NET チームのための実践的な移行スタンス:
- .NET 10 へのリターゲットを日付付きの目標として設定し、無期限のバックログ項目としては扱わない。
- 互換性とリグレッションテストを、Q4 ではなく、今、機能作業と並行して実行する。
- 依存関係とホスティングの準備状況を別のワークストリームとして追跡する。なぜなら、多くの障害はプロジェクトファイルの外部で発生するからである。
- Upgrade Assistant と破壊的変更ドキュメントを早期に使用し、驚きを前倒しする。
複数の製品で使用される共有ライブラリを所有している場合は、.NET 10 サポートタイムラインを組織内で公に公開する。下流チームにはリードタイムが必要である。
Visual Studio のサポート対象外コンポーネントマーキングも運用上重要である。それは、ツールチェーンのクリーンアップがコンプライアンス維持の一部であることの明確なシグナルを生み出す。これを無視するチームは、通常、混在 SDK 状態と一貫性のないビルド動作に漂流する。
あまり議論されていない詳細のひとつは、.NET 8 と .NET 9 が同じ終了日に収束することである。これは、より多くのクッションを期待して段階的採用を行った組織のアップグレードウィンドウを圧縮する。機能アクセスのために .NET 9 に移行した場合でも、同じサポートの崖に着地する。
プラットフォームリーダーにとって、判断マトリックスは単純である:期限前に移行するか、補完的制御を伴うサポート対象外リスクを文書化して受け入れるかである。 何も変わらないという第三の選択肢はない。
良いニュースは、.NET 10 が2028年11月までの LTS ターゲットであり、移行を完了すれば安定した滑走路を確保できることである。
最後の Patch Tuesday まで待ち始めてはならない。これをセキュリティ影響を伴うデリバリー期限として扱え。なぜならそれがまさにこれだからである。
