インフラ

オンプレミスからクラウドへのサーバ移行手順｜失敗しない計画の立て方

オンプレミスからクラウドへのサーバ移行手順を解説。移行計画の策定方法、リスク管理、切り替え時の注意点を中小企業の事例とともに紹介します。

クラウド移行サーバ移行AWS移行計画

クラウド移行の必要性と背景

「自社データセンターのサーバーが老朽化してきた」「保守費用が高騰している」「リモートワークに対応したい」——こうした理由から、オンプレミス環境からクラウドへの移行を検討する企業が増えています。私がコンサルティングを行う中小企業でも、クラウド移行の相談が年々増加しています。

クラウド移行には、コスト削減、柔軟なスケーラビリティ、運用負荷の軽減など多くのメリットがあります。一方で、移行計画が不十分だと、予期せぬダウンタイムが発生したり、移行後にパフォーマンスが低下したりするリスクもあります。

本記事では、オンプレミスからクラウドへのサーバ移行を成功させるための手順を、移行計画の策定方法、リスク管理、切り替え時の注意点を中心に、実例を交えて解説します。インフラ設計全般についてはインフラ設計入門もあわせてご覧ください。

クラウド移行のメリットとデメリット

まず、クラウド移行のメリットとデメリットを整理します。

メリット

1. 初期投資の削減 オンプレミス環境では、サーバー機器、ネットワーク機器、ラックスペース、電源設備などの初期投資が必要です。クラウドでは、これらの設備投資が不要になり、必要な分だけ利用できます。

2. 柔軟なスケーラビリティ ビジネスの成長に応じて、リソース（CPU、メモリ、ディスク）を柔軟に増減できます。オンプレミスでは、サーバーの増設に数週間〜数か月かかりますが、クラウドでは数分で完了します。

3. 運用負荷の軽減 ハードウェアの保守、OS・ミドルウェアのパッチ適用、データセンターの物理的な管理などの運用作業を、クラウドプロバイダーに委託できます（マネージドサービスを利用する場合）。

4. 高可用性と災害復旧 クラウドプロバイダーは、複数のデータセンター（リージョン、アベイラビリティゾーン）を持ち、高い可用性を提供します。災害時のバックアップやフェイルオーバーも容易に実現できます。

詳しくは災害復旧（DR）計画の立て方をご覧ください。

5. リモートアクセスの容易さ クラウド環境は、インターネット経由でどこからでもアクセスできるため、リモートワークや多拠点運用に適しています。

デメリット

1. ランニングコストの変動 クラウドは従量課金制が基本です。使用量が増えると、コストも増加します。適切なコスト管理を怠ると、想定外の請求が発生する可能性があります。

コスト最適化についてはクラウドコスト最適化の実践ガイドをご覧ください。

2. ベンダーロックイン 特定のクラウドプロバイダーのサービスに依存すると、他のプロバイダーへの移行が困難になります。

3. セキュリティとコンプライアンス クラウド環境では、データが外部のデータセンターに保管されるため、セキュリティやコンプライアンスの要件を満たす必要があります。

クラウドセキュリティの詳細はクラウドセキュリティの基礎知識を参照してください。

4. インターネット接続への依存 クラウドサービスはインターネット経由でアクセスするため、インターネット回線に障害が発生すると、サービスにアクセスできなくなります。

クラウド移行の6つのアプローチ（6R）

クラウド移行には、いくつかのアプローチがあります。AWSが提唱する「6R」と呼ばれるフレームワークを紹介します。

1. Rehost（リホスト / Lift and Shift）

オンプレミスのシステムをほぼそのままクラウドに移行する方法です。「Lift and Shift（持ち上げて移動）」とも呼ばれます。

特徴

  • 最も短期間で移行可能
  • アプリケーションの改修が不要
  • クラウドの特性を活かしきれない

