SQL Server 2016サポート終了は2026年7月14日｜移行先の選び方・費用・ESUの落とし穴【2026チェックリスト】

結論：危ないのは「SQL Serverを使っている自覚がない」会社。移行はDB入れ替えではなくパッケージ改修の連鎖なので、気づいた時には間に合わない

SQL Server 2016の延長サポートは2026年7月14日に終了する（Microsoft Lifecycleの一次情報で確認。日付は太平洋標準時基準）。この日を過ぎてもデータベースは動き続けるが、新たに見つかった脆弱性へのセキュリティ更新が止まる。攻撃者にとっては「穴が塞がれないサーバ」であり、取引先のセキュリティチェックや監査では「サポート切れの基盤で会計・個人情報を扱っている」と指摘される対象になる。

このEOLが厄介なのは、影響を受ける企業の多くに「SQL Serverを使っている」自覚がないことだ。販売管理・会計・人事給与・生産管理といった業務パッケージは、その裏でSQL Serverを同梱DB／前提DBとして動かしていることが多い。2016〜2020年頃に導入したパッケージなら、2016世代のDBが台帳に載らないまま現役で残っている可能性が高い。そしてこのDBの更改は、単なるバージョン入れ替えでは終わらない。パッケージ側の対応バージョン確認 → パッケージのバージョンアップ（場合により後継製品への乗り換え）→ DB移行 → データ移行 → 業務テストという連鎖になり、ベンダーの作業枠確保まで含めると数か月単位の案件になる。OSのEOLよりも「気づいてから間に合わせる」のが難しい典型だ。

先に要点を3つだけ置く。詳細は本文で一次情報とともに展開する。

1. 選択肢は5つ（新バージョンへアップグレード／Azure SQL Managed Instanceへ移行／Azure VM上のSQL Serverへ移行／ESUで延命／現状維持）。中小企業の現実解は「パッケージが対応するSQL Serverへのアップグレード」か「クラウドへの移行」の二択に集約されやすい。
2. ESUは万能の逃げ道ではない。 よく「Azure VMなら無償で延命できる」と書かれるが、Microsoftの一次情報では無償ESUの対象はSQL Server 2014であって、2016はAzure VM上でもサブスクリプション（有償）が必要であり、しかも2016のESU価格構造は変更されている。ここを誤解すると予算計画が崩れる。
3. 移行の失敗はDBではなくアプリ互換性で起きる。 費用と納期を決めるのはパッケージ側の対応状況であって、DBの容量ではない。見積もりを読むときはこの一点を外してはいけない。

押さえるべき一点：DBのEOL対応は「DB担当」の仕事ではなく「業務パッケージ資産」の仕事である。問うべきは「SQL Server 2016はあるか」ではなく「うちの基幹業務は、何のDBの上で動いているか」だ。

この記事を読むべき人

• 販売管理・会計・生産管理などの業務パッケージを使っているが、その裏のDBが何かを即答できない経営者・情シス
• 社内にDBやインフラの専任がおらず、兼任情シスやベンダー任せでIT資産を管理している中小企業
• パッケージベンダーから「サポート終了なので更改を」と言われたが、その見積もりが妥当か・急ぐべきかを中立に判断したい決裁者
• 取引先や親会社からセキュリティチェックシートの提出を求められ、サポート切れ製品の有無を答える必要がある担当者
• DB更改を機に、塩漬けの販売・会計データをBIやAIで使えるようにしたいと考えている事業責任者

2026年の主要Microsoft製品サポート終了一覧

SQL Server 2016は単独で起きるイベントではない。2026年はMicrosoft製品のEOLが連発する年で、IT資産台帳を総点検すべきタイミングにあたる。Microsoft Learn「2026年のサポート終了」から企業システムに関わりの深いものを抜粋する。

SQL Server 2016のライフサイクルを一次情報から正確に置く。Microsoft Lifecycleの製品ページに記載された日付である。

