SQL Server 2016 の延長サポートは、2026年7月14日をもって終了しました。すでに期限は過ぎています。

それでも「動いているから」という理由で、そのまま使い続けている基幹システムは少なくありません。実際、サポート終了は障害を引き起こすものではなく、ある日突然システムが止まるわけでもないため、対応が後回しになりがちです。

しかし、セキュリティ更新プログラムの提供が止まったサーバーで基幹データを扱い続けることは、監査・取引先要件・サイバー保険のいずれの観点からも説明が難しくなります。

本記事では、サポート終了後に取り得る4つの選択肢（ESU購入・オンプレでのアップグレード・Azureへの移行・AWSへの移行）を比較し、自社がどれを選ぶべきかの判断基準を整理します。あわせて、バージョン別のサポート終了日一覧と、移行を進める際の5ステップも解説します。

想定読者

• SQL Server 2016 を使い続けており、対応方針をまだ決めていない情報システム担当者の方
• サポート終了のリスクを経営層や監査部門に説明する必要がある方
• 次に期限を迎える SQL Server 2017 を含め、DBの更新計画を立てたい方
• オンプレミスのDBサーバーをクラウドへ移すべきか判断したい方

SQL Server 2016のサポートは2026年7月14日に終了した

SQL Server は「固定ライフサイクルポリシー」に沿って、リリースからメインストリームサポート5年＋延長サポート5年＝計10年のサポートが提供されます。

SQL Server 2016 の場合、メインストリームサポートは2021年7月13日に、延長サポートは2026年7月14日に終了しました。

サポート終了によって具体的に止まるのは、次のものです。

• セキュリティ更新プログラムの提供（新たな脆弱性が見つかっても修正されない）
• 不具合修正プログラムの提供
• マイクロソフトによる技術サポート

一方で、ライセンスが失効するわけではないため、インストール済みのSQL Server 2016は引き続き起動し、動作します。ここが判断を鈍らせる最大の要因です。「止まらないなら急がなくていい」という認識のまま数年が経過し、いざ移行しようとしたときには当時の担当者が退職していた、というケースを現場でよく見かけます。

動き続けることと、使い続けてよいことは別

サポートが切れたDBを使い続けるリスクは、技術面よりも説明責任の面で先に表面化します。

• 取引先のセキュリティチェックシートで「サポート対象外のソフトウェアを使用していないこと」に該当してしまう
• 情報セキュリティ監査やPマーク・ISMSの更新審査で指摘を受ける
• インシデント発生時、サイバー保険の支払い要件や社内の説明で不利になる
• 新しいOS・ミドルウェア・アプリケーションが SQL Server 2016 を動作保証しなくなる

特に4点目は見落とされがちです。DB本体を変えなくても、周辺のOSやアプリケーション側の都合で移行を迫られることがあります。

SQL Serverバージョン別のサポート終了日一覧

自社の対応を考えるうえでは、2016だけでなく前後のバージョンの期限も把握しておく必要があります。特にSQL Server 2017 は2027年10月12日と、すでに次の期限が視野に入っています。

ここで注意したいのが、2016から2017へのアップグレードは延命策として弱いという点です。2017の延長サポート終了は2027年10月であり、移行にかかる期間を考えると、実質的な猶予はほとんど残っていません。移行先を選ぶなら、2019以降を前提に検討してください。

サポート終了後に取り得る4つの選択肢

サポートが終了した後の対応は、大きく4つに整理できます。

ESUは「時間を買う」手段であって解決策ではない

拡張セキュリティ更新プログラム（ESU）は、サポート終了後も最長3年間、重要なセキュリティ更新のみを受け取れる仕組みです。SQL Server 2016 の場合、2029年7月17日までが対象となります。

ただし、次の点を理解したうえで使う必要があります。

• 提供されるのはセキュリティ更新のみで、不具合修正や新機能は含まれない
• ソフトウェアアシュアランスやサブスクリプション契約が前提となる
• Azure VM（IaaS）上へ移しただけでは無償にならない。無償で提供されるのは、Azure SQL DatabaseやSQL Managed InstanceといったPaaSサービスへ移行した場合
• オンプレミス環境でも、Azure Arc経由でAzureポータルから購入・適用できる