適用ケース

  • 移行期限が迫っている場合
  • レガシーシステムで、改修が困難な場合
  • まずはクラウドに移行し、後で最適化する計画の場合

2. Replatform（リプラットフォーム）

アプリケーションのコアロジックは変更せず、一部をクラウドのマネージドサービスに置き換える方法です。

特徴

  • Rehostよりもクラウドのメリットを享受できる
  • 部分的な改修が必要
  • 運用負荷を軽減できる

適用ケース

  • データベースをAmazon RDSやAzure SQL Databaseに移行
  • ファイルサーバーをAmazon S3やAzure Blob Storageに移行

例 オンプレミスでMySQLを運用していた場合、Amazon RDS for MySQLに移行することで、バックアップ、パッチ適用、高可用性構成などをAWSに委託できます。

3. Repurchase（リパーチェス）

既存のシステムを廃止し、SaaS（Software as a Service）などのクラウドサービスに置き換える方法です。

特徴

  • システムの運用・保守が不要
  • ライセンス費用がサブスクリプション型に変わる
  • データ移行やカスタマイズが必要

適用ケース

  • オンプレミスのメールサーバーをMicrosoft 365やGoogle Workspaceに移行
  • オンプレミスのERPをクラウドERPに移行

4. Refactor（リファクター / Re-architect）

クラウドネイティブなアーキテクチャに全面的に作り変える方法です。

特徴

  • クラウドのメリットを最大限活用できる（自動スケーリング、サーバーレスなど）
  • 開発コストと時間がかかる
  • 最も柔軟で高性能

適用ケース

  • モノリシックなアプリケーションをマイクロサービス化
  • サーバーレスアーキテクチャ（AWS Lambda、Azure Functionsなど）への移行

5. Retire（リタイア）

不要になったシステムを廃止する方法です。

特徴

  • システムの数を減らし、管理を簡素化
  • コスト削減

適用ケース

  • 使われていないレガシーシステム
  • 他のシステムに統合されたシステム

6. Retain（リテイン）

クラウドに移行せず、オンプレミスに残す方法です。

特徴

  • 移行のリスクやコストが高い場合に選択

適用ケース

  • 法規制により、データを外部に保管できないシステム
  • 移行のコストが見合わないシステム

中小企業の多くは、Rehost（Lift and Shift）から始め、段階的にReplatformやRepurchaseに移行するアプローチが一般的です。

クラウド移行の計画策定

クラウド移行を成功させるには、綿密な計画が不可欠です。以下、移行計画の策定手順を解説します。

ステップ1: 現状調査（アセスメント）

まず、現在のオンプレミス環境を詳細に調査します。

調査項目

  • サーバー台数とスペック: CPU、メモリ、ディスク容量
  • OS・ミドルウェア: バージョン、ライセンス情報
  • アプリケーション: 構成、依存関係、カスタマイズ内容
  • ネットワーク構成: IPアドレス体系、ファイアウォール設定
  • ストレージ容量: 現在の使用量、増加傾向
  • バックアップ: 方式、頻度、保管場所
  • ピーク時の負荷: CPU、メモリ、ディスクI/O、ネットワーク帯域

この調査をもとに、クラウド環境での必要リソースを見積もります。

ステップ2: 移行対象の優先順位付け

全てのシステムを一度に移行するのではなく、優先順位を付けて段階的に移行します。

優先順位の基準

  • 移行の難易度: 依存関係が少なく、単純なシステムから移行
  • ビジネスへの影響: 影響が小さいシステムから移行（開発環境、テスト環境など）
  • 移行のメリット: 移行によるコスト削減や運用効率化の効果が大きいシステムを優先

例

  1. 開発環境、テスト環境（影響が小さく、移行の練習になる）
  2. ファイルサーバー（S3などのオブジェクトストレージに移行しやすい）
  3. Webサーバー、アプリケーションサーバー
  4. データベース（最も慎重な移行が必要）

ステップ3: クラウドプロバイダーの選定

