SQL Server 2016サポート終了後の対応｜ESUの条件と移行先の選び方を解説

Microsoft SQL Server 2016の延長サポートは、2026年7月14日（米国太平洋時間）に終了しました。以降は深刻な脆弱性が見つかっても、無償のセキュリティ更新プログラムは提供されません。本記事では、Microsoft公式ライフサイクル情報にもとづく事実関係の整理から、SQL Server 2022・2025・Azure SQLという移行先の比較、ESU（延長セキュリティ更新プログラム）の入手条件と2016で変わった課金の扱い、互換性検証を含む移行実務の手順までを解説します。稼働中のデータベースを止めずに、どの順番で何を判断すべきかを整理できる構成です。

まとめ：SQL Server 2016サポート終了後の対応方針と移行判断の軸

結論から示します。SQL Server 2016は2026年7月14日で延長サポートが終わっており、現時点で無償の更新プログラムは一切出ません。恒久対応は新しい環境への移行だけです。ESUは移行完了までの橋渡しにすぎません。

移行先は3系統に整理できます。オンプレミス継続ならSQL Server 2022（延長サポート2033年1月11日まで）またはSQL Server 2025（同2036年1月6日まで）、クラウドへ寄せるならAzure SQL DatabaseかAzure SQL Managed Instance、期限までに移行が間に合わない場合のみESUで最長3年（2029年7月17日まで）の延命です。注意すべきは、SQL Server 2016のESUはAzure VMへ載せ替えるだけでは無償にならない点で、これは2014までとの決定的な違いになります。まだ方針が決まっていない場合も、Data Migration Assistantによる互換性評価だけは先に済ませ、改修規模を数字で把握してから延命か移行かを決める手順を推奨します。

SQL Server 2016延長サポート終了の事実関係と残されたリスクの中身

まず「何が」「いつ」終わったのかを、Microsoft Learnのライフサイクル情報で正確に押さえます。対応の期限感はすべてここから逆算します。

2026年7月14日の延長サポート終了に至るライフサイクルの経過

SQL Server 2016は固定ライフサイクルポリシーの製品で、2016年6月1日の提供開始から約10年で支援が終わる設計でした。機能修正を含むメインストリームサポートは2021年7月13日に終了しており、それ以降の約5年間はセキュリティ更新のみの延長サポート期間でした。その延長サポートが2026年7月14日（米国太平洋時間）に満了しています。

更新プログラムの提供対象は最終サービスパックであるSP3（2021年9月15日提供開始）に限られていました。SP2以前のサポートは2022年10月11日までに終わっているため、SP3未適用のインスタンスは実質的にはもっと前から更新を受け取れていなかったことになります。自社環境の版は SELECT @@VERSION で確認でき、13.xで始まる番号がSQL Server 2016です。

サポート終了後も停止しない稼働と、止まる更新プログラムの線引き

サポート終了でデータベースが止まるわけではありません。ライセンスも失効せず、SQL Server 2016は今日も動き続けます。終わるのは、セキュリティ修正プログラム（GDR）と累積更新（CU）の提供、そしてMicrosoftへの技術問い合わせ窓口です。

この線引きが、判断を誤らせる原因になります。「動いているから問題ない」という状態は、正確には「まだ攻撃されていないだけ」です。SQL Serverはデータベースエンジンとして認証・権限昇格・リモートコード実行に関わる修正を延長サポート期間中も受け取ってきました。その供給が止まった以上、今後発見される脆弱性は原則として修正されないまま残ります。

セキュリティ更新の停止・監査指摘・周辺ドライバー非互換の実害

放置した場合の実害は3系統に分かれます。

• 脆弱性の放置：新規に発見された欠陥への修正が出ないため、社内ネットワークへ侵入された後の横展開でデータベースが標的になります。インターネットに直接公開していなくても、接続元アプリケーションの脆弱性経由で到達される経路は残ります。
• 監査・契約上の指摘：サポート切れソフトウェアの継続利用は、内部統制監査やISMS・PCI DSSなどの審査で指摘対象になります。取引先のセキュリティチェックシートで申告を求められる場面も増えます。
• 周辺部品の非互換：新しいWindows Server、ODBC/OLE DB/JDBCドライバー、監視エージェントなどの動作検証対象からSQL Server 2016が外れていき、データベース本体より先に周辺が更新できなくなります。

3つ目は見落とされがちですが、実務では先に効いてきます。OS側の更新やドライバー刷新のたびに「2016では検証されていない」という条件が積み上がり、塩漬けの範囲がデータベースの外へ広がっていくためです。

