こんにちは、カトーです。

先日、台北にあるカルフール（現・万家福）桂林店の「麻膳堂」で、麻辣牛肉麺を食べてきました。
これがまあ、かなりスパイシー。

普通に食べているだけなのに、呼吸した瞬間にむせるくらいの辛さで、なかなか強烈でした。
ただ、辛いだけではなく、しびれと旨味もしっかりあって、これはちょっと病みつきになります。
台湾に行くと、ついついこういう刺激の強いものを食べてしまいます。

Windows Server 2016の延長サポート終了日は、2027年1月12日

それはそうと。社内SEの方の中には、Windows Server 2016が来年サポート切れになるので、何とか予算をねじ込んだ人や移行は年明けから……なんて方もいるのではないでしょうか。Windows Server 2016の延長サポート終了日は、2027年1月12日です。

「まだ数か月ある」と思うかもしれませんが、実際には、現行環境の調査から、予算確保、移行方式の検討、検証環境の構築、アプリケーションの動作確認、本番切り替え、切り戻し手順の準備まで考えると、意外と時間はありません。特にAWS上のEC2でWindows Server 2016を運用している場合、「AWSだから簡単に入れ替えられるでしょ」と思われがちですが、実際にはそう単純でもありません。またWindows Serverのアップグレードそのものよりも、クラウドの場合、ENIとIPアドレスの確認、ENA/NVMeなどのAWS用ドライバー、インスタンスタイプ、IISやSQL Serverなどのミドルウェア、AMIやEBSを利用した切り戻し、ADやDNS、Security Groupや外部システムとの通信といった、AWSとWindows Serverの境界部分でハマることがあります。

弊社で受けてる案件は概ね７～９月に完了しておりますが、毎年？この時期になると乗っけているいろいろなアプリ都合で、ギリギリに更新・移行する問い合せが増えるので社内SEさん向け備忘録として記事を書いておきますね。

……といってもWindowsServerでなにを動かしているかによりますので、今回は、AWS上のWindows Server 2016を2025へ移行する際に、SEが事前に確認しておきたいポイントを整理してみます。

Windows Server 2016から2025へ直接アップグレードできる

まず最初に確認しておきたいのが、Windows Serverのアップグレードパスです。

Windows Server 2025ではアップグレード可能な世代が拡大されており、Microsoftの現行ドキュメントでは、非クラスター環境の場合、

Windows Server 2016 → Windows Server 2025

の直接インプレースアップグレードがサポートされています。

以前のWindows Serverでは、

2016
↓
2019
↓
2022

といった段階的なアップグレードを意識する場面もありました。

Windows Server 2025については2016から直接移行できるため、作業工程そのものはかなり楽になっています。

ただし、

「アップグレードできる」ことと「その方法が一番安全である」ことは別問題です。

ここが最初のポイントです。

ハマりポイント1

インプレースアップグレードか、新しいEC2を作るか

AWSでは大きく分けて2種類の移行方法があります。

インプレースアップグレード

現在使用しているEC2インスタンス上で、

Windows Server 2016
↓
Windows Server 2025

へOSをアップグレードします。

設定やサーバーロール、データを維持したまま移行できるため、短時間で済む可能性があります。

一方で、既存環境にある

• 古いドライバー
• 不要なサービス
• 古いミドルウェア
• 過去の設定
• セキュリティソフト
• 独自アプリケーション

も一緒に引き継ぐことになります。

新規EC2へ移行

もう一つは、

Windows Server 2025の新しいEC2を作成して、そこへアプリケーションやデータを移す方法です。

いわゆるサイドバイサイド移行です。

時間はかかりますが、

長期間使用してきたWindows Serverほど、新規構築した方がきれいになる

というメリットがあります。

弊社でも、2016以前から何度も設定変更されてきたサーバーについては、無理にインプレースアップグレードするより、新しいEC2を構築した方が結果的に安全と判断することがあります。

ハマりポイント2

「同じIPアドレスにすればいい」が意外に難しい

