Windows Server 2016のサポートはいつ終了しますか？

2027年1月12日に延長サポートが終了します。同じ日に.NET Framework 4.6.2、Windows Server 2016上のIIS 10、Hyper-V Server 2016などもサポートを終了し、以降はセキュリティ更新プログラムが提供されなくなります。

.NET Framework 4.6.2で作ったアプリは、新しいWindows Serverでそのまま動きますか？

多くの場合は.NET Framework 4.8系の上でそのまま動作します。4.8系は4.6.2と互換性を保つインプレース更新だからです。ただし、32ビットのCOMコンポーネント、古いデータベースクライアント、サードパーティ製の帳票ツールやActiveXなど、アプリケーションが依存している周辺部品は個別に確認が必要です。止まる原因の多くはフレームワーク本体ではなく、こうした依存部品にあります。

OSの移行とアプリケーションの刷新は、どちらを先に進めるべきですか？

2027年1月までの期間で全面刷新を終えるのは現実的ではないため、多くの場合は期限前にOSを移行するか延長策を確保し、そのうえでアプリケーションの刷新を計画します。ただし、VB6やASP.NET Web Formsなど、将来の移行先が限られる技術で作られたシステムは、OS移行の検証作業とあわせて刷新範囲を見極めておくと、二度手間を避けられます。

Windows Server 2016サポート終了と業務アプリ

Windows Server 2016は、2027年1月12日に延長サポートを終了します。同じ日に、.NET Framework 4.6.2、Windows Server 2016上のIIS 10もサポートを終了します。残りは約3か月です。

サーバOSのサポート終了は、インフラ担当の仕事と見られがちです。しかし実際に移行作業を止めるのは、OSの上で動いている業務アプリケーションであることがほとんどです。新しいOSに載せ替えたら動かなかった、検証に想定以上の時間がかかった、という形で問題が表面化します。

自社のサーバでどの業務アプリケーションがどの部品に依存しているかは、ソースコードを解析すれば短期間で洗い出せます。無料コード診断では、移行時に問題になりうる依存関係と、対応範囲の概算をご提示しています。

2027年1月にサポートを終了する主な製品

製品	サポート終了日
BizTalk Server 2016、Team Foundation Server 2017	2027年1月11日
Windows Server 2016	2027年1月12日
.NET Framework 4.6.2	2027年1月12日
IIS 10（Windows Server 2016上）	2027年1月12日
Hyper-V Server 2016	2027年1月12日
Visual Studio 2017	2027年4月13日
SQL Server 2017	2027年10月12日

出典はMicrosoftのライフサイクル情報です。2016年前後に構築されたシステムでは、OS、開発環境、データベースのサポート終了が1年のうちに重なります。

.NET Framework 4.6.2だけが先に終わる理由

.NET Framework 4.5.2以降は、Windowsの構成要素として扱われ、インストール先のOSと同じサポート期間が適用されます。4.6.2はWindows Server 2016とWindows 10 バージョン1607に対応するバージョンのため、それらと同じ2027年1月12日に終了します。一方、4.7から4.8.1までは、インストール先のWindowsがサポートされている限り引き続きサポートされます。

なお、.NET Frameworkの新しいバージョンは4.8系で止まっており、新機能は後継の.NET（旧 .NET Core）にのみ追加されています。.NET Frameworkで作られたアプリケーションは、OSのサポートに合わせて延命はできても、技術としての発展はありません。

OSを入れ替えれば済むのか

結論から言えば、.NET Framework 4.6.2で作られたアプリケーションの多くは、新しいWindows Serverの.NET Framework 4.8系でそのまま動作します。 4.8系は4.6.2との互換性を保つインプレース更新だからです。

問題になるのは、フレームワーク本体よりも、アプリケーションが依存している周辺部品です。