移行先の比較：SQL Server 2022・2025とAzure SQLの選択肢

移行先は「オンプレミスで版を上げる」か「Azure SQLへ寄せて版の概念から離れる」かの2方向です。それぞれの支援期限と向き不向きを比較します。

オンプレミス継続で選ぶSQL Server 2022と2025の支援期限比較

オンプレミス継続の場合、選択肢はSQL Server 2022（2022年11月16日提供開始）とSQL Server 2025（2025年11月18日提供開始）です。支援期限はそれぞれ、2022がメインストリーム2028年1月11日・延長2033年1月11日まで、2025がメインストリーム2031年1月6日・延長2036年1月6日までとなっています。

これから移行プロジェクトを起こすなら、本線はSQL Server 2025です。移行完了が2027年ごろになると想定した場合、2022ではメインストリーム残期間が1年を切りますが、2025なら4年近く残ります。移行の作業内容はどちらを選んでもほぼ同じなので、得られる期間が長い方を取るのが原則です。2022を選ぶ条件は、利用中のパッケージ製品やミドルウェアのベンダーが2025対応をまだ表明していない場合に限られます。この場合も、ベンダーの対応予定を確認したうえで決めるのが先です。

Azure SQLへの移行で版更新の負担を手放せる構成と互換性の条件

Azure SQL DatabaseとAzure SQL Managed Instanceは、Microsoftが基盤を常時更新するPaaSのため、製品としてのサポート終了日が設定されていません。今回のような版の期限切れ対応そのものから離れられるのが、オンプレミス更新との最大の違いです。

使い分けの目安は機能面の互換性です。SQL Server Agentのジョブ、複数データベースをまたぐクエリ、リンクサーバーといったインスタンス水準の機能を使っているシステムはManaged Instance、単一データベースで完結しているアプリケーションはAzure SQL Databaseが候補になります。データベース互換性レベルは130（SQL Server 2016相当）の指定を残したまま動かせるため、アプリケーションの挙動を変えずに基盤だけ移す進め方が取れます。一方で、ネットワーク経路の再設計や接続文字列・認証方式の変更は避けられません。オンプレミス継続かクラウドかの判断軸はオンプレミスとクラウドの違いを整理した記事で詳しく扱っています。

支援期限・アプリ改修規模・運用負荷で並べる移行先4案の比較表

4つの移行先とESU延命を、判断に使う3軸で並べます。

アプリ改修規模が「なし」で済むのはESUだけですが、期限が3年で必ず来ます。表の下段を選ぶほど当面の作業は減り、将来へ送る負債は増える構造です。

ESU（延長セキュリティ更新プログラム）の仕様と2016での変更点

ESUはサポート終了後のインスタンスを最長3年守る有償の仕組みです。ただしSQL Server 2016から取得条件が変わっており、旧版での知識のまま計画すると費用見積もりが狂います。

Azure Arc接続とサブスクリプション課金で受け取るESUの仕組み

SQL Server 2016のESUは、対象インスタンスをAzure Arcに接続し、Azureポータルの「SQL Server Configuration」からサブスクリプションを有効化して受け取ります。Arc接続自体は無償で、オンプレミスや他社クラウド上のサーバーも対象にできる仕組みです。契約面では、Enterprise Agreementなどのソフトウェアアシュアランス保有が基本条件ですが、Arc経由の従量課金を選べばソフトウェアアシュアランスなしでも購読できます。

課金は時間単位で、いつでも解約可能です。新しい版への更新やAzureへの移行が完了すると自動で解約される仕組みのため、「移行完了までの月数だけ支払う」使い方に合っています。適用前提として最新のCUを当てておくことが公式に推奨されており、GDRのみで運用してきたインスタンスは、購読時点でCUの検証を先に済ませておくと更新適用時の失敗を避けられます。

Azure VM移行の無償特例がSQL Server 2016では廃止された変更点

SQL Server 2014までは、ワークロードをAzure VMへそのまま移すと、Windows Update経由で無償のESUを受け取れました。この特例がSQL Server 2016では廃止されています。Microsoftのドキュメントにも、2016以降はAzure VM上でもESUが無償にならないことが明記されており、Azure VM上のインスタンスもSQL IaaS Agent拡張機能への登録と有償サブスクリプションが必要です。

実務への影響は費用計画に直結します。「とりあえずAzureのVMに載せ替えれば延命は無料」という2014時代の定石が使えないため、Azure VMへのリフト単体では、オンプレミスでArc接続する場合と比べて延命費用の面での優位がありません。リフトするなら、その先でAzure SQL Managed Instanceなどへ寄せて版の期限自体を消す計画までを一続きで描くのが筋です。