AWS移行でかなり重要なのがネットワークです。

特に、

「新しいEC2を作ったけれど、今まで使っていたプライベートIPアドレスをそのまま使いたい」

というケースがあります。

例えば、

を、

へ変更したい場合です。

ところがAWSの場合、EC2のネットワークインターフェースは**ENI（Elastic Network Interface）**として管理されています。

IPアドレスは単純にWindows側のNIC設定だけで管理しているわけではありません。

そのため新しいEC2を作ってからWindows側で勝手に、

と設定すればよい、というものではありません。

場合によっては、

旧EC2を停止
↓
ENIを切り離す
↓
新EC2へENIを付け替える

といった設計も検討します。

このあたりはオンプレミスのWindows Server移行と感覚が少し違います。

Elastic IPも確認する

インターネット公開しているサーバーなら、Elastic IPも確認します。

例えば、

• Webサーバー
• VPNサーバー
• 外部API接続
• 他社からIP制限されているサーバー

などです。

外部サービス側で、

と設定されている場合、新しいEC2へ切り替えた際にIPアドレスが変わると通信できなくなります。

サーバー移行時は、

DNSだけではなく「IPアドレスそのものに依存しているもの」を確認する

ことが重要です。

ハマりポイント3

ENA・NVMeなどAWS用ドライバーを忘れる

AWS上のWindows Serverは、単純なWindows Serverではありません。

EC2を正常に動かすために、

• ENAドライバー
• NVMeドライバー
• AWS PVドライバー
• EC2Launch

などAWS固有のコンポーネントが利用されています。

特に怖いのがネットワークドライバーです。

アップグレード後にOSは起動しているのに、

RDPできない。

となったら結構焦ります。

Windowsのアップグレード前に、

などのバージョンを確認しておくことをおすすめします。

NitroベースのEC2を使用している場合は、特にENAとNVMeを確認しておきたいところです。

ハマりポイント4

「AMIを取ったから大丈夫」は半分正解

AWSでWindows Serverを触る前によく行うのがAMI作成です。

これは非常に重要です。

しかし、

AMIを取った＝何があってもすぐ戻せる

とは限りません。

例えばアップグレード後に、

• データベースへ新しいデータが入った
• ユーザーがファイルを更新した
• メールが保存された
• バッチ処理が実行された

という状態で昔のAMIへ戻せば、その間のデータが失われる可能性があります。

つまり、

と、

は別に考える必要があります。

本番では「戻す時間」を決める

例えば、

というように、

何時までに正常性が確認できなかったら戻す

と事前に決めておきます。

これだけでも現場の安心感はかなり違います。

深夜2時になってから、

「これ、戻した方がいいですかね……？」

という相談を始めるのは、あまり良い移行計画とはいえません。

ハマりポイント5

IISは動いた。でもシステムが動かない

Windows Serverをアップグレードしたあと、

IIS Managerを開いて、

となっている。

そこで、

「移行成功！」

と判断するのは危険です。

実際のWebシステムには、

• IIS
• .NET Framework
• ASP.NET
• ODBC
• SQL Server
• Oracle Client
• Java
• PHP
• DLL
• COM
• タスクスケジューラ

などが絡んでいる可能性があります。

例えばWebページそのものは開けても、

とか、

ということがあります。

そのため確認項目は、

だけでは不十分です。

実際の業務フローを確認する必要があります。

ハマりポイント6

SQL Serverが古い

Windows Server 2016を長期間使っている環境では、SQL Serverも古いことがあります。

例えば、

といった構成です。

OSだけ2025にすれば問題解決、とは限りません。

SQL Server側にも、

• Windows Server 2025でサポートされるか
• 互換性レベル
• ODBCドライバー
• Native Client
• TLS
• 接続文字列

などの確認が必要です。

特に昔から使われている業務システムでは、

のような古い接続方式が残っていることもあります。

OS移行をきっかけに、

SQL Serverまで含めてサポート状況を確認する

ことをおすすめします。

ハマりポイント7