つまりESUは、移行の期日が決まっている組織が、その期日までの安全を確保するために買うものです。「とりあえずESUで延命する」という使い方をすると、毎年の費用を払いながら意思決定が先送りされ、結局は同じ判断を3年後にすることになります。

どの選択肢を選ぶべきか｜3つの判断軸

4択のどれを選ぶかは、次の3つの軸で整理すると決めやすくなります。

ハードウェアの保守期限がいつ切れるか

DBサーバーが載っている物理サーバーの保守期限が2年以内に到来するなら、オンプレミスでのアップグレードは選ぶ意味が薄くなります。ソフトウェアとハードウェアで二重に更新コストがかかるためです。この場合はクラウド移行を軸に検討したほうが、トータルの投資対効果が良くなります。

逆に、直近でサーバーを更改したばかりであれば、SQL Server 2019/2022 へのアップグレードでハードウェアの残存期間を使い切る判断も合理的です。

アプリケーションがDBにどれだけ依存しているか

長年運用してきた基幹システムでは、ストアドプロシージャや旧来の互換性設定、リンクサーバー経由の連携などがDBに深く埋め込まれていることがあります。

依存が浅ければ、PaaS（Azure SQL Database や Amazon RDS）への移行がそのまま運用負荷の削減につながります。一方、依存が深い場合は、まずIaaS（仮想マシン上のSQL Server）へそのまま移すことを先に行い、PaaS化は次のフェーズに切り出すほうが、失敗する確率を下げられます。

他システムのクラウド移行方針と揃っているか

DBだけを単独で移すと、アプリケーションサーバーとの間にネットワーク遅延が生まれ、性能問題を招くことがあります。アプリケーションとDBは同じ場所に置くのが原則です。

すでに他システムをAWSへ移している、あるいはこれから移す計画があるなら、DBの移行先もAWSに揃えるのが自然です。

なおAWSは、Amazon RDS for SQL Server についても SQL Server 2016 から 2017・2019・2022 への上位バージョンへのアップグレードを推奨しています。RDSを利用中の場合も、期限管理は自社で行う必要があります。

サポート終了への対応方針が固まらない、あるいは移行先の比較を客観的に整理したいときは、c3indexにご相談ください。 基幹システムの移行を前提としたDB移行のご支援を行っています。

c3indexに無料で相談する

Windows Server 2016の期限と重なることを見落とさない

実務上もっとも見落とされやすいのが、OS側の期限との重なりです。

SQL Server 2016 は Windows Server 2016 と同世代の製品であり、両者が同じサーバーに同居しているケースが非常に多くあります。そしてWindows Server 2016 の延長サポートは、2027年1月12日に終了します。

つまり、SQL Server 2016 だけを見て「ESUで数年しのぐ」と判断しても、その数か月後にはOSの期限が来るということです。DBだけを更新して、翌年にOSの更新でもう一度同じサーバーを止めることになれば、業務部門への説明も、停止調整も二度手間になります。

対応方針を決めるときは、必ず次の3点をセットで確認してください。

• そのサーバーのOSは何で、サポート終了はいつか
• 物理サーバーまたは仮想基盤の保守期限はいつか
• 同居している他のミドルウェア（IIS、.NET Framework、バックアップソフト等）の対応バージョンはどうか

これらの期限が2年以内に集中しているなら、個別の延命ではなく、まとめて移行するほうが総コストは下がります。 停止調整とテストが一度で済むためです。

なお、同じ「サポート終了への対応」でも、AS/400（IBM i）のようにハードウェアとOSとアプリケーションが一体化した環境では、判断の構造が変わります。該当する場合は次の記事もあわせてご確認ください。

移行を進める5つのステップ

方針が決まったら、次の順序で進めます。特に最初の2ステップを省略すると、移行後の障害対応で工数が跳ね上がります。