主要なクラウドプロバイダーを比較し、自社に最適なものを選定します。

主要プロバイダー

  • AWS（Amazon Web Services）: 最も実績が豊富、幅広いサービス、中〜大規模企業向け
  • Microsoft Azure: Microsoft製品との親和性が高い、Windowsサーバーの移行に強み
  • Google Cloud Platform（GCP）: データ分析・機械学習に強み、スタートアップ向け

中小企業では、AWSまたはAzureが一般的です。既にMicrosoft 365を使っている場合は、Azureが統合管理しやすく便利です。

詳しくはクラウド vs オンプレミス、どちらを選ぶべきかも参照してください。

ステップ4: 移行方式の決定

各システムについて、どの移行方式（6Rのどれか）を採用するかを決定します。

例

  • ファイルサーバー: Replatform（Amazon S3に移行）
  • Webサーバー: Rehost（EC2に移行し、将来的にコンテナ化を検討）
  • データベース: Replatform（Amazon RDSに移行）
  • メールサーバー: Repurchase（Microsoft 365に移行）

ステップ5: 移行スケジュールの策定

移行の全体スケジュールを策定します。

スケジュール例（全体で3〜6か月）

  1. 準備フェーズ（1〜2か月）: 現状調査、計画策定、クラウド環境の構築
  2. パイロット移行（1か月）: 開発環境やテスト環境を先行移行
  3. 本番移行（1〜2か月）: 段階的に本番環境を移行
  4. 安定化フェーズ（1か月）: 移行後の監視、チューニング

移行スケジュールには、余裕を持たせてください。予期せぬトラブルが発生する可能性があります。

ステップ6: リスク分析と対策

移行に伴うリスクを洗い出し、対策を講じます。

主なリスク

  • ダウンタイムの発生: 移行中にサービスが停止
  • データ損失: 移行中のデータ破損や欠損
  • パフォーマンス低下: 移行後にシステムが遅くなる
  • コスト超過: 想定よりもクラウド費用が高額になる

対策

  • ダウンタイム: 移行は深夜や休日に実施、ダウンタイムを最小限に
  • データ損失: 移行前に完全バックアップを取得、移行後にデータ整合性を確認
  • パフォーマンス: 事前に負荷テストを実施、十分なリソースを確保
  • コスト超過: 事前にコスト見積もりを行い、予算を確保

移行の実施手順

ここでは、WebサーバーとデータベースをオンプレミスからAWSに移行する例を紹介します。

事前準備

1. AWSアカウントの作成 AWSのアカウントを作成し、IAM（Identity and Access Management）でユーザーとアクセス権限を設定します。

2. ネットワーク設計 VPC（Virtual Private Cloud）を作成し、サブネット、ルーティング、セキュリティグループを設計します。

例：

  • VPC: 10.0.0.0/16
  • パブリックサブネット: 10.0.1.0/24（Webサーバー用）
  • プライベートサブネット: 10.0.2.0/24（データベース用）

3. セキュリティグループの設定

  • Webサーバー: インターネットからHTTP（80）、HTTPS（443）を許可
  • データベース: Webサーバーからのみアクセスを許可（例: MySQL 3306ポート）

Webサーバーの移行（Rehost）

ステップ1: EC2インスタンスの起動 オンプレミスサーバーと同等のスペックのEC2インスタンスを起動します。

例：

  • インスタンスタイプ: t3.medium（2vCPU、4GBメモリ）
  • OS: Ubuntu 22.04 LTS
  • ストレージ: 50GB gp3

ステップ2: アプリケーションのコピー オンプレミスサーバーからアプリケーションファイルをコピーします。

rsyncを使った例

rsync -avz -e "ssh -i my-key.pem" /var/www/html/ ubuntu@ec2-xx-xx-xx-xx.compute.amazonaws.com:/var/www/html/

ステップ3: ミドルウェアのインストールと設定 EC2インスタンスに、Apache、PHP、Nginxなど必要なミドルウェアをインストールします。

