オンプレミスやデータセンターのシステムをAWSへ移行するとき、「リホスト」「リプラットフォーム」「リファクタリング」といった方式の違いを調べる方は多いでしょう。しかし、用語を理解しただけでは、自社に合う方式を決められません。

実務で最初に確認すべきなのは、利用するAWSサービスではなく、業務をどのくらい止められるか、移行中もデータが更新され続けるか、問題が起きたときに元へ戻せるかという制約です。

同じサーバー移行でも、夜間に数時間停止できる社内システムと、24時間注文が入るECシステムでは、データ同期や切り替え方法が変わります。また、短期間でAWSへ移すことを優先するのか、移行と同時に構成を最適化するのかによって、必要な期間とテスト範囲も異なります。

本記事では、停止可能時間とデータ更新頻度を起点に、AWS移行方式を選ぶ手順を解説します。

移行方式をAWSサービス名から決めてはいけない理由

AWSには、サーバー移行を支援するAWS Application Migration Service（AWS MGN）や、データベース移行を支援するAWS Database Migration Service（AWS DMS）などがあります。これらは有力な手段ですが、サービスを先に選ぶと、業務要件に合わない移行計画になる可能性があります。

たとえば、「AWS DMSを使えば停止時間を短くできる」と考えても、アプリケーションが旧環境と新環境へ同時に書き込む設計に対応していなければ、切り替え時の整合性確認が必要です。外部システムとの接続先やバッチ処理が切り替わっていなければ、データが旧環境へ入り続けることもあります。

移行方式は、次の順番で決めることが重要です。

1. 業務上の停止制約を確認する
2. データの更新特性を確認する
3. システム間の依存関係を整理する
4. 移行後にどこまで構成を変えるか決める
5. テスト、切り戻し、運用引き継ぎを設計する
6. 条件に合うAWSサービスと実施方法を選ぶ

技術選定は、業務制約を満たすための手段として行います。

手順1：停止可能時間を具体的にする

「できるだけ止めたくない」という表現だけでは移行方式を決められません。次の項目を業務部門と確認し、数値や時間帯へ落とし込みます。

• システムを停止できる曜日と時間帯
• 許容できる最大停止時間
• 閲覧のみ可能であれば許容されるか
• 一部機能だけ停止することは可能か
• 月末、決算期、繁忙期など避けるべき期間
• 切り替え失敗時に延長できる時間
• 利用者への事前通知に必要な期間

停止可能時間は、移行作業だけでなく、最終データ同期、動作確認、接続先変更、利用者確認、切り戻し判断を含めて考えます。

数時間以上停止できる場合

夜間や休日に十分な停止時間を確保できるなら、更新を止めた後に最終バックアップやデータコピーを行い、新環境で確認して切り替える方法を取りやすくなります。

構成が単純でデータ量が少ないシステムでは、計画も比較的シンプルです。ただし、コピー時間だけでなく、DNS、ネットワーク、ジョブ、外部連携などの切り替えを含めたリハーサルが必要です。

停止時間を短くしたい場合

停止時間を短くするには、事前に大部分のサーバーやデータを複製し、本番切り替え時は差分同期と接続先変更へ作業を絞ります。

AWS MGNでは、移行元サーバーのデータを継続的に複製し、テスト起動やカットオーバーを行う構成を取れます。データベースでは、AWS DMSの継続的レプリケーションを利用し、初期ロード後の変更を移行先へ反映する方法があります。

ただし、停止時間が短いほど、事前テスト、監視、データ整合性確認、切り戻し条件の設計が重要になります。

原則として停止できない場合

24時間利用されるサービスでは、単純な一括切り替えが難しくなります。機能単位、ユーザー単位、地域単位などで段階的に切り替える方法や、一時的に新旧環境を並行稼働させる設計を検討します。

この場合、データの二重書き込み、同期遅延、セッション管理、外部接続、監視の二重化など、アプリケーション側の対応が必要になることがあります。インフラ移行だけでは完結しないため、開発チームを含めた計画が必要です。

手順2：データの更新頻度と整合性要件を確認する

次に、移行対象データがどのように更新されるかを整理します。

• 1日数回のバッチ更新か
• 営業時間中に継続して更新されるか
• 1秒間に多数の更新が発生するか
• 複数のシステムから同じデータを更新するか
• 更新順序に意味があるか
• 一時的な同期遅延を許容できるか
• 移行後に全件照合が必要か、サンプル確認でよいか

更新頻度が低く、業務停止中にデータを固定できるなら、バックアップ・リストアやエクスポート・インポートでも対応しやすいでしょう。

更新が継続するシステムでは、変更データを追跡して移行先へ反映する仕組みが必要です。ここで重要なのは、「同期できる」ことと「業務上正しい状態で切り替えられる」ことは同じではない点です。

切り替え直前に更新を一時停止し、同期遅延が解消されたことを確認し、アプリケーションの接続先を変更するなど、整合性を守る手順を決めます。

