※このサイトはTOKAIコミュニケーションズをスポンサーとして、Zenken株式会社が運営しています。
オンプレミスサーバーをAWSへ移行する際、まず必要になるのが既存環境の現状把握です。特に、長年運用されてきたサーバーでは、構成図や仕様書が古くなっていたり、担当者しか分からない設定が残っていたりすることもあります。
このような状態のまま移行を進めると、移行対象の漏れ、想定外の通信エラー、移行後の性能不足、コスト増加などにつながる可能性も⋯。
本記事では、オンプレミスサーバーをAWSへ移行する前に確認しておきたい調査項目や、ブラックボックス化した既存資産の棚卸し方法について解説します。
オンプレミスサーバーをAWSへ移行する際、最初に行うべきなのが既存環境の現状調査です。移行というとサーバーをどのAWSサービスに置き換えるか、どのような手順でデータを移すかといった作業に目が向きがちですが、その前提として「現在の環境がどのように構成されているのか」を正しく把握しておく必要があります。
たとえば、サーバーの台数やスペック、OSの種類、利用しているミドルウェア、アプリケーション、データベース、ネットワーク構成などは、移行計画を立てるうえで欠かせない情報です。また、各サーバーがどの業務で使われているのか、停止できる時間帯はあるのか、他のシステムとどのように連携しているのかといった情報も確認しておく必要があります。
現状調査が不十分なまま移行を進めると、移行対象の抜け漏れや、移行後の通信エラー、性能不足、想定外のコスト増加につながるおそれがあります。特に、長年運用されてきたオンプレミス環境では、構成図や仕様書が最新の状態に保たれていないケースも少なくありません。
つまり、現状調査は単なる事前確認ではなく、AWS移行の方針を決めるための土台となる工程です。移行後のトラブルや手戻りを減らすためにも、まずは既存環境の情報を丁寧に整理することから始める必要があります。
オンプレミス環境を長く運用している企業では、サーバーやシステムの構成がブラックボックス化していることがあります。ブラックボックス化とはシステム自体は稼働しているものの、内部の構成や設定、依存関係を十分に把握できていない状態を指します。
たとえば、過去に作成された構成図や手順書が更新されておらず、実際の環境と内容が合っていないケースがあります。また、サーバーの用途や設定を把握していた担当者が異動・退職しており、現在の担当者だけでは詳細を確認できないことも⋯。
また、夜間バッチや定期処理、古い連携処理などが見落とされることも多いです。日中の業務画面だけを見ていると把握しづらい処理が、実は売上集計や在庫管理、外部システムとのデータ連携に関わっている場合もあります。
さらに、性能面でも注意が必要です。現在のサーバースペックだけを見ても、実際にどの程度のCPUやメモリ、ディスク容量、ネットワーク帯域を使っているのかは分かりません。利用状況を確認しないままAWS環境を設計すると、必要以上に大きな構成となってコストが高くなったり、反対に性能が不足して業務に影響が出たりすることがあります。
ブラックボックス化した環境では、見えていない情報が移行リスクになります。AWS移行を円滑に進めるためには、サーバーやアプリケーションの情報を一つずつ確認し、現状を可視化することが重要です。
ここでは、オンプレミスサーバーの移行前調査で確認しておきたい主な項目を解説します。
まず確認したいのが、移行対象となるサーバーの基本情報です。物理サーバーなのか仮想サーバーなのか、サーバーの台数、ホスト名、IPアドレス、OSの種類やバージョン、CPU、メモリ、ディスク容量などを整理します。
あわせて、サーバーの設置場所、稼働年数、保守期限、メーカーや機種、仮想化基盤の情報なども確認しておくとよいでしょう。保守期限が近いサーバーや老朽化した機器は、AWS移行の優先度を高める判断材料になります。
サーバー情報を整理することで、どのサーバーをAWSへ移行するのか、どの程度のリソースが必要になるのかを検討しやすくなります。ただし、現在のスペックをそのままAWS上に置き換えればよいとは限らないため、後述する利用状況や性能情報とあわせて確認することが大切です。
次に、各サーバーが実際にどの程度利用されているかを確認します。CPU使用率、メモリ使用率、ディスク使用量、ディスクI/O、ネットワーク使用量、アクセス数、ピーク時間帯などが主な調査項目です。
オンプレミス環境では、将来の負荷増加を見込んで大きめのサーバーを用意しているケースもあります。そのため、現在のスペックだけを見てAWS環境を設計すると、必要以上に大きなインスタンスを選んでしまい、コストが高くなる可能性があります。
一方で、日中や月末、繁忙期など特定のタイミングだけ負荷が高くなるシステムもあります。平均値だけでなく、ピーク時の利用状況も把握しておくことで、移行後の性能不足を防ぎやすくなります。一定期間の利用状況を収集し、実態に合ったサイジングを行うことが重要です。
サーバー上で稼働しているアプリケーションの情報も、移行前に確認しておくべき項目です。どのサーバーでどのアプリケーションが動いているのか、利用部門、利用目的、業務上の重要度、利用時間帯、停止可能時間などを整理します。
特に業務システムの場合、サーバー単位ではなくアプリケーション単位で移行方針を考える必要があります。同じサーバー上で複数のアプリケーションが動いている場合や、1つのアプリケーションが複数のサーバーにまたがって構成されている場合もあるためです。
また、アプリケーションの改修が必要かどうかも確認しておきたいポイント。OSやミドルウェアのバージョンに依存している場合、AWSへ移行する際にそのまま動作しない可能性があります。事前にアプリケーションの構成や制約を把握しておくことで、移行時の手戻りを減らしやすくなります。
Webサーバー、アプリケーションサーバー、データベース、ジョブ管理ツール、監視ツール、バックアップソフトなど、サーバー上で利用しているミドルウェアや関連ソフトウェアも調査します。
確認すべき項目としては、製品名、バージョン、設定内容、ライセンス条件、保守期限、サポート状況などがあります。古いバージョンのミドルウェアやデータベースを利用している場合、AWS環境への移行時にバージョンアップや構成変更が必要になることもあります。
また、商用ソフトウェアを利用している場合は、クラウド環境での利用可否やライセンスの持ち込み可否も確認しておく必要があります。ライセンス条件を確認しないまま移行を進めると、移行後に追加費用が発生したり、利用条件に合わない構成になったりする可能性が⋯。
データベースについては、データ容量、テーブル数、接続元アプリケーション、バックアップ方式、レプリケーションの有無なども確認しておくと、移行方式を検討しやすくなります。
オンプレミスサーバーの移行では、ネットワーク構成や通信経路の把握も重要です。社内ネットワーク、サーバー間通信、外部サービスとの連携、VPN、ファイアウォール、ロードバランサー、DNS、固定IPアドレスの利用状況などを確認しましょう。
特にブラックボックス化した環境では、どのサーバー同士が通信しているのか、どのポートを利用しているのか、どの外部サービスと連携しているのかが明確になっていないことがあります。この状態で移行を進めると、AWS移行後に通信が遮断され、アプリケーションが正常に動作しない可能性があります。
また、社内からAWSへの接続方法も検討が必要です。インターネット経由で接続するのか、VPNや専用線を利用するのかによって、設計やコスト、セキュリティ要件が変わります。移行後のトラブルを防ぐためには、現在の通信経路を可視化し、AWS上でどのように再現するかを事前に検討しておくことが大切です。
データの種類や容量、保存場所、増加率、バックアップ方式、保持期間、復旧手順なども確認しておきます。データ量が多い場合や、業務停止できる時間が限られている場合は、移行方法や移行スケジュールに大きく影響します。
たとえば、大容量のデータを短時間で移行する必要がある場合、ネットワーク経由での転送だけでは時間が足りないことがあります。また、移行中にデータ更新が発生するシステムでは、移行前後のデータ整合性をどのように確保するかも検討しなければなりません。
バックアップについては、現在の取得方法だけでなく、復旧にかかる時間や復旧手順も確認しておくことが重要です。AWS移行後も同じ運用を続けるのか、AWSのサービスを活用してバックアップや災害対策の仕組みを見直すのかを検討する材料になります。
AWS移行後も安全かつ安定して運用するためには、現在のセキュリティや運用ルールも整理しておく必要があります。アカウント管理、アクセス権限、認証方式、ログ取得、監視項目、障害対応フロー、パッチ適用状況、ウイルス対策などを確認します。
オンプレミス環境では、長年の運用のなかで個別のルールや例外的な設定が増えていることがあります。たとえば、特定の担当者だけが利用している管理アカウントや、一時的に許可したまま残っている通信設定などがあると、移行後のセキュリティリスクにつながる可能性があります。
また、AWSではオンプレミスとは異なる考え方で権限管理やログ管理、監視設計を行う必要があります。そのため、現在の運用をそのまま移すのではなく、移行を機に運用ルールを見直すことも大切です。
技術的な情報だけでなく、業務上の制約や要件も確認しておきましょう。システムを停止できる時間帯、移行してはいけない繁忙期、関係部署との調整事項、法令や社内規程による制約などが該当します。
どれだけ技術的には移行可能であっても、業務への影響が大きいタイミングで作業を行うと、現場に負担がかかる可能性があります。特に基幹システムや顧客向けサービスでは、停止時間や切り戻し手順を慎重に検討する必要があります。
移行前の調査では、技術面だけでなく、業務上どのような条件を満たす必要があるのかも整理しておくことが重要です。これにより、現実的な移行スケジュールや作業計画を立てやすくなります。
オンプレミスサーバーの移行前調査では、サーバーごとの情報だけでなく、業務やシステム同士の依存関係も確認することが大切です。サーバーの台数やスペックを把握できていても、それぞれがどの業務に使われ、どのシステムと連携しているのかが分からなければ、移行時の影響範囲を正しく判断できません。
たとえば、あるサーバー上のアプリケーションが別のサーバーのデータベースを参照していたり、認証基盤やファイルサーバー、外部サービス、夜間バッチと連携していたりする場合があります。こうした関係を把握しないまま一部のサーバーだけを移行すると、移行後にアプリケーションが正常に動作しない、データ連携が止まるといったトラブルにつながる可能性があります。
そのため、移行前調査では「このサーバーをAWSへ移すか」だけでなく、「どの業務を支えているのか」「停止するとどこに影響するのか」「他のシステムと同時に移行すべきか」といった視点で整理することが重要です。
オンプレミスサーバーの現状調査は、情報を集めて終わりではありません。調査結果をもとに、どのサーバーやシステムをAWSへ移行するのか、どの順番で進めるのか、どの程度の期間やコストが必要になるのかを検討していきます。
たとえば、すぐにAWSへ移行できるもの、事前に改修や検証が必要なもの、当面はオンプレミス環境に残すもの、廃止や統合を検討できるものに分類します。すべてをそのままクラウドへ移すのではなく、業務上の必要性や利用状況を踏まえて整理することで、無駄な移行やコスト増加を防ぎやすくなります。
また、既存環境がブラックボックス化している場合、自社だけで必要な情報を洗い出すのが難しいこともあります。、移行対象の整理や依存関係の可視化、移行方針の検討に不安がある場合は専門会社の移行アセスメントを活用するのがおすすめです。現状を正しく把握したうえで方針を決めることが、AWS移行を円滑に進める第一歩になります。
TOKAIコミュニケーションズは、AWS導入から設計・移行・運用までをワンストップで支援するクラウドの専門家。AWSプレミアティアサービスパートナーとして豊富な実績を誇り、 600社以上（2025年9月時点）の導入実績と高い技術力に裏打ちされたサポート体制で、クラウドに不安を抱える企業の心強いパートナーです。