ステップ4: 動作確認 EC2インスタンスのパブリックIPアドレスにアクセスし、Webサイトが正常に表示されることを確認します。

データベースの移行（Replatform）

ステップ1: RDSインスタンスの作成 Amazon RDSでMySQLインスタンスを作成します。

設定例：

  • エンジン: MySQL 8.0
  • インスタンスクラス: db.t3.medium
  • ストレージ: 100GB gp3
  • マルチAZ: 有効（高可用性のため）

ステップ2: データのエクスポート オンプレミスのMySQLから、データをエクスポートします。

mysqldump -u root -p --databases mydb --result-file=mydb_backup.sql

ステップ3: データのインポート エクスポートしたデータを、RDSインスタンスにインポートします。

mysql -h mydb.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -u admin -p mydb < mydb_backup.sql

ステップ4: アプリケーションの接続先変更 Webサーバーのアプリケーション設定ファイルで、データベース接続先をRDSのエンドポイントに変更します。

ステップ5: 動作確認 Webサイトにアクセスし、データベースへの接続が正常に動作することを確認します。

DNS切り替え

移行が完了したら、DNSレコードを変更し、トラフィックをクラウド環境に向けます。

ステップ1: TTLの短縮 DNS切り替えの数日前に、TTL（Time To Live）を短く設定します（例: 300秒）。これにより、DNS変更が迅速に反映されます。

ステップ2: AレコードまたはCNAMEレコードの変更

example.com.  A  203.0.113.10  （EC2のパブリックIPアドレス）

または、Elastic Load Balancer（ELB）を使う場合：

example.com.  CNAME  my-alb-xxxxxxxxxxxx.ap-northeast-1.elb.amazonaws.com.

ステップ3: 切り替え確認 DNS変更が反映されたか、digやnslookupで確認します。

dig example.com

ステップ4: 旧環境の監視 DNS切り替え後も、数日間は旧環境を監視します。DNSキャッシュの影響で、一部のユーザーが旧環境にアクセスする可能性があるためです。

DNSの詳細はドメイン・DNS・SSL証明書の管理ガイドをご覧ください。

旧環境の廃止

クラウド環境が安定稼働していることを確認した後、旧環境を廃止します。

廃止の手順

  1. 旧環境の完全バックアップを取得（念のため）
  2. 旧環境のサービスを停止
  3. データを完全に削除（機密情報の漏洩防止）
  4. ハードウェアを返却またはリサイクル

移行後の最適化

移行が完了した後も、継続的な最適化が必要です。

コスト最適化

クラウドのコストを定期的にレビューし、無駄を削減します。

最適化の例

  • リザーブドインスタンス: 1年または3年契約で、EC2やRDSのコストを最大75%削減
  • スポットインスタンス: 余剰リソースを安価に利用（バッチ処理などに適用）
  • Auto Scaling: 負荷に応じてインスタンス数を自動調整
  • 不要なリソースの削除: 使われていないEBS（ディスク）やスナップショットを削除

詳しくはクラウドコスト最適化の実践ガイドをご覧ください。

パフォーマンスチューニング

移行後、パフォーマンスをモニタリングし、必要に応じてチューニングします。

チューニングの例

  • インスタンスタイプの変更（CPU、メモリの増減）
  • データベースのインデックス最適化
  • CDN（CloudFront、Azure CDNなど）の活用
  • キャッシュ（ElastiCache、Redisなど）の導入

セキュリティ強化

クラウド環境のセキュリティを継続的に強化します。

セキュリティ対策の例

  • 多要素認証（MFA）の有効化
  • セキュリティグループ、ネットワークACLの見直し
  • 不要なポートを閉じる
  • AWS IAMの権限を最小限に設定（最小権限の原則）
  • ログの収集と分析（CloudTrail、CloudWatch Logs）