Security Groupだけ見て安心しない

AWS環境では、通信制御としてSecurity Groupを確認するのは当然です。

ただしWindows Serverの場合、

だけでなく、

もあります。

つまり、

AWSでは許可されている
↓
Windows側で拒否

ということもあります。

逆もあります。

サーバー移行時には、

をセットで確認する必要があります。

ハマりポイント8

ADサーバーなら話が変わる

対象EC2がActive Directory Domain Servicesのドメインコントローラーの場合は、さらに注意が必要です。

単純なWebサーバーと同じ感覚で、

と進めるのはおすすめしません。

ADの場合は、

• FSMO
• DNS
• SYSVOL
• レプリケーション
• Global Catalog
• 時刻同期
• DHCP
• 証明書サービス

なども確認します。

複数のドメインコントローラーがあるのであれば、

Windows Server 2025の新しいDCを追加
↓
レプリケーション確認
↓
FSMO移行
↓
旧2016 DCを降格

という方法の方が安全なケースもあります。

ハマりポイント9

インスタンスタイプ変更を同時にやりたくなる

せっかくOSを入れ替えるので、

などインスタンスタイプも最新化したくなります。

コストや性能面では合理的です。

ただし、

を全部同時に行うと、障害が発生した際に原因が分からなくなります。

例えば、

と切り分けが難しくなります。

できれば、

一度に変更する要素を減らす

のが移行の基本です。

ハマりポイント10

RDPできなくなったときの手段を用意しておく

アップグレード途中ではRDP接続が切断されます。

そのため、

「RDPが切れた！」

だけで慌てる必要はありません。

EC2では、

• EC2 Status Check
• System Log
• CloudWatch
• Systems Manager
• EC2 Serial Console

など、RDP以外の確認方法も考えておきます。

特にSystems Managerが事前に利用できる状態なら、トラブル時の選択肢が増えます。

移行前に最低限確認しておきたい項目

実際に弊社で作業する場合でも、いきなりアップグレードを開始することはありません。

まず以下を確認します。

AWS側

Windows側

アプリケーション

「このサーバー、思ったより色々動いていた」

ということがよくあります。

個人的には「新しいEC2を作る」方法をまず検討したい

Windows Server 2016から2025への直接インプレースアップグレードは現在サポートされています。

そのため、

をそのまま実行する選択肢は十分あります。

ただし10年近く使ってきたWindows Serverの場合、

• 使っていないサービス
• 古いドライバー
• 古いアプリ
• 過去の設定
• 不明なタスク
• 不明なDLL

などが残っていることもあります。

AWSであれば新しいEC2を比較的簡単に用意できます。

そのため、

という並行環境を作り、

十分に動作確認してから切り替える方法も有力です。

サーバー移行は「OSを上げる作業」ではない

Windows Server 2016のサポート終了が近づいているため、

「とりあえず2025へアップグレードしよう」

という話になりがちです。

しかし実際の移行作業では、

を一つのシステムとして考える必要があります。

特にAWSの場合、

Windows Serverだけを見ていると、ENIやEBS、ENA、Security GroupといったAWS側の仕組みを見落とします。

逆にAWSだけを見ていると、

IISやSQL Server、AD、.NETといったWindows側の依存関係を見落とします。

Windows Server 2016のサポート終了は2027年1月12日です。

まだ時間があるようにも見えますが、本番システムの場合、

調査
↓
移行設計
↓
テスト環境構築
↓
移行テスト
↓
本番作業

まで考えると、それほど余裕があるわけではありません。

特に、

「このサーバーが何をしているのか、実はよく分からない」

というWindows Serverが残っている場合は、OSアップグレードより先に、まず棚卸しから始めることをおすすめします。

システムガーディアンでは、AWS上のWindows Serverを含め、既存環境の調査、移行設計、Windows Server 2025への移行についても対応しています。

Windows Server 2016のサポート終了に向けて、

「まず何を調べればよいか分からない」

という段階からでもお気軽にご相談ください。