SQL Server 2017の延長サポートは、2027年10月12日に終了します。 メインストリームサポートはすでに2022年10月11日に終わっており、現在受け取れるのはセキュリティ更新のみです。期限を過ぎると、それも止まります。

「まだ1年以上ある」と感じるかもしれません。しかし基幹システムのデータベース移行は、現状調査から本番切替まで半年から1年かかるのが普通です。つまり、2027年10月に間に合わせるには、逆算すると2026年度内には動き出す必要があります。

本記事では、SQL Server 2017のサポート期限と終了後のリスクを整理したうえで、移行先の選択肢と、期限から逆算した移行スケジュールの立て方を解説します。

想定読者

本記事は、次のような方を想定しています。

• 社内の業務システムや基幹システムでSQL Server 2017を使っている情報システム部門の方
• 「2027年10月」という期限は聞いたが、いつ・何から着手すべきか決めかねている方
• オンプレミスのDBサーバーをこのままアップグレードするか、クラウドへ移すか迷っている方
• ベンダーから移行提案を受けており、内容と時期の妥当性を自分でも確認したい方

SQL Server 2017のサポート終了日は2027年10月12日

SQL Server 2017のサポートは、2段階で終了します。

• メインストリームサポート：2022年10月11日に終了済み。 新機能の追加や不具合修正は、この時点で止まっています
• 延長サポート：2027年10月12日に終了。 現在提供されているセキュリティ更新プログラムが、この日を最後に止まります

つまりSQL Server 2017は、いま「セキュリティ更新だけを受け取れる猶予期間」にあります。不具合が見つかっても修正は提供されず、残っているのは脆弱性対応だけです。この猶予が切れるのが2027年10月12日です。

バージョン別サポート期限一覧｜2017の次は2019

自社の計画を立てるうえでは、前後のバージョンの期限も併せて把握しておくと判断しやすくなります。

この表から読み取るべき点は2つあります。

1. 2019へ上げても延長サポートは2030年1月までで、メインストリームはすでに終わっている。いま移行するなら実質的に2022が本命になる
2. ひとつ前の2016は2026年7月14日にすべてのサポートが終了した。2016が残っている場合は、2017より対応が先

サポート終了後も使い続けた場合の3つのリスク

2027年10月12日を過ぎてもSQL Server 2017が止まるわけではありません。データベースは翌日も動きます。問題は「動くこと」と「業務基盤として使い続けてよいこと」が別だという点です。

脆弱性が見つかっても修正されない

サポート終了後は、新たな脆弱性が公表されても修正プログラムが提供されません。データベースは顧客情報や取引データを直接保持するため、攻撃者から見れば最も価値の高い標的です。未修正の脆弱性を抱えたDBを社内ネットワークに置き続けること自体が、セキュリティ事故の条件になります。

監査・取引先要件を満たせなくなる

ISMSやPマークの審査、取引先からのセキュリティチェックシートでは、サポート切れソフトウェアの使用有無を問われるのが一般的です。「サポート終了製品を基幹DBに使用している」という回答は、監査指摘や取引条件の見直しに直結します。

障害時に頼る先がなくなる

サポート期間中であれば、再現困難な障害はMicrosoftのサポート窓口へエスカレーションできます。終了後はこの窓口が使えません。基幹DBの障害を自社と保守ベンダーだけで解決しきれるか、という問いに答えられない場合、それ自体が事業リスクです。

移行先の選択肢｜2017からの移行で押さえる3つのポイント

移行先の選択肢は、SQL Server 2016のときと同じく大きく4つです。

それぞれの向き不向きと判断軸（ハードウェア保守期限・DB依存度・他システムのクラウド方針）は、SQL Server 2016の記事で詳しく整理しているので、そちらを参照してください。ここでは2017からの移行に固有のポイントを3つに絞ります。

1. SQL Server 2022へ直接アップグレードできる。 2017からは中間バージョンを挟まずに2022へ上げられるため、二段階アップグレードは不要です
2. 互換性レベル140のまま動かせる。 SQL Server 2022は2017の互換性レベル（140）をサポートしており、アプリケーションを当面改修せずにDBだけ先に上げる段階移行が組みやすいバージョン関係です
3. 2019への移行は選ばない。 前述のとおり2019はメインストリームが終了済みで、移行してもすぐ次の期限（2030年1月）に追われます

なおクラウド移行を選ぶ場合、SQL Serverのライセンスをそのまま持ち込むか、利用料込みで借りるかで総費用が大きく変わります。

どの移行先が自社に合うか、客観的な比較から相談したい方はc3indexへどうぞ。 基幹システムを前提としたDB移行の調査・設計・実施までを一貫して支援しています。

2027年10月12日から逆算する移行スケジュール

本記事の主題です。移行の内容そのものよりも、「いつまでに始めれば間に合うか」を先に確定させてください。期限のある移行プロジェクトで最も多い失敗は、方式選定で迷っているうちに検証期間が削られ、ぶっつけ本番に近い切替を強いられるパターンです。

移行方式別の標準的な所要期間

合計すると短くて5ヶ月、アプリ改修を伴う場合は1年以上です。単純なオンプレアップグレードは短く、PaaS化やアプリ改修を伴うクラウド移行は長くなります。

着手時期の目安｜いつ始めればどの選択肢が残るか

2027年10月12日を締切に置くと、着手時期ごとに選べる手が変わります。

社内の予算サイクルも考慮が必要です。2027年度予算で移行費用を確保する場合、予算要求は2026年秋、つまり今の時期に現状調査を終えている必要があります。 「期限は2027年10月」でも、意思決定の締切はずっと手前にあります。