Microsoftの延長サポートは「セキュリティ更新のみ」を提供するフェーズであり、機能追加やバグ修正はすでに止まっている。つまり2026年7月14日は「サポートが薄くなる」のではなく「セキュリティ更新という最後の一本すら止まる」区切りだ。なお現在サポート対象なのはService Pack 3適用済みの環境で、対象エディションはDeveloper／Enterprise／Enterprise Core／Express／Standard／Webの全てである。無償のExpressも例外ではない。

EOL後に実際に何が起きるのか：セキュリティ・監査・コンプライアンスの3つの実リスク

「動くなら使い続ければいい」という判断が危険な理由を、抽象論ではなく具体で押さえる。

第一に、セキュリティ更新の停止。 SQL Serverはインターネット直結ではないことが多いが、社内ネットワークに侵入した攻撃者にとってDBは最終目標だ。EOL後に発見された権限昇格やリモートコード実行の脆弱性は、原則として修正プログラムが出ない。基幹データ（取引先・受発注・会計・従業員の個人情報）を抱えたDBが、穴が塞がらないまま稼働し続けることになる。

第二に、取引先監査・セキュリティチェックシートでの指摘。 近年、親会社や大口取引先が下請け・仕入先に対してセキュリティチェックシートの提出を求めるケースが増えている。「サポート終了済みのソフトウェアを使用していないか」という設問はほぼ定番で、SQL Server 2016が残っていると「是正計画の提出」を求められる。取引条件に関わることもあり、これは技術問題ではなく商流の問題になる。

第三に、コンプライアンス基準からの逸脱。 クレジットカード情報を扱うならPCI DSS、業種によっては各種のガイドラインが、稼働システムがベンダーサポート対象であることを前提にしている（この点は競合各社も指摘しており、二次情報を含むが方向性は一致している）。サポート切れDBの放置は、こうした基準の要件を満たさなくなるリスクを生む。

要するにEOL後のSQL Server 2016は「動くが守られない・説明できない・監査で落ちる」状態であり、経営リスクとして扱うべき対象だ。判断を先送りするほど、選べる移行方式は減っていく。延命か更改かの判断軸はレガシーシステムの延命 vs リプレース判断フローで8つの評価軸に整理しているので、投資判断の物差しとしてあわせて使ってほしい。

なぜ「基幹パッケージの裏のDB」は放置されるのか

競合記事の多くは「SQL Serverをアップグレードしましょう」で終わるが、中小企業の現実は「そもそもDBの存在に気づけない」ところにある。放置される構造的な理由は3つだ。

第一に、導入時にDBを意識していない。 パッケージベンダーが構築一式を納品するケースでは、DBのバージョンは納品書の片隅にしか残らない。資産台帳に「販売管理システム」とは載っても「SQL Server 2016 Standard」とは載らない。

第二に、更改にアプリの都合が絡む。 DBだけ新バージョンに上げたくても、パッケージ側が新しいSQL Serverに対応していなければ動かない。パッケージの対応バージョン確認から始まり、パッケージ自体のバージョンアップ、DB移行、データ移行、業務テストという連鎖になる。サポート切れの基盤が攻撃対象になり続ける構図は「レガシー放置」の代償を扱った記事でも整理した。

第三に、「動いているから」の慣性。 DBは障害がなければ存在を忘れられる。しかし塩漬けされた販売・会計データは、後述するBI・AI活用の足かせにもなっている。更改を「守りの義務」で終わらせるか、データ基盤整備の起点にできるかで、同じ投資でも回収余地が変わる。

移行先の選択肢：5つの方式を比較する

Microsoftの「サポート終了オプション」（一次情報）は、EOLに達したSQL Serverの選択肢を大きく次のように整理している。中小企業が現実に検討するのは主にこの5つだ。

Microsoftの一次情報では、SQL Serverの新バージョンとして2017／2019／2022／2025が「サポートされるアップグレード」の対象として案内されている。オンプレを続けるなら、パッケージが対応する範囲で最も新しい版を選ぶのが、次のEOLまでの猶予を最大化する定石だ（SQL Server 2022はメインストリーム終了が2028年、延長サポート終了が2033年）。クラウドに寄せるなら、Managed Instanceは「常に最新版・EOLの概念がない」バージョンレス運用が利点で、更改のたびに同じ期限問題を繰り返さずに済む。方式そのものの進め方はレガシー刷新・移行の進め方に体系化しているので、社内で方式を比較する際の下敷きにしてほしい。