1. 棚卸し：対象のSQL Serverインスタンス、データベース、接続しているアプリケーション、バッチ、帳票、BIツールをすべて洗い出す
2. 互換性の確認：非推奨機能や廃止された機能の使用有無を確認する。マイクロソフトが提供するアセスメントツールを使うと、移行の障害になる箇所を事前に把握できる
3. 移行方式の決定：バックアップからのリストア、レプリケーション、DMS（データ移行サービス）などから、許容できる停止時間に応じて選ぶ
4. リハーサル：本番と同等のデータ量で移行を試行し、所要時間と切り戻し手順を確定させる
5. 本番移行と並行稼働：切り替え後の一定期間は旧環境を停止せずに残し、問題が起きた際に戻せる状態を維持する

見落としやすい3つの落とし穴

照合順序（コレーション）の不一致は、移行後に文字列の比較やソート結果が変わる原因になります。既存の照合順序を必ず引き継いでください。

接続文字列の変更漏れも頻出します。アプリケーション本体だけでなく、バッチ、帳票ツール、Excelのクエリ、退職者が作った野良ツールまでが接続先を持っていることがあります。棚卸しの精度がそのまま移行の成否を決めます。

性能特性の変化にも注意が必要です。SQL Server 2019以降ではクエリ実行プランの生成方式が変わっており、これまで問題のなかったクエリが遅くなることがあります。互換性レベルを一旦従来のまま維持し、段階的に引き上げる進め方が安全です。

移行にかかる費用の相場や、移行先ごとのコスト比較については、次の記事で詳しく解説しています。

よくある質問

Q. サポートが終了したSQL Server 2016を使い続けると、法律違反になりますか。

A. サポート終了そのものが法令違反になるわけではありません。ただし、個人情報を扱うシステムでは、安全管理措置を怠っていると判断される可能性があります。取引先のセキュリティ要件やISMS・Pマークの審査で指摘される実務上のリスクのほうが、先に表面化します。

Q. ESUを購入すれば、2029年まで何もしなくてよいですか。

A. 推奨できません。ESUで提供されるのはセキュリティ更新のみで、不具合修正や技術サポートは含まれません。また、2029年7月にはESU自体が終了します。ESUは移行計画とセットで使うものと考えてください。

Q. SQL Server 2016から2017へのアップグレードで問題ありませんか。

A. 延命策としては弱い選択です。SQL Server 2017 の延長サポートは2027年10月12日に終了するため、移行プロジェクトの期間を考えるとすぐに次の更新が必要になります。2019以降を移行先に選ぶことをおすすめします。

Q. オンプレミスのまま使い続けるのと、クラウドに移すのとではどちらが安いですか。

A. サーバーの保守期限、ライセンスの保有形態、必要な可用性のレベルによって変わるため、一律には決まりません。判断のポイントは、ハードウェア更改の時期が近いかどうかです。近いのであれば、ハードウェア投資とソフトウェア更新が重なるため、クラウド移行のほうが有利になりやすい傾向があります。

Q. 移行にはどのくらいの期間が必要ですか。

A. 単一インスタンスで依存関係が少ない場合は数か月、基幹システムに深く組み込まれている場合は要件整理から本番移行まで1年程度を見込むケースもあります。SQL Server 2017 の期限（2027年10月）も踏まえると、着手を先送りする余裕は多くありません。

まとめ

• SQL Server 2016 の延長サポートは2026年7月14日に終了済み。動作はするが、セキュリティ更新は提供されない
• リスクは技術面よりも先に、取引先のセキュリティ要件・監査・保険といった説明責任の面で表面化する
• 対応はESU購入・オンプレアップグレード・Azure移行・AWS移行の4択。ESUは最長2029年7月17日までの時間稼ぎであり、恒久策ではない
• 2017への移行は延命策として弱い（2027年10月に終了）。移行先は2019以降を前提にする
• 判断軸はハードウェアの保守期限・アプリケーションのDB依存度・他システムのクラウド方針の3つ
• 移行は棚卸しと互換性確認から着手する。接続文字列の洗い出し漏れと照合順序の不一致が代表的な失敗要因

サポート終了への対応は、期限が過ぎた今からでも計画的に進められます。重要なのは、「動いているから」で判断を止めないことです。

c3indexでは、基幹システムやデータベースの移行について、現状の棚卸しから移行先の選定、移行後の運用設計までを一貫してご支援しています。SQL Server の更新方針でお悩みでしたら、まずは現状をお聞かせください。

無料相談・お問い合わせはこちら