詳しくはクラウドセキュリティの基礎知識をご覧ください。

監視とアラート

移行後も、継続的な監視とアラートが必要です。

監視項目の例：

  • EC2インスタンスのCPU、メモリ使用率
  • RDSの接続数、スロークエリ
  • アプリケーションのエラーログ
  • ネットワークトラフィック

詳しくはサーバ監視・アラート設計入門をご覧ください。

失敗しやすいポイント

クラウド移行で、中小企業が陥りがちな失敗パターンを紹介します。

1. 現状調査が不十分

オンプレミス環境の詳細な調査を怠り、移行後に「必要なデータが移行されていなかった」「依存関係のあるシステムが動かない」といった問題が発生します。

対策

  • 現状調査を徹底し、全てのサーバー、アプリケーション、依存関係を洗い出す
  • 移行計画書に詳細を記録

2. 移行のテスト不足

本番環境をいきなり移行し、トラブルが発生します。

対策

  • 開発環境やテスト環境で先行移行し、問題を洗い出す
  • 本番移行のリハーサルを実施

3. ダウンタイムの長期化

移行作業が予定より長引き、ダウンタイムが延びてしまいます。

対策

  • 移行手順を詳細に文書化し、リハーサルで時間を計測
  • 余裕を持ったスケジュールを設定
  • 必要に応じて、段階的移行やブルーグリーンデプロイメントを採用

4. コスト見積もりの甘さ

移行後のクラウド費用が、当初の見積もりを大幅に超えてしまいます。

対策

  • AWS Pricing Calculator、Azure Pricing Calculatorなどで事前に見積もり
  • 移行後も定期的にコストをレビュー
  • 予算アラートを設定

5. セキュリティ設定の不備

クラウド環境のセキュリティ設定が不十分で、不正アクセスや情報漏洩が発生します。

対策

  • セキュリティグループ、IAM、ネットワークACLを適切に設定
  • 定期的なセキュリティ監査を実施
  • AWS Trusted Advisor、Azure Security Centerなどのツールを活用

導入事例: オンプレミスからAWSへの段階的移行

ここでは、製造業の企業がオンプレミス環境からAWSに段階的に移行した事例を紹介します。

企業プロフィール

業種: 製造業（精密機械部品） 従業員数: 150名 IT体制: 情報システム部1名、外部SIer

課題

同社は、10年前に構築したオンプレミス環境（物理サーバー5台）を運用していましたが、以下の課題を抱えていました。

  • サーバー機器の老朽化（保守期限が迫っている）
  • データセンター（自社ビル内のサーバールーム）の空調設備が故障しがち
  • バックアップが手動運用で、復旧に時間がかかる
  • リモートワークに対応できていない

ハードウェアを更改する場合、初期投資が500万円程度必要と見積もられ、経営層はクラウド移行を検討することにしました。

移行計画

移行方針 全システムを一度に移行するのではなく、段階的に移行する方針を採用しました。

第1フェーズ: ファイルサーバーの移行（Replatform）

  • 目的: クラウドに慣れる、リモートアクセスの実現
  • 移行先: Amazon S3 + AWS Storage Gateway

第2フェーズ: 開発環境・テスト環境の移行（Rehost）

  • 目的: EC2での運用を習得
  • 移行先: Amazon EC2

第3フェーズ: 基幹システムの移行（Replatform）

  • 目的: 本番環境の移行
  • 移行先: Amazon EC2（Webサーバー）+ Amazon RDS（データベース）

移行スケジュール

  • 第1フェーズ: 2か月
  • 第2フェーズ: 1か月
  • 第3フェーズ: 3か月
  • 合計: 6か月

第1フェーズ: ファイルサーバーの移行

実施内容 オンプレミスのファイルサーバー（Windows Server）を、Amazon S3に移行しました。社内からのアクセスは、AWS Storage Gateway（ファイルゲートウェイ）を経由することで、従来と同じ使い勝手を維持しました。