ESUの落とし穴：「Azure VMなら無償」は2016には当てはまらない（勝ち筋）

ここが多くの記事が取り違えているポイントだ。二次情報のまとめ記事では「Azure VM上で動かせばESUは無償」と一般化して書かれていることが多いが、Microsoftの一次情報を読むとそれはSQL Server 2014の特典であって、SQL Server 2016には当てはまらない。

Microsoftの「サポート終了オプション」ページには、Azure VMへ移行して現状維持する場合について「SQL Server 2016 (13.x) ではESUをサブスクライブできます。SQL Server 2014 (12.x) の場合は、ESU期間が終了するまでESUを無料で取得できます」と明記されている。さらに同ページには「Azure VMのSQL Server 2016のESUの価格構造が変更された」という注意書きもある。つまり2016については、Azure VMに載せても無償にはならず、価格体系も変わったため、旧来の感覚で見積もると予算が合わない。

ESUのコスト感についても一次情報が触れている。同ページは、ESUの年間コストを**オンプレミスのライセンス費用の約75%**と説明している。3年フルに使えばライセンスをもう一本買うのに近い出費になり、その間もバグ修正や新機能は得られない。ESUは「移行までの時間を買う」ための橋渡しであって、恒久策ではない、と位置づけを固定して考えるべきだ。

この一点だけでも、他社記事を鵜呑みにした計画は崩れる。ESUを織り込んだ延命プランを立てる前に、対象がSQL Server 2016なのか2014なのか、Azure VMか否かで条件がまったく違うことを、一次情報で確認してほしい。

見積もりの読み方：費用を決めるのはDBではなくパッケージだ

競合記事の共通の弱点は「費用の話がない」ことだ。とはいえGXOの案件データを使って相場を断定することはしない（金額は環境依存が大きく、根拠のない数字は誤解を生む）。代わりに、見積もりを受け取ったときに費用の内訳をどう読むかという判断フレームを渡す。SQL Server 2016更改の見積もりは、ざっくり次の要素で構成される。

見積もりを読むときの勘所は、総額の大小ではなく「パッケージ対応費用」の欄が具体的に埋まっているかを見ることだ。ここが「別途見積もり」「要確認」のまま総額だけが出ている見積もりは、後から追加費用が膨らむ典型パターンである。逆に言えば、パッケージベンダーの回答（対応版・費用・納期）を先に書面で取れていれば、複数社の見積もりを同じ土俵で比較できる。ベンダー見積もりが妥当か迷ったら、方式選定の前に移行前の第三者診断で棚卸しと要件整理を先に済ませておくと、比較の物差しがぶれない。

アプリ互換性検証：移行が失敗する本当の場所

DB移行そのものは、ツールもガイドも整っていて、実は難所ではない。Microsoftは移行を助けるツール群（SQL Server Management Studioの移行コンポーネント、Azure Database Migration Service、Data Migration Assistant相当の互換性検出）を提供しており、DBの引っ越しは定型作業に近い。

失敗が起きるのはアプリ側だ。SQL Serverには「データベース互換性レベル（compatibility level）」という概念があり、Microsoftの一次情報は、互換性レベルをレガシと一致させておけば、既存アプリは機能やパフォーマンスの変化から保護されると説明している。逆に言えば、新しい互換性レベルの機能を使おうとした瞬間に、アプリの完全な再認定（全機能の動作確認）が必要になる。ここを軽く見ると、「DBは移ったのに帳票が崩れる」「夜間バッチがこける」といった本番障害を引く。

実務の勘所は次の通りだ。

• まず現行の互換性レベルを確認し、移行後も同じレベルで動かす前提で計画する
• カスタマイズ・アドオン・自社スクリプトを棚卸しし、非推奨機能や廃止機能を使っていないか検出ツールでチェックする
• 帳票、夜間バッチ、他システム連携（在庫・EC・EDI・会計連携など）を「業務が止まると困る順」にテスト項目化する
• 本番切替の前に、必ず移行リハーサルを行い、切替手順とロールバック手順を書面化する