最長3年・2029年7月17日まで・Critical限定という配信の制約

ESUの提供期間は1年単位で最長3年です。Year 1が2026年7月15日から2027年7月13日、Year 2が2028年7月18日まで、Year 3が2029年7月17日までで、それ以降の延長はありません。

配信内容にも制約があります。ESUで提供されるのは、Microsoft Security Response CenterがCriticalと評価した脆弱性への修正のみで、定期的な配信予定はありません。Important以下の脆弱性、新機能、機能面の不具合修正、個別の障害調査は対象外です。サポート窓口も、ESUで配られた更新プログラムの導入・適用に関する問題に限定されます。つまりESUは「通常サポートの続き」ではなく、最低限の防御だけを買う契約です。この性質が、後述する「ESUを選んでよい場面」の判断につながります。

互換性検証から本番切替まで、SQL Server移行実務の手順と期間の見立て

移行プロジェクトの失敗は切替当日ではなく、互換性検証の省略で起きます。手順を工程順に整理します。移行方式の一般論はシステム移行の方式と進め方を整理した記事も参照してください。

Data Migration Assistantでの互換性評価と廃止機能の洗い出し

最初にやるべきは、Microsoftが無償提供するData Migration Assistant（DMA）による評価です。移行先（SQL Server 2022/2025またはAzure SQL）を指定して既存データベースを解析すると、移行を妨げる互換性問題、非推奨機能の使用箇所、動作が変わる箇所が一覧で出ます。この一覧の件数と内容が、改修規模と期間を見積もる根拠になります。

評価で必ず確認したいのは、データベース互換性レベルの扱いです。SQL Server 2022はレベル100〜160をサポートしており、2016相当のレベル130を指定したまま移行できます。移行直後は130のまま動かし、クエリストアで実行計画を比較しながら段階的にレベルを上げる二段構えにすると、性能劣化の切り分けが「基盤の変更」と「互換性レベルの変更」に分離でき、原因調査が速くなります。

バックアップ復元・ログシッピングなど切替方式ごとの停止時間設計

データの移送方式は、許容できる停止時間から逆算して選びます。

• バックアップ復元：完全バックアップを事前に復元しておき、切替時は差分・ログバックアップの適用のみ。仕組みが単純で、停止時間は最終ログの転送・適用時間に収まります。
• ログシッピング：稼働中からログを新環境へ送り続け、切替時に残差を適用。大容量データベースでも切替当日の停止を短くできます。
• トランザクションレプリケーション：切替前に新旧を並行稼働させたい場合の選択肢。構成の手間と制約が多く、要件が合う場合に限って使います。

どの方式でも、切替後に旧環境をすぐ廃棄しないことが戻り道の確保になります。旧インスタンスは読み取り専用で一定期間凍結保持し、切替判定の基準（エラー率・バッチ完走・性能指標）を事前に文書化しておくと、当日の判断が迷いません。

検証・データ移行・並行監視の3工程から逆算する期間と体制の目安

工程は大きく、資産棚卸しと互換性検証、データ移行と回帰テスト、本番切替後の並行監視に分かれます。期間を左右する変数はデータ量よりも接続元アプリケーションの数です。棚卸しでは、インスタンス一覧に加えて、接続してくるアプリケーション・バッチ・帳票・連携ジョブと、それぞれの改修可否・担当者を洗い出します。ここで漏れた接続元が、切替後に障害として現れます。

目安として、接続アプリケーションが単一で改修余地もある構成なら検証込みで数か月、複数の基幹連携が絡む構成では回帰テストが支配的になり年単位の計画になります。すでに延長サポートが終わっている現状では、この見立てを先に持つことが「ESUを何年分購読するか」の判断材料そのものです。だからこそ、方針が未定でもDMA評価だけは今週にでも実行する価値があります。

ESU延命を許容できる条件と、移行に踏み切るべき場面の判断基準

ここまでの事実を踏まえ、延命と移行の線引きを言い切ります。判断を先送りするための材料ではなく、決めるための基準です。

ESU契約が正当化される撤去予定システムと期間限定の橋渡し用途

ESUを選んでよいのは、次のどちらかに当てはまる場合だけです。第一に、システム自体の撤去・統合が確定しており、2029年7月17日のESU満了より前に確実に消える場合。第二に、移行プロジェクトが既に走っていて切替日が決まっており、それまでの期間だけ防御を維持する場合です。

