Windows Server 2016からWindows Server 2022への移行は、非クラスター構成ならインプレースアップグレードがMicrosoftの対応経路に含まれます。ただし、対応していることと、その方式が最適であることは別です。短時間で同じサーバーを引き継ぎたい場合は直接アップグレード、ドメインコントローラー、重要なファイルサーバー、業務停止を短くしたい環境、構成を整理したい環境では新規サーバーへのサイドバイサイド移行を優先します。
結論:役割と戻しやすさで方式を選ぶ
一般的なメンバーサーバーで、アプリケーションとドライバーがWindows Server 2022に対応し、検証環境で同じ手順を再現できるなら、インプレースアップグレードは現実的です。一方、Active Directoryドメインサービスを実行するサーバーは、Microsoftの現行手順に従い、新しいサーバーをドメインコントローラーとして追加して役割を移し、旧サーバーを降格する方式を使います。
ファイルサーバーはStorage Migration Serviceを利用すると、移行元の棚卸し、データ転送、名前やネットワーク設定の切り替えを段階的に進められます。単純に「上書きなら速い」と判断せず、障害時に旧環境へ戻せる時間まで含めて比較してください。
移行方式の判断表
- インプレース向き:単一の非クラスターサーバー、役割が単純、停止時間を確保できる、対応済みアプリが中心、同一ハードウェアを継続利用する。
- 新規セットアップ向き:ドメインコントローラー、重要なファイルサーバー、旧ドライバー依存、構成を整理したい、旧環境を並行稼働して切り戻したい。
- 先にベンダー確認が必要:データベース、バックアップ製品、セキュリティ製品、独自フィルタードライバー、業務アプリ、USBライセンス装置がある。
- 別計画にする:フェールオーバークラスター、言語変更、Server Coreとデスクトップエクスペリエンスの切り替え、エディションやライセンス条件が不明。
Microsoftの対応表ではWindows Server 2022以前の非クラスター環境は最大2バージョン先までのインプレースアップグレードが対象で、2016から2022はこの範囲です。ただし、役割、エディション、言語、OEMのハードウェアサポート、アプリの対応条件は個別に満たす必要があります。
事前調査:現在の構成を記録する
移行前に、OSだけでなくサーバーが提供している機能を一覧化します。ホスト名、IP設定、DNS、ドメイン参加、役割と機能、共有、アクセス権、証明書、タスクスケジューラ、サービスアカウント、アプリのバージョン、データ保存先、バックアップジョブ、監視設定を記録してください。次のコマンドは調査結果をテキストとして残す一例です。
New-Item -ItemType Directory C:\MigrationInventory -Force
Get-ComputerInfo | Out-File C:\MigrationInventory\computerinfo.txt
Get-WindowsFeature | Where-Object Installed | Out-File C:\MigrationInventory\features.txt
Get-Service | Sort-Object Name | Out-File C:\MigrationInventory\services.txt
Get-ScheduledTask | Out-File C:\MigrationInventory\tasks.txt
ipconfig /all | Out-File C:\MigrationInventory\ipconfig.txt
Get-SmbShare | Out-File C:\MigrationInventory\shares.txt
出力先はバックアップ対象に含め、管理情報として適切に保護します。共有権限だけでなくNTFSアクセス権も必要です。暗号化証明書、秘密鍵、サービスアカウントの資格情報など、別途エクスポートや管理手続きが必要なものも確認します。
互換性とライセンスを確認する
サーバーメーカーの機種別サポート、BIOS・ファームウェア、ストレージコントローラー、ネットワークアダプターのWindows Server 2022対応を確認します。業務アプリは「起動した実績」ではなく、提供元が明示する対応OS、必要な更新版、データベースとの組み合わせを確認してください。バックアップ製品とEDRもOS更新時に深く関わるため、停止・更新・再有効化の公式手順を用意します。
インプレースでは、インストールメディアの言語を現行OSと合わせ、現在のエディションから引き継げる対象を選ぶ必要があります。評価版から製品版、ライセンスチャネル、仮想化権などは契約によって異なるため、プロダクトキーが入力できることだけで判断しないでください。
バックアップと復元テストを先に完了する
Microsoftのアップグレード手順は、OS、アプリ、データ、仮想マシンを含む完全バックアップを作成するよう求めています。バックアップ成功の表示だけでは不十分です。別環境へ復元し、起動、共有アクセス、アプリ接続、データ整合性を確認して初めて切り戻し手段になります。
- ベアメタル復元またはシステム全体を戻せるバックアップ
- 業務データのアプリ整合性を保ったバックアップ
- 暗号化キー、証明書、構成ファイル、ライセンス情報の保管
- 復元用メディア、ドライバー、バックアップ保管先へアクセスする手段
- 復元にかかる実測時間と、切り戻し判断の締切
仮想マシンのチェックポイントやスナップショットだけを復元策にしないでください。アプリ整合性、外部ストレージ、ドメイン関係、長期保管を保証しないため、製品の正式なバックアップと復元テストが必要です。
インプレースアップグレードの進め方
- 検証環境で本番と同じ役割、アプリ、更新状態を再現して試験する。
- 保留中の再起動、ディスク空き容量、Windows Update、ハードウェアエラーを解消する。
- 完全バックアップを取得し、監視と業務処理を計画停止する。
- Microsoftまたは正規ライセンス経路のWindows Server 2022メディアを、稼働中のWindows Server 2016から開始する。
- 保持する項目、対象エディション、警告を確認し、問題があれば開始せず調査へ戻る。
- アップグレード後に更新を適用し、役割と業務アプリを検証する。
作業中は電源を切らず、リモート接続だけに依存しない管理経路を確保します。ディスク空き容量を増やす目的で、バックアップ未確認のログやシステムファイルを削除しないでください。互換性警告を無視して続行するより、原因を解消して再試行するほうが安全です。
新規サーバーへのサイドバイサイド移行
新しいWindows Server 2022を構築し、更新、時刻同期、監視、バックアップ、セキュリティ設定を先に整えます。その後、アプリや役割ごとの正式な移行手順でデータを複製し、テスト用の名前やIPで利用者確認を行います。本番切り替えでは書き込みを止め、最終差分を同期してから名前、IP、DNS、ロードバランサーなど必要な入口を切り替えます。
この方式の利点は、旧サーバーを変更せずに比較できることです。ただし、同じIPやホスト名を同時に使うと競合します。切り替え手順、DNSの反映時間、アプリ側の接続先、証明書名を事前に設計してください。切り戻す場合は新側への書き込みデータをどう旧側へ反映するかも決めておきます。
役割別の注意点
ドメインコントローラー
新しいWindows Serverを既存ドメインへ追加し、AD DSを構成してレプリケーションとDNSを確認し、必要なFSMO役割を移してから旧ドメインコントローラーを降格します。MicrosoftはAD DSサーバーをインプレースで更新しないよう案内しています。レプリケーションエラーがある状態で移行を進めないでください。
ファイルサーバー
共有名、NTFS権限、ローカルユーザー、ファイル属性、開いているファイル、容量、パス長を調査します。Storage Migration Serviceは、インベントリ、転送、カットオーバーを支援します。移行後は管理者の閲覧だけでなく、代表的な利用者権限で読み書きを確認します。
アプリケーション/データベース
製品ごとのバックアップ、エクスポート、レプリケーション、アップグレード順を使います。サービスフォルダーをそのままコピーして移行できるとは限りません。データベースのバージョン、照合順序、接続文字列、サービスアカウント、ポート、証明書まで検証します。
移行後の検証
OSが起動してログオンできるだけでは完了ではありません。移行前の棚卸しと照合し、イベントログ、デバイス、役割、サービス、共有、タスク、バックアップ、監視、ライセンス認証を確認します。利用者テストは、実際の業務シナリオを使って読み取り、書き込み、印刷、外部連携、夜間処理まで行います。
- OSのエディション、ビルド、更新、ライセンス認証が想定どおり
- 固定IP、DNS、ルーティング、時刻同期が正常
- 重要サービスが実行され、不要な自動停止を繰り返していない
- 共有とアクセス権が利用者単位で正しい
- バックアップジョブを新環境で実行し、復元テストできる
- 監視、通知、脆弱性管理、運用手順が新サーバーを対象にしている
切り戻し計画
インプレースで重大障害が出た場合は、作業前に定めた時刻で復旧作業へ切り替え、テスト済みの完全バックアップからサーバー全体を復元します。アップグレード途中の状態に継ぎ足し修復を続けると、停止時間が読めなくなります。切り戻し後に発生した業務データをどう扱うかも、作業前に責任者と合意します。
サイドバイサイドでは、旧サーバーを再び入口に戻せるよう、廃止やデータ削除を急ぎません。ただし、新サーバーへ切り替えた後に更新されたデータを旧側へ戻せる仕組みがなければ、単にDNSやIPを戻すだけでは整合性を失います。データ同期と業務停止の境界を明記してください。
サポート期限を含めて計画する
Microsoft Lifecycleでは、Windows Server 2016の延長サポート終了日は2027年1月12日、Windows Server 2022はメインストリームサポートが2026年10月13日、延長サポートが2031年10月14日です。2026年時点で新規移行を始める場合、2022が業務アプリや機器の認定対象か、次の更新までの運用期間を満たすかを確認します。対象アプリがより新しいWindows Serverを認定しているなら、その選択肢も同じ基準で比較してください。
よくある質問
2016から2019を経由する必要がありますか?
非クラスターのWindows Server 2016から2022は、Microsoftの対応経路に含まれるため、2019の経由は必須ではありません。ただし、役割やアプリが直接経路を認定しているかは別途確認が必要です。
アップグレード後に元へ戻せますか?
サーバー移行では、画面上の簡単な「元に戻す」機能を前提にしません。完全バックアップからの復元、または旧サーバーへの切り戻しを事前に試験し、必要時間を測っておきます。

コメント