よくある失敗パターン（発注前に知っておく）

GXOが移行・刷新の相談で繰り返し見る、判断ミスの類型を挙げる。自社に当てはまるものがないか点検してほしい。

• DBだけ見て、パッケージを見ない。 「SQL Serverを2022に上げればいい」と考えて発注したら、パッケージが2022非対応で、結局パッケージのバージョンアップ（別費用・別納期）が必要だった。
• ESUを恒久策と誤解する。 「ESUで3年延ばせば安泰」と考えたが、有償で、しかも2016はAzure VMでも無償にならず、3年後にまた同じ問題が来る。時間を買っただけで、判断は先送りされている。
• 切替直前に着手し、ベンダーの枠が取れない。 EOL直前は同じ理由で駆け込む企業が集中し、ベンダーの作業枠が埋まる。「やると決めたのに動けない」状態に陥る。
• 一社の見積もりだけで判断する。 パッケージ提供元の見積もりは、多くの場合「そのパッケージを使い続ける前提」でしか出てこない。後継製品やクラウドERBへの乗り換えを含めた比較ができず、割高な延命を選んでしまう。
• 移行を「守り」で終わらせる。 塩漬けデータの構造を整理しないまま移すと、更改後もExcel転記やデータ分断が残り、BI・AI活用の入り口に立てない。せっかくの投資が「現状維持のためのコスト」で終わる。
• テスト範囲を絞りすぎる。 主要画面だけ確認して切り替えたら、月次・年次の帳票や連携が本番で初めてこけた。頻度の低い処理ほど見落とされる。

ERP・基幹パッケージ連携で特に注意すること

販売・会計・生産管理などが相互に連携している環境では、SQL Server単体の更改が連鎖的に周辺へ波及する。確認すべき論点を整理する。

• 連携方式の依存。 他システムとの連携がDBの直接参照（別システムがSQL Serverを直に読む）で組まれていると、DBを移した瞬間に連携先が動かなくなる。API連携かDB直参照かを把握する。
• 文字コード・照合順序（collation）。 日本語データを扱う基幹系では照合順序の差異が並び順や重複判定に影響する。移行時に維持できるか確認する。
• リンクサーバ・分散トランザクション。 複数DB間の連携をリンクサーバや分散トランザクションで組んでいる場合、クラウド移行で構成が変わる。
• バッチ・ジョブのスケジュール。 SQL Server Agentで組んだ夜間ジョブは、Managed Instanceでは扱いが変わる場合がある（一部機能は代替設計が必要）。
• 基幹刷新のロードマップとの整合。 DB更改だけを単独で回すか、ERP刷新の一部として位置づけるかで最適解は変わる。基幹刷新の期限問題はSAP ECC 2027 EOL問題と同根であり、DB更改を入口に基幹全体の刷新計画へつなげる発想が有効だ。

塩漬けデータを「更改のついでに」整えられるかどうかは、その後のデータ活用余地を大きく左右する。更改後にBIやAIで販売・在庫データを使いたいなら、移行設計の段階からデータ活用基盤構築の観点を混ぜておくと、二度手間を避けられる。

発注前チェックリスト

見積もり依頼や社内稟議の前に、次を埋められるか確認してほしい。埋まらない項目こそ、いま調べるべき論点だ。

• 業務パッケージを部門導入も含めて全て列挙した（販売・会計・人事給与・生産・ワークフロー等）
• 各パッケージのDB種別とバージョンを確認した（SELECT @@VERSION またはベンダー照会）
• SQL Server 2016だけでなく、既にEOLの2014以前が残っていないか確認した
• SP3適用状況を確認した（未適用なら既にサポート外＝緊急度が一段上）
• Express Editionを含む「台帳外」のDBがないか、計測器付属ソフト・部門ツールまで探した
• パッケージベンダーに「対応する新SQL Serverの版・費用・納期」を書面で照会した
• 連携方式（DB直参照かAPIか）と照合順序・カスタマイズを棚卸しした
• 業務が止まると困る順にテスト項目を洗い出した
• 間に合わない場合の暫定策（ESU可否・条件、ネットワーク分離）を検討した
• 延命／更改／刷新の選択肢を、一社の見積もりだけでなく中立に比較する準備をした