現状調査でやることのチェックリスト

逆算の起点になる現状調査では、最低限次の項目を押さえてください。ここが曖昧なまま方式選定に進むと、検証段階で手戻りが発生します。

• インスタンスの棚卸し：社内にSQL Server 2017が何台あるか。開発機・検証機・部門サーバーに埋もれているインスタンスまで含めて洗い出す
• エディションとライセンス形態の確認：Standard/Enterpriseの別、コア数、ソフトウェアアシュアランスの有無。移行方式の費用比較に直結する
• 接続元アプリケーションの特定：どの業務システム・帳票・Excelマクロ・連携ジョブがそのDBに接続しているか。切替時の影響範囲そのもの
• 同居コンポーネントの確認：Reporting Services（SSRS）・Integration Services（SSIS）・Analysis Services（SSAS）を使っているか。DB本体より移行の工数が読みにくい部分
• OS・ハードウェアの期限確認：後述のWindows Server 2016問題を含め、DBと同じ時期に期限を迎える要素を並べる

なおSQL Server 2017はLinux対応した最初のバージョンでもあります。Linux上やコンテナで動かしているインスタンスは管理台帳から漏れやすいため、棚卸しの対象に必ず含めてください。

Windows Server 2016が同居しているなら、期限はさらに手前

SQL Server 2017がWindows Server 2016上で動いているケースでは、OS側の延長サポートが2027年1月12日と、DBより9ヶ月早く終了します。この構成では、実質的な締切は2027年1月です。OSとDBの更新を別々に行うと停止調整とテストが二重になるため、まとめて移行する計画を推奨します。

期限に間に合わない場合の延命策（ESU）とその限界

移行が期限に間に合わない場合、ESU（拡張セキュリティ更新プログラム）を購入してセキュリティ更新のみ継続して受け取る手があります。ひとつ前のSQL Server 2016では、終了後最長3年（2029年7月17日まで）のESUが提供されており、2017でも同様の提供が見込まれます。

ただしESUは「時間を買う」手段であって解決策ではありません。

• 対象はセキュリティ更新のみで、不具合修正やサポート窓口は含まれない
• 年単位の購入で、年を追うごとに割高になる料金体系が通例
• ESU期間が切れたときの移行問題は、そのまま残る

ESUを使うのは「移行計画は確定しているが、切替日が期限を数ヶ月超える」ような場合に限定し、無計画な延命の道具にしないことが重要です。ESUの費用構造と購入条件の詳細は、SQL Server 2016の記事で解説しています。

よくある質問

SQL Server 2019や2022のサポート期限はいつですか？

SQL Server 2019の延長サポートは2030年1月8日、SQL Server 2022は2033年1月11日までです。ただし2019はメインストリームサポートがすでに終了しているため、これから移行するなら2022を選ぶのが基本です。

2027年10月12日を過ぎるとSQL Server 2017は使えなくなりますか？

止まりはしません。ライセンス上も使い続けられます。ただしセキュリティ更新が提供されなくなるため、脆弱性が未修正のまま蓄積します。基幹データを預けるDBとしての要件を満たさなくなる、という意味での「使えなくなる」です。

Amazon RDSでSQL Server 2017を使っている場合も対応が必要ですか？

必要です。RDSはインフラの運用をAWSが担いますが、DBエンジンのバージョン期限そのものは変わりません。RDS for SQL Serverでは期限に合わせて旧バージョンの提供が順次終了するため、2022などの上位バージョンへのアップグレード計画を自社で立てる必要があります。

Linux版のSQL Server 2017も期限は同じですか？

同じです。サポートライフサイクルはOSを問わずバージョン単位で設定されており、Linux版・コンテナ版のSQL Server 2017も2027年10月12日で延長サポートが終了します。Windows版だけ対応してLinux版が残る、という漏れが起きやすいので注意してください。

移行にあわせてライセンス費用を見直す方法はありますか？

あります。クラウド移行時に既存ライセンスを持ち込む（BYOL）か、利用料込みのライセンスを使うかで総費用が変わるほか、コア数の見直しやエディションの最適化で削減できるケースが多くあります。移行はライセンス棚卸しの絶好の機会です。

まとめ

• SQL Server 2017の延長サポートは2027年10月12日に終了する。メインストリームは2022年10月に終了済みで、いま受け取れるのはセキュリティ更新のみ
• 終了後のリスクは「脆弱性の未修正」「監査・取引先要件」「障害時の窓口喪失」の3つ
• 移行先はオンプレ2022更新・Azure・AWS・ESU延命の4択。2017からは2022へ直接アップグレードでき、2019は選ばない
• 移行には現状調査から切替まで5ヶ月〜1年以上かかる。全選択肢を残すには2026年内の着手が必要で、2027年度予算で対応するなら予算要求前の現状調査が今の宿題
• Windows Server 2016と同居している場合、実質的な締切はOS側の2027年1月12日

期限から逆算すると、判断を先送りできる時間はあまり残っていません。まず自社のSQL Server 2017が「どこで・何に使われているか」の棚卸しから始めてください。

SQL Server移行のご相談はc3indexへ

c3indexは、基幹システム・業務システムを前提としたデータベース移行の現状調査から、移行方式の比較・設計・実施までを一貫して支援しています。オンプレミスの更改とAWS・Azureへの移行のどちらも扱っているため、特定の移行先ありきではない比較が可能です。

「うちの構成だと、いつまでに何を決めるべきか」という段階のご相談からで構いません。