HOME > 技術ドキュメント > 既存Webシステムをクラウドへ移行する手順と注意点

既存Webシステムをクラウドへ移行する手順と注意点

執筆：株式会社エスロジカル（Webシステム受託開発・インフラ構築・クラウド移行支援）

「オンプレ・専用サーバーのコストが高くなった」「サーバーの老朽化が進んでいる」「スケールアウトが必要になった」 といった理由でクラウド移行を検討する企業が増えています。
本記事では、既存 Web システムをクラウドへ移行する際の手順と、失敗しないための判断基準を整理します。

1. 移行前に確認すること：システム棚卸し

移行を始める前に、現行システムの全体像を把握します。見落としが後で大きなトラブルになります。

• 動作している OS とミドルウェアのバージョン：古い CentOS 6・PHP 5.x・Java 8 などの場合、クラウドに持ち込んでも延命にしかならない可能性があります。
• データベースの種類とサイズ：移行方法・ダウンタイムの許容値・マネージド DB（RDS 等）への移行可否に影響します。
• 外部依存：決済 API・外部 SMTP・固定 IP 要件（IP 許可リスト）など、クラウドで再現できない依存関係を洗い出す。
• SSL 証明書：現在の証明書の種類・発行認証局・有効期限を確認する。移行後のドメインで再取得が必要になる場合があります（SSL証明書 FAQ）。
• ドメイン・DNS の管理者：切り替え時に DNS を操作できる担当者と権限を事前に確認する。

2. 移行戦略の選択：リフト&シフト vs リアーキテクチャ

戦略	概要	メリット	デメリット
リフト&シフト （Rehost）	現行構成をほぼそのままクラウドの VM に移す	移行期間が短い・リスクが低い・コードの変更が不要	クラウドのメリットを活かしきれない・古い技術が残る
リプラットフォーム （Replatform）	DB をマネージドサービスに変更するなど、一部最適化する	運用負荷が減る・コストが下がりやすい	設定変更・テストが必要
リアーキテクチャ （Refactor）	コンテナ化・マイクロサービス化など構造から見直す	スケーラビリティ・保守性が向上	期間・コストが大きい

実務判断：「まず動くことを確認してからクラウドの機能を活用する」というアプローチが安全です。 最初のリリースはリフト&シフトで行い、安定稼働を確認してから段階的にリプラットフォームに移行するのが現実的です。

3. 移行計画の立て方（フェーズ分け）

• Phase 1 – 環境構築：クラウド側に新環境を構築し、アプリケーションのデプロイと動作確認を行う。本番トラフィックはまだ向けない。
• Phase 2 – データ移行リハーサル：本番 DB をコピーして新環境でテストし、移行スクリプトと所要時間を確認する。
• Phase 3 – 並行稼働：可能であれば旧環境を維持したまま新環境を一部のユーザーに開放してテストする。
• Phase 4 – 本番切り替え：DNS を新環境に向け変更。旧環境はすぐに廃止せず、最低 1〜2 週間は維持する。
• Phase 5 – 安定稼働確認・旧環境廃止：監視データが安定したら旧環境を廃止する。

4. データ移行の注意点

• ダウンタイムの見積もり：DB サイズが大きいほど移行時間がかかります。事前にリハーサルで計測し、メンテナンス時間を確保する。
• 差分同期：大規模 DB では初回フルダンプ後、本番切り替え直前に差分を同期する方式（レプリケーション利用）でダウンタイムを最小化できます。
• 文字コード・タイムゾーン：MySQL の charset・collation、PostgreSQL のタイムゾーン設定が新旧で一致しているか確認する。文字化けや時刻ズレが頻発するトラブルポイントです。
• ファイルの移行：アップロードされた画像・ファイルは rsync や AWS CLI で転送し、移行前後でファイル数・チェックサムを確認する。

5. SSL証明書の移行

ドメインが変わる場合や証明書の認証方式が変わる場合は、SSL 証明書の再取得が必要です。 移行のタイミングで証明書の種類（DV / OV / EV）を見直す機会にもなります。

• 新環境用の証明書を事前に取得・インストールしておく（DNS 認証は早めに着手）
• 旧証明書の有効期限が切れる前に移行できるようスケジュールを組む
• マルチドメイン証明書（SAN）やワイルドカード証明書を使っている場合は、新環境で同等の証明書を用意する

SSL証明書の一覧・購入はこちら /  購入から発行までの流れ /  CSR 作成・インストール手順

6. DNS 切り替えとダウンタイム最小化

• TTL の事前短縮：切り替え 1〜2 日前に DNS の TTL を 300 秒（5 分）程度に短縮しておく。切り替え後の浸透が早くなります。
• 切り替えタイミング：深夜・早朝のアクセスが少ない時間帯を選ぶ。
• 切り替え後の確認：複数の場所（異なる回線・DNS サーバー）から接続確認を行い、旧環境へのリクエストが減少していることをアクセスログで確認する。
• 旧環境の維持：切り替え後最低 1 週間は旧環境のサーバーを稼働させ、想定外の問題に備える。

7. テスト・検証フロー

• 機能テスト：主要機能のスモークテストを新環境で実施。ログイン・検索・フォーム送信・決済フローなど。
• パフォーマンステスト：旧環境と同等のレスポンスタイムを確認。Apache Bench（ab）や k6 などで負荷をかける。
• SSL 証明書の確認：ブラウザで HTTPS 接続を確認し、証明書チェーンに問題がないことを確認する（SSL証明書インストールチェッカー）。
• ログ・監視の確認：アクセスログ・エラーログ・メトリクス収集が新環境で正しく動作しているか確認する。

8. ロールバック計画

• DNS の TTL を短縮しておけば、旧環境に DNS を戻すだけで数分以内に切り戻せます
• 旧環境の DB データが最新状態になるよう、切り替え直前にバックアップを取得する
• ロールバックの判断基準（エラーレート・レスポンスタイムのしきい値）を事前に決めておく

移行チェックリスト

• □ システム棚卸しが完了している（OS・MW バージョン・外部依存）
• □ 移行戦略（リフト&シフト / リプラットフォーム）を決定した
• □ 新環境で動作確認済み（機能・パフォーマンス）
• □ DB 移行リハーサルを実施し、所要時間を把握している
• □ 新環境の SSL 証明書を取得・インストール済み
• □ DNS の TTL を事前に短縮した
• □ ロールバック手順を文書化した
• □ 監視・アラートが新環境で動作している

← 技術ドキュメント一覧へ戻る