手順3：システムの依存関係を棚卸しする

移行対象サーバーだけを見ていると、切り替え後に外部連携が動かないことがあります。最低限、次を棚卸しします。

• 接続するデータベース、ファイルサーバー、認証基盤
• 外部API、SaaS、取引先システム
• IPアドレスを許可リストへ登録している接続先
• DNS名、証明書、プロキシ、ロードバランサー
• バッチ、ジョブ、ファイル転送
• 監視、バックアップ、ログ収集
• 運用端末や管理経路
• ライセンスがサーバー情報へひも付くソフトウェア

依存関係が多い場合は、単体で移行するより、関連システムを同じ移行ウェーブにまとめる方が安全なことがあります。一方で、大きな単位へまとめすぎると、一度の切り替えリスクが高まります。

「一緒に移す必要があるもの」と「後から切り替えられるもの」を分け、移行ウェーブを設計します。

手順4：移行後にどこまで構成を変えるか決める

停止時間だけでなく、移行の目的も方式へ影響します。代表的な考え方は次の3つです。

Lift & Shiftで早く移す

現行構成を大きく変えずAWSへ移す方法です。ハードウェア保守切れやデータセンター退去など期限が明確で、まず移行完了を優先する場合に向いています。

変更範囲を抑えられる一方、現行環境の運用負荷や構成上の課題を引き継ぐ可能性があります。移行後に性能、可用性、コスト、セキュリティを見直す計画を用意します。

移行と同時にクラウド向けへ最適化する

データベースやストレージのマネージドサービス化、冗長化、バックアップ、監視などを見直しながら移行します。

移行後の運用負荷や可用性を改善しやすい一方、テスト範囲が広くなり、アプリケーションの変更が必要になる場合があります。停止期限と改善効果のバランスを確認します。

クラウドネイティブに再構築する

サーバーレスやコンテナ、マネージドサービスを活用し、アプリケーションを再設計します。拡張性や変更スピードの向上を期待できますが、開発・テスト期間は長くなります。

期限が迫るインフラ更改と同時に全面再構築を行うと、計画が複雑になりがちです。まずLift & Shiftで期限を守り、その後に段階的なモダナイズを行う選択肢もあります。

手順5：切り戻し条件を先に決める

移行計画では、成功手順だけでなく、どの状態なら旧環境へ戻すかを決めます。

切り戻し条件の例は次のとおりです。

• 主要機能の動作確認が期限内に完了しない
• データ件数や残高が一致しない
• 性能が業務基準を満たさない
• 外部連携の一部が復旧しない
• 重大なセキュリティ設定不備が見つかる
• 切り替え後の障害が一定時間内に解消しない

判断期限を決めておかないと、復旧を続けるか戻すかで時間を消費します。誰が切り戻しを決定するか、移行後に旧環境へ発生したデータをどう扱うかも事前に決めます。

新旧環境を並行稼働する場合は、どちらを正とするかを明確にし、両方へ更新が発生する状態を可能な限り短くします。

手順6：本番前に移行リハーサルを行う

移行リハーサルでは、技術的なコピーだけでなく、本番当日の意思決定と連絡まで確認します。

• 実際のデータ量で移行時間を測る
• 接続先変更とDNS反映を確認する
• 動作確認項目と担当者を確認する
• データ整合性の確認方法を試す
• 監視、バックアップ、ログが機能するか確認する
• 切り戻しを実際に試す
• 利用者・関係部署への連絡手順を確認する

初回リハーサルで判明した作業時間や問題を計画へ反映し、本番のタイムラインを更新します。特に「確認待ち」が停止時間を延ばすことがあるため、担当者と承認者の待機時間も含めます。

移行対象の棚卸しや方式選定から支援が必要な場合は、SunnyCloudへAWS移行について相談できます。問い合わせフォームでは「AWS環境構築・移行 総合支援サービス」を選択できます。

AWS移行方式を選ぶ簡易判断表

この表は初期判断用です。実際には、OS・ミドルウェア、データベース、ライセンス、ネットワーク、セキュリティ、関係者の協力可能性なども含めて評価します。

まとめ：移行方式は「止められる時間」から逆算する

AWS移行方式は、流行しているサービスや一般的なメリットだけで決めるものではありません。まず、停止可能時間、データ更新頻度、依存関係、切り戻し条件を整理し、その制約を満たす方法を選びます。

選定の流れは次のとおりです。

1. 停止できる時間帯と最大停止時間を決める
2. データ更新頻度と整合性要件を確認する
3. 外部連携を含む依存関係を棚卸しする
4. Lift & Shift、最適化、再構築の範囲を決める
5. 切り戻し条件と判断者を決める
6. 実データに近い条件でリハーサルする
7. 条件に合うAWSサービスと移行手順を確定する

関連セミナー・資料

AI活用、コスト最適化、モダナイゼーション、データ活用などの注目テーマを整理しています。