チェックの勘所：ベンダーへの照会は口頭でなく書面で行うこと。回答（対応可否・費用・納期）は更改計画の根拠になり、監査対応の際に「確認していた」ことの証跡にもなる。

ベンダーに必ず聞くべき質問

見積もりを取る相手（パッケージ提供元・SIer）には、次を明確に聞いておく。曖昧な回答が返る項目が、後の追加費用とトラブルの火種になる。

1. 「うちのパッケージは、どのバージョンのSQL Serverまで対応しているか。2022/2025で動くか」
2. 「対応にはパッケージ自体のバージョンアップが必要か。その費用と納期は」
3. 「7月14日までに完了しない場合の暫定策として、ESUは使えるか。使える場合、対象・条件・費用は」
4. 「移行後のデータ整合はどう検証するか。リハーサルは何回想定か」
5. 「カスタマイズ・帳票・連携のうち、再検証が必要な範囲はどこか」
6. 「後継製品やクラウド版への乗り換えという選択肢はあるか。その場合の費用感は」
7. 「本番切替でどれだけ業務を止める必要があるか。ロールバック手順はあるか」

1か月でやる棚卸し：5つの手順

残り時間が短くても、着手の順序を間違えなければ現実的に進められる。

1. 業務パッケージの一覧を作る。 部門導入も含めて全パッケージを列挙する。
2. 各パッケージのDB種別とバージョンを確認する。 サーバ上で SELECT @@VERSION を実行するか、ベンダーに照会する。2014以前が残っていないかも見る。
3. SP3適用状況を確認する。 2016でもSP3未適用なら既にサポート外で、緊急度が一段上がる。
4. パッケージベンダーに対応方針を書面で照会する。 対応版・費用・納期・暫定策をセットで確認する。
5. 間に合わない環境の経過措置を決める。 ESUの利用可否・条件を確認しつつ、ネットワーク分離や接続元制限で露出を下げる暫定防御を併用する。

90日で「発注側の物差し」を整えるロードマップ

期限に間に合わないと分かった場合でも、闇雲に製品選定へ走るより、次の90日で発注側の要件を固めた方が失敗コストは小さい。

最初の30日は、現行業務と現行システムの棚卸しに使う。画面・帳票・データ・連携・利用者・例外処理・障害履歴を整理し、どの業務が止まると事業影響が大きいかを確認する。古いシステムほど仕様書より現場の運用が正になっているため、担当者ヒアリングが要る。

31〜60日目は、更改の目的を決める。保守期限への対応だけなのか、業務改善・データ活用・セキュリティ強化まで含めるのかで要件は大きく変わる。ここで目的を広げすぎると失敗するため、必須要件と将来要件を分ける。

61〜90日目は、RFPまたは要件定義書に落とす。機能一覧だけでなく、権限・ログ・監査・非機能・移行・テスト・保守・運用体制を含める。RFPに製品名やベンダー名を先に書くと比較が歪むため、先に書くのは処理量・可用性・権限・監査・移行制約・運用体制だ。

よくある質問（FAQ）

Q. 7月14日を過ぎるとSQL Server 2016は使えなくなるのか？ A. 使えなくなるわけではなく、動き続ける。ただし新たなセキュリティ更新・修正・サポートが提供されなくなるため、以降に発見される脆弱性は塞がれない。基幹データを抱えるDBである以上、「動くが守られない」状態の放置は経営リスクとして扱うべきだ。

Q. ESUで延命できるか。Azure VMに載せれば無償と聞いたが？ A. ESUは最大3年間（〜2029年7月17日）、重要なセキュリティ更新のみを購入できる延命策だ。ただしMicrosoftの一次情報では、Azure VMでの無償ESUはSQL Server 2014が対象で、2016はAzure VM上でもサブスクリプション（有償）が必要であり、価格構造も変更されている。「Azure VMなら無償」は2016には当てはまらないので、条件を一次情報で必ず確認してほしい。ESUは移行までの時間を買う手段であって、恒久策ではない。