共通点は「終わりの日付が先に決まっている」ことです。時間課金でいつでも解約でき、移行完了で自動解約される仕組みも、この使い方を前提に設計されています。逆に、終了日を決めないままのESU購読は、期限が3年後ろへずれただけで同じ問題が再来します。

長期稼働前提の基幹データベースでESU連続更新を見送るべき理由

今後も長く使う基幹データベースでESUを3年間使い切る選択は、取るべきではありません。理由は3つあります。ESUが守るのはCritical評価の脆弱性だけで、Important以下は修正されないまま残ること。2029年7月17日で必ず終わり、その時点で移行作業は1行も減っていないこと。そして周辺のOS・ドライバー・接続ライブラリの非互換は、ESUでは一切解消されないことです。

延命費用を払い続けても、資産側は古くなり続けます。3年後に行う移行は、今行う移行より検証対象の乖離が広がるぶん高くつきます。長期稼働が前提なら、ESUは「移行プロジェクトの着手が遅れた場合の保険」と位置づけ、主計画は移行に置くべきです。

アプリケーション改修を含む移行を外部委託する場合の要件整理と進め方

データベースの版上げ自体より、接続元アプリケーションの改修と回帰テストが移行の作業量の大半を占めます。社内にSQL Serverの移行経験者がいない場合や、DMA評価で互換性問題が多数出た場合は、評価結果を持って外部の移行支援に相談する方が、自力で試行錯誤するより総コストを抑えられます。

依頼前に整理しておく要件は4点です。インスタンスとデータベースの棚卸し一覧、接続元アプリケーションごとの改修可否と担当、業務上許容できる停止時間、そして目標期限（ESUを使うなら購読終了予定日）。この4点があれば、見積もりの精度が上がり、提案の比較もしやすくなります。一創ではシステムマイグレーション・リプレイスの支援サービスで、現行調査から移行方式の設計、アプリケーション改修、切替までを一括で請け負う体制です。サポート終了済み環境からの脱却を検討している場合の相談先として利用できます。

よくある質問

SQL Server 2016のサポート終了に関して、検討現場でよく出る質問に答えます。

SQL Server 2016はサポート終了後も使い続けられますか？

稼働は継続でき、ライセンスも失効しません。ただし2026年7月14日以降に発見される脆弱性への無償修正は提供されず、時間の経過とともに危険度が上がっていきます。ネットワーク分離や接続元の限定といった緩和策は暫定措置にとどまるため、ESUの購読か移行のどちらかを期限付きで決める必要があります。

ESUの費用はどのくらいかかりますか？

費用はエディション・コア数・購読期間に依存し、Azure Arc経由の従量課金では時間単位で計算されます。金額は契約形態や地域で変わるため、Azureポータルで対象インスタンスをArc接続したうえで見積もるのが確実です。なお課金は解約まで継続する一方、新版への更新やAzure移行が完了すると自動で止まるため、移行計画の完了予定月までの費用として見積もれます。

SQL Server 2017や2019への移行では駄目ですか？

推奨しません。SQL Server 2017の延長サポートは2027年10月12日、2019は2030年1月8日に終わります。移行の作業内容は2022や2025を選んだ場合とほぼ同じなのに、得られる支援期間だけが短くなるためです。特に2017への移行は、完了した直後に次のサポート終了対応が始まる計算になります。オンプレミス継続なら2025、ベンダー対応の制約がある場合のみ2022が妥当です。

Azureに移行すればESUは無償になりますか？

SQL Server 2016では無償になりません。Azure VMへの移行で無償ESUを受け取れる特例はSQL Server 2014までで、2016からは廃止されています。Azure VM上のインスタンスもSQL IaaS Agent拡張機能に登録したうえで有償のサブスクリプションが必要です。延命費用を消したい場合は、VMへのリフトではなくAzure SQL DatabaseやManaged Instanceへの移行まで進める必要があります。

データベース互換性レベル130のまま新しい版へ移行できますか？

できます。SQL Server 2022は互換性レベル100〜160をサポートしており、2016相当のレベル130を指定したままの移行が可能です。Azure SQLでも同様に130の指定を維持できます。移行直後はレベルを据え置いてアプリケーションの挙動を固定し、クエリストアで実行計画を採取してから段階的にレベルを上げると、性能変化の原因を切り分けやすくなります。

関連記事

• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：移行を機にデータベースの種類と選定基準を整理し直したい場合の基礎記事です。
• SQLとは？文の種類（DDL・DML・DCL）と実行順序・RDBMS方言を実装目線で解説：移行時の互換性検証で問題になりやすいRDBMS方言の違いを扱っています。