32ビットのCOMコンポーネントやActiveX：開発元が廃業している、ソースが残っていないものは置き換えが困難です。
古いデータベースクライアントやODBCドライバ：新しいOSでの動作が保証されていないことがあります。
帳票ツールやPDF出力ライブラリ：古いバージョンのライセンスが新しい環境で使えない場合があります。
VB6で作られたクライアントや連携プログラム：ランタイムは新しいWindowsでも動作対象ですが、サードパーティ製のOCXは個別の確認が必要です。
Classic ASPやASP.NET Web Forms：新しいIISでも動作しますが、後継の.NETへの移行先がありません。
暗号化通信の設定：古いTLSに依存した外部連携が、新しいOSの既定設定で接続できなくなることがあります。

どれも、設計書には書かれていないことが多い項目です。構築から10年近くが経過し、当時の担当者が残っていない環境では、実際に新しいOSで動かしてみるまで分からない状態になりがちです。

選択肢の比較

選択肢	期限までの実現性	解決する範囲	次の期限
延長策で現行環境を維持する	高い	当面のセキュリティ更新のみ	延長期間の終了時
新しいWindows Serverへ移行する	中程度（検証次第）	OSのサポート	Windows Server 2022なら2031年10月
アプリケーションを刷新する	期限内は困難	OSとアプリケーションの両方	移行先の技術による

延長策で現行環境を維持する

過去のWindows Server 2012 / 2012 R2では、有償の拡張セキュリティ更新プログラム（ESU）が提供されました。Windows Server 2016についても延長の選択肢が案内されていますが、対象となる契約形態や費用は条件によって異なります。採用する場合は、Microsoftまたは販売代理店から最新の条件を確認してください。

延長策で得られるのは時間です。その期間を次の移行の準備に充てられるかどうかが、分かれ目になります。

新しいWindows Serverへ移行する

もっとも一般的な対応です。上で挙げた依存部品の確認と、業務単位での動作検証が中心になります。

ただし、この移行で解決するのはOSのサポートだけです。VB6やWeb Formsで作られたアプリケーションは、次のOS更新のときにも同じ検証を繰り返すことになります。

アプリケーションを刷新する

業務アプリケーションそのものを、後継の.NETやモダンなWeb構成へ移行する方法です。2027年1月までに完了させるのは現実的ではありませんが、OS移行の検証で依存関係を洗い出すのであれば、その結果を刷新計画の材料にできます。

次のいずれかに当てはまる場合は、刷新を前提に計画を立てる価値があります。

VB6、Classic ASP、ASP.NET Web Formsなど、移行先が限られる技術で作られている
置き換えのきかない古いCOMコンポーネントに依存している
仕様書が現行システムに追いついておらず、コードが唯一の正確な仕様になっている
OSの更新のたびに、同じ検証と回避策を繰り返している

手法ごとの違いは再構築か、自動変換かで、VB6からの移行についてはVB6 からの移行ガイドで詳しく解説しています。

依存関係を把握するところから始める

OSを移行するにしても、アプリケーションを刷新するにしても、最初に必要なのはどのアプリケーションが、どの部品に依存しているかの一覧です。サーバの台数が多い環境ほど、ここを手作業で調べるのには時間がかかります。

日本ビビファイでは、ソースコードの自動解析によるコード分析サービスで、アプリケーションごとの依存部品、使用技術、規模を一覧化します。そのうえで刷新が必要な範囲については、既存のコードから業務ロジックをモデルとして抽出し、新しいアプリケーションを生成するモデル駆動型のコード変換サービスで移行を進めます。移行後は、新旧のシステムが同じ動作をすることを自動テストで検証します。数百万行規模のVB6システムで、解析から移行計画の策定までを2か月で完了した事例を含め、実績は導入事例で紹介しています。

まずは現状の把握から

対象サーバの台数、その上で動く業務アプリケーションの一覧、開発言語とフレームワーク、依存しているCOMコンポーネントや外部ツール。この4点が整理できれば、OS移行で済む範囲と、アプリケーション側の対応が必要な範囲は見えてきます。

期限まで残り3か月の時点で全体像が見えていない場合は、無料コード診断をご利用ください。現行コードを解析し、移行時に問題になる依存関係と対応範囲の概算をご提示します。