移行手順

  1. Amazon S3バケットを作成
  2. AWS Storage Gatewayをオンプレミスのサーバーにインストール
  3. 既存のファイルをS3にコピー（AWS DataSyncを使用）
  4. 従業員のPCから、Storage Gateway経由でアクセス

成果

  • ファイルサーバーのハードウェア保守が不要に
  • バックアップが自動化（S3のバージョニング機能）
  • リモートワーク時も、VPN経由でファイルにアクセス可能

第2フェーズ: 開発環境の移行

実施内容 開発環境とテスト環境のサーバーをEC2に移行しました（Rehost）。

移行手順

  1. EC2インスタンスを起動（t3.medium、Ubuntu 22.04）
  2. アプリケーションコードをrsyncでコピー
  3. 開発チームに動作確認を依頼

成果

  • 開発環境の起動・停止が柔軟に（不要時は停止してコスト削減）
  • 開発チームがクラウド環境に慣れた

第3フェーズ: 基幹システムの移行

実施内容 基幹システム（受発注管理システム）を、EC2とRDSに移行しました。

移行手順

  1. VPC、サブネット、セキュリティグループを設計
  2. RDS for MySQLインスタンスを作成
  3. オンプレミスのMySQLから、データをエクスポート・インポート
  4. EC2インスタンスにWebサーバー（Apache）とアプリケーションをインストール
  5. 週末にDNS切り替えを実施

ダウンタイム 土曜日の深夜2時〜6時（4時間）にメンテナンスを実施しました。実際のダウンタイムは約2時間でした。

成果

  • サーバーの物理的な保守が不要に
  • RDSの自動バックアップにより、復旧時間が短縮
  • マルチAZ構成により、高可用性を実現

移行後のコスト比較

移行前（オンプレミス）

  • サーバー購入費（5年償却）: 月額約8万円
  • 保守費用: 月額5万円
  • 電気代: 月額2万円
  • 合計: 月額約15万円

移行後（AWS）

  • EC2（3インスタンス）: 月額3万円
  • RDS（1インスタンス、マルチAZ）: 月額4万円
  • S3、Storage Gateway: 月額1万円
  • その他（VPN、CloudWatchなど）: 月額1万円
  • 合計: 月額約9万円

月額6万円のコスト削減を実現しました。また、ハードウェアの更改費用（500万円）が不要になったことも大きなメリットです。

運用のポイント

移行後、情報システム部の担当者は、AWS認定資格（AWS Certified Solutions Architect - Associate）を取得し、クラウド運用のスキルを向上させました。また、外部SIerとの保守契約を継続し、トラブル時のサポート体制を確保しました。

まとめ

オンプレミスからクラウドへのサーバ移行は、綿密な計画とリスク管理が成功の鍵です。本記事のポイントをまとめます。

クラウド移行のメリット

  • 初期投資の削減、柔軟なスケーラビリティ、運用負荷の軽減、高可用性

移行のアプローチ（6R）

  • Rehost、Replatform、Repurchase、Refactor、Retire、Retain
  • 中小企業はRehost（Lift and Shift）から始め、段階的に最適化

移行計画の策定

  • 現状調査（アセスメント）を徹底
  • 移行対象の優先順位付け
  • クラウドプロバイダーの選定
  • 移行スケジュールとリスク分析

移行の実施

  • 事前準備（ネットワーク設計、セキュリティ設定）
  • Webサーバー、データベースの移行
  • DNS切り替え
  • 旧環境の廃止

移行後の最適化

  • コスト最適化（リザーブドインスタンス、Auto Scalingなど）
  • パフォーマンスチューニング
  • セキュリティ強化
  • 継続的な監視

クラウド移行は、一度に全てを完璧に移行する必要はありません。まずは小規模なシステムで経験を積み、段階的に本番環境を移行することで、リスクを最小限に抑えながら、クラウドのメリットを享受できます。

関連記事