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

先日、台北にあるカルフール（現・万家福）桂林店の「麻膳堂」で、麻辣牛肉麺を食べてきました。これがまあ、かなりスパイシー。普通に食べているだけなのに、呼吸した瞬間にむせるくらいの辛さで、なかなか強烈でした。
ただ、辛いだけではなく、しびれと旨味もしっかりあって、これはちょっと病みつきになります。台湾に行くと、ついついこういう刺激の強いものを食べてしまいます。

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アドレスをそのまま使いたい」

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

例えば、

旧Windows Server 2016
10.0.1.50

を、

新Windows Server 2025
10.0.1.50

へ変更したい場合です。

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

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

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

10.0.1.50

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

場合によっては、

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

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

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

Elastic IPも確認する

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

例えば、

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

などです。

外部サービス側で、

接続元IP：xxx.xxx.xxx.xxxのみ許可

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

サーバー移行時は、

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

ことが重要です。

ハマりポイント3

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

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

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

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

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

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

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

RDPできない。

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

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

ENA
NVMe
AWS PV
EC2Launch

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

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

ハマりポイント4

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

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

これは非常に重要です。

しかし、

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

とは限りません。

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

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

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

つまり、

OSの切り戻し

と、

データの切り戻し

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

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

例えば、

20:00 移行開始
21:00 OSアップグレード完了
21:30 動作確認
22:00 切り戻し判断

というように、

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

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

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

深夜2時になってから、

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

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

ハマりポイント5

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

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

IIS Managerを開いて、

Webサイト
Started

となっている。

そこで、

「移行成功！」

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

実際のWebシステムには、

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

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

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

ログインすると500エラー

とか、

検索ボタンを押すとエラー

ということがあります。

そのため確認項目は、

トップページ表示

だけでは不十分です。

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

ハマりポイント6

SQL Serverが古い

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

例えば、

Windows Server 2016
SQL Server 2014

といった構成です。

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

SQL Server側にも、

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

などの確認が必要です。

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

Provider=SQLOLEDB

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

OS移行をきっかけに、

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

ことをおすすめします。

ハマりポイント7

Security Groupだけ見て安心しない

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

ただしWindows Serverの場合、

AWS Security Group

だけでなく、

Windows Defender Firewall

もあります。

つまり、

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

ということもあります。

逆もあります。

サーバー移行時には、

Security Group
Network ACL
Windows Firewall
ルーティング
VPN

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

ハマりポイント8

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

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

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

AMI取得
↓
OSアップグレード

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

ADの場合は、

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

なども確認します。

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

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

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

ハマりポイント9

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

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

m4 → m7i

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

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

ただし、

OS変更
インスタンスタイプ変更
ドライバー変更
IP変更
アプリ変更

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

例えば、

Windows Server 2025だから動かないのか？

ENAドライバーなのか？

アプリの問題なのか？

インスタンスタイプなのか？

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

できれば、

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

のが移行の基本です。

ハマりポイント10

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

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

そのため、

「RDPが切れた！」

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

EC2では、

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

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

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

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

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

まず以下を確認します。

AWS側

EC2 Instance ID
Instance Type
Availability Zone
VPC
Subnet
ENI
Private IP
Elastic IP
Security Group
IAM Role
EBS
Snapshot
AMI
CloudWatch

Windows側

Windows Server Edition
Windows Update
ディスク容量
NIC
DNS
Windows Firewall
サービス
タスクスケジューラ
共有フォルダ
証明書

アプリケーション

IIS
SQL Server
.NET Framework
Java
PHP
ODBC
バックアップソフト
ウイルス対策ソフト
監視エージェント

ここまで確認すると、

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

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

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

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

そのため、

2016 → 2025

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

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

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

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

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

そのため、

旧EC2
Windows Server 2016

        ↓ データ・設定移行

新EC2
Windows Server 2025

という並行環境を作り、

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

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

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

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

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

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

Windows
AWS
ネットワーク
データベース
Web
認証
バックアップ
セキュリティ

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

特に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のサポート終了に向けて、

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

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