Q. 無償のExpress Editionで小さなツールを動かしているだけでも対象か？ A. 対象だ。Microsoftのライフサイクル情報の対象エディションにExpressも明記されている。部門の小規模ツールや計測器付属ソフトの裏で動くExpressは台帳から漏れやすく、むしろ典型的な見落としポイントだ。

Q. どうせ更改するなら何に移行すべきか？ A. パッケージ継続なら、そのパッケージが対応する新しいSQL Server（2019/2022/2025）へのアップグレードが基本線だ。保守負担を減らしたい・EOLの繰り返しを避けたいなら、バージョンレスで運用できるAzure SQL Managed Instanceが有力になる。一方、パッケージ自体が老朽化しているなら、後継製品・クラウドERP・再構築を含めた比較検討の好機だ。

Q. 移行にはどれくらいの期間がかかる？ A. 環境依存が大きいが、二次情報では簡易な構成で2〜3か月、複雑な構成で6〜12か月という目安が示されている。実際の期間はDBの容量ではなく、パッケージ対応・カスタマイズ・連携の多さで決まる。逆算すると、7月14日に間に合わせるのは多くの企業で困難であり、その場合は暫定防御＋計画的移行の二段構えになる。

Q. まず何から手をつければいい？ A. 台帳づくりだ。「うちの基幹の裏で、何のDBが、どのバージョンで動いているか」を洗い出すことが全ての起点になる。ここが埋まらないと、見積もりも比較も始まらない。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、方式を決める前の「棚卸し・整理」の段階で相談してほしい。ここを飛ばして製品選定に入ると、判断ミスが後工程で高くつく。

• 業務パッケージの裏で動くDBのバージョンを把握できておらず、棚卸しから支援がほしい
• パッケージベンダーの見積もりが妥当か、更改か刷新かの判断を中立の立場で比較検討したい
• 7月14日に間に合わない前提で、暫定防御と計画的移行の二段構えを設計したい
• DB更改を機に、塩漬けデータをBI・AIに使えるデータ基盤へ引き上げたい

GXOはレガシーシステム刷新で基幹パッケージ・DBの棚卸しから更改・移行までを伴走し、方式選定に迷う段階ではシステム移行・再構築の相談として特定ベンダーに依存しない立場で比較を支援する。方式を決める前に現状と要件を整理したい場合は、移行前の第三者診断で棚卸しと要件シート化から着手できる。7月14日まで時間は限られている。まずは台帳づくりから始めてほしい。→ DB更改・基幹刷新の相談はこちら

関連記事

• SAP ECC 2027 EOL問題｜S/4HANA移行の費用とタイムライン
• Windows 10サポート終了まで半年｜企業が今やるべき移行チェックリスト
• Amazon Linux 2サポート終了は2026年6月30日｜放置EC2の確認手順
• レガシーシステムの延命 vs リプレース判断フロー｜投資判断8軸

参考資料（一次情報）

• Microsoft Learn「SQL Server 2016 - Microsoft Lifecycle」（延長サポート終了2026年7月14日、ESU 1〜3年目、SP3・対象エディション）
• Microsoft Learn「サポート終了オプション - SQL Server」（移行の選択肢、ESUの条件・価格、2016はAzure VMでも要サブスク、互換性証明）
• Microsoft Learn「2026年のサポート終了 - Microsoft Lifecycle」（7月14日のSQL Server 2016ほか同時終了製品）
• Microsoft「SQL Server および Windows Server の拡張セキュリティ更新プログラム」（ESUの概要）

本記事は2026年7月時点の公開情報をもとに作成。サポート期限はMicrosoftのライフサイクルポリシー上の日付（太平洋時間基準）であり、ESUの提供条件・価格は契約形態によって異なる。移行期間の目安は二次情報を含む。対応判断の前に、Microsoft Learnの一次情報の最新版と自社環境の対象有無を必ず突き合わせること。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報にもとづいて行う。