ITエンジニア歴20年以上の筆者ですが、サーバ更新は地味に最高級難度のプロジェクトだと思います。
クラウドサービス（PaaSやSaaS）が増えつつありますが、世の中にはまだまだ物理サーバや仮想サーバが沢山あります。
仮想化により、サーバの物理的寿命は無くなりつつありますが、サーバOSにはやはり寿命（サポート期限）があります。
Windows Server 2008も2020年1月にサポートが切れたところなので、苦労してサーバ更新を実施された方も多いのではないでしょうか？
この記事では、サーバ更新で気を付けるべき６つの重要ポイントをご説明します。
今後サーバ更新をする方は、是非とも目を通していただき、サーバ更新プロジェクトを無事に乗り越えていただければ幸いです。
私はサーバ更新を専門的に担当していた時期があり、同時並行で6システム、年間10サーバ以上の移行を担当したことがあります。
かなりの激務でしたが、この中での気づき、失敗事例から得たノウハウが多数あります。
下記には、どれも実際のサーバ更新プロジェクトの中で得た、リアルなノウハウ・失敗事例から抽出したものばかりですので、
必ず皆さんの参考になる情報があると考えます。
サーバ更新プロジェクトはIT界の総合格闘技
サーバ更新プロジェクトは、IT界の総合格闘技と私は呼んでいます。システムの新規開発よりも断然難しいです。
何故かと言うと、サーバ更新では、アプリケーション、ネットワーク、サーバ構築、ユーザ調整、物品調達、セキュリティ、費用配賦、移行設計といった、とても幅広いスキルを要求されます。
これら難しい工程があるにも関わらず、ユーザにとっては何のメリットもないため調整は難しく、
限られた停止時間でかつ、低価格で実現する必要があります。
しかもサーバ更新と言うのは、ハードウェアかOSの期限切れを起因として実施するため、前回実施したのは軽く5年以上前で、前回のノウハウや有識者はいなくなっていることがほとんどです。
この超過酷なミッションをなんとか乗り越えるため、下記の６つのポイントに気を付けて進めてください。
１．ネットワーク
経験上、最も問題が起こりやすいのはネットワーク周りです。
現行システムが機嫌よく動いているのは、ファイアウォールやサーバの通信許可ポートが適切に設定されているためです。
現行システムに必要な穴あけ（許可設定）は全て把握していますか？
モバイルPCや、海外からのシステム利用は考慮されていますか？
連携システムとの通信経路は把握していますか？
インターネットにアクセスできる設定（プロキシ等）は入っていますか？
IPアドレスとか、接続文字列がプログラムに埋め込まれていないか確認しましたか？
メール送信するための、メールゲートウェイの設定は済んでいますか？
DNSは切り替え設定はいつ実施しますか？TTL（Time To Live）の設定は適切ですか？
ネットワーク周りの設定は、申請や反映に時間がかかることが多いですが、リードタイムは考慮されていますか？
２．ジョブ
ジョブもトラブルの代表選手です。
今動いているジョブは、設計書に記載されているジョブがすべてと確信できますか？
なんてこのジョブがこの時間に動いているか理解していますか？（後続のジョブがあったり、他のシステムが出力ファイルを監視していたりしませんか？）
新旧のジョブの繋ぎ替えは考慮できていますか？いつが旧サーバの最終ジョブ実行で、いつから新のジョブに切り替わりますか？
３．ユーザ
ユーザ調整は忘れがち、遅れがちでトラブルになりやすい要素です。
サーバ更新するといったら、あのバグは当然直してくれるんでしょ？と言われたらどうしますか？
サーバ更新時にクラウドにもっていく場合、レスポンスが劣化する可能性を考慮していますか？
システムの作りによっては、オンプレよりレスポンスが著しく劣化する場合があります。その場合のユーザに納得してもらう論理、またはプログラム修正の費用は確保していますか？
共同利用システムの場合、サーバ更新のタイミングで、利用会社が減少することがあります。その場合、新システムの利用料（配賦）は、旧システムより高くなりませんか？高くなる場合、論理的な説明ロジックはありますか？
４．ソフトウェア調達
新サーバでは新しくソフトウェアを購入が必要となる場合があります。
データベース、HULFTやJP1など、新サーバで利用するソフトウェアのライセンスは購入済みですか？
サーバ更新期間中のライセンスは２重で必要になりませんか？
最新バージョンにバージョンアップする場合、スクラッチのシステムはそれでも動作するか確認していますか？
５．環境の変更
サーバだけでなく、環境周りの変更を見落としていませんか？
サーバ更新のタイミングで、利用端末の条件（端末の解像度、OS、ブラウザ）が変わっている場合、アプリケーションの動作確認は不要ですか？
サーバのフォルダをシステムが利用している場合、そのフォルダの権限設定は引き継がれていますか？
６．移行設計
移行設計とリハーサルは十分ですか？
ユーザと調整したシステム停止時間内で、ジョブの切り替え、データ移行、ネットワーク設定変更、疎通確認は全て可能ですか？
リハーサルで発生した問題課題は全て解決できていますか？
移行時に問題が発生した場合、ネットワーク、インフラ、アプリ、ユーザの各担当者の緊急連絡先は明確になっていますか？
切り戻しポイントは設定していますか？本当にそのタイミング、手順で切り戻しができると自信を持って言えますか？
最後に
長くなってしまいましたが、これらがサーバ更新において最も気を付けて欲しいポイントです。
これだけ潜在的にリスクがあるんだということを、ユーザ、関係者の共通認識としていくことも有効なリスクヘッジです。
是非とも参考にしていただき、サーバ更新を無事に乗り切ってください。