データセンターの契約満了が決まり、数百台のサーバーとデータベースを期限までに AWS へ移す。まず悩むのは「どのサービスで運ぶか」に見えますが、実際に計画が崩れるのは、その手前の判断が曖昧なときです。どれを捨て、どれを残し、どれを作り直すのか。どの順番で運ぶのか。止めてよいのは何時間か。戻すと決めたら誰が判断するのか。
この記事は、移行の道具の説明ではなく、7R（7つの移行戦略）を決める軸、移行の順番の組み方、転送手段とカットオーバーの選び方を、要件が変わると答えがどう変わるかという形で整理します。
この記事の結論
- クラウド移行の設計は、期限・停止できる時間・データ量と回線・体制と予算を先に書き出し、そこから戦略と道具を逆算する仕事です。
- 7R は「使い続けるか」「今移す理由があるか」「どこまで変えるか」の順に絞ると、アプリごとの戦略がぶれにくくなります。
- 移行の順番は、依存関係でアプリを束ね、低リスクのパイロットから重い基幹系へ進めるウェーブで組みます。
- 転送手段はデータ量を回線の実効帯域で割った日数で決め、Snowball Edge が新規の顧客に提供されない前提で計画します。
- カットオーバーは、継続的な複製で停止を短くしたうえで、切り戻しの手段と期限と判断者を先に決めておきます。
クラウド移行の設計とは何を決めることか
AWS の規範ガイダンス（Prescriptive Guidance）は、大規模な移行を「評価（Assess）」「準備（Mobilize）」「移行とモダナイズ（Migrate and Modernize）」の3つの段階で進める形を示しています。評価で事業上の理由と組織の準備状況を確かめ、準備で着地先の環境（ランディングゾーン）と体制を作り、そのうえでサーバーを数で運ぶ、という順番です。
設計者が決めるのは、この流れの中の「判断の軸」です。同じ 400 台でも、期限が5か月か2年か、停止が数分しか許されないか週末に数時間止められるかで、選ぶ戦略も道具もまったく変わります。だから最初に、技術の選択肢ではなく要件を書き出します。
MIGRATION REQUIREMENTS先に書き出す要件
戦略と道具は技術からではなく4つの要件から逆算する
-
1.期限と規模 — 契約満了日、台数、アプリの数
作り直しに使える時間。リホスト中心か、作り直しを混ぜられるか
-
2.停止できる時間 — アプリごとに分か時間か
継続的な複製が要るか、ダンプと戻しで足りるか
-
3.データ量と回線 — 総容量・日々の変更量・帯域
転送の日数。回線の増強を先に入れるか
-
4.体制と予算 — 人数と、二重の費用を払える期間
並行稼働をどこまで許すか。マネージドへ寄せるか
| 先に書き出す要件 | 何が決まるか | 書き出し方の例 |
|---|---|---|
| 期限と規模 | 作り直しに使える時間。リホスト中心か、作り直しを混ぜられるか | 契約満了日、台数、アプリの数 |
| 停止できる時間 | 継続的な複製が要るか、ダンプと戻しで足りるか | アプリごとの許容停止（分・時間）と、止めてよい曜日と時間帯 |
| データ量と回線 | 転送に何日かかるか、回線の増強が要るか | 総容量、日々の変更量、回線の帯域と使ってよい割合 |
| 体制と予算 | 並行稼働をどれだけ続けられるか、どこまで自分で運用するか | 移行に割ける人数、二重の費用を払える期間 |
この4つは、アプリごとに違う値になります。全体で1つの答えを出すのではなく、アプリごとに戦略を割り当て、それを束ねて順番に並べるのが移行の設計です。
7R はどの軸で決めるのか
7R は、AWS の規範ガイダンスがまとめた7つの移行戦略です。名前と意味は次のとおりです。
| 戦略 | 何をするか | 合う条件 |
|---|---|---|
| リタイア（Retire） | 使っていないアプリを廃止する | 利用者がいない、機能が他に吸収されている |
| リテイン（Retain） | 当面は移行元に残し、後で判断し直す | 近く大きな作り直しが控えている、移す事業上の理由がない |
| リロケート（Relocate） | ハイパーバイザーの単位で、アプリも OS も変えずに移す。AWS の中で別の VPC・リージョン・アカウントへ移す場合もこう呼ぶ | 仮想化基盤ごと運びたい、運用を変えたくない |
| リホスト（Rehost） | 変更せずにサーバーを EC2 などへ移す（リフト&シフト） | 期限が短い、台数が多い、変更のリスクを取りたくない |
| リプラットフォーム（Replatform） | 中核の構造は変えず、一部をマネージドサービスに置き換える | 自前運用の DB を RDS へ、など運用の手間を減らしたい |
| リパーチェス（Repurchase） | 別の製品、典型的には SaaS に乗り換える | 市販の製品で業務が足り、インフラの保守をやめたい |
| リファクタ（Refactor / Re-architect） | クラウドの機能を活かす形に作り直す | 俊敏性や拡張性が事業の差になり、作り直す時間がある |
名前を覚えるより大事なのは、決める順番です。この記事では次の3つの問いで絞ります。
- 使い続けるか。 使っていなければリタイア。棚卸しで利用者のいないアプリが見つかると、それだけで移行の総量が減ります。
- 今移す理由があるか。 作り直しが近い、または移す理由がないならリテイン。期限に追われて全部を運ぶより、残すものを先に決めるほうが計画は軽くなります。
- どこまで変えるか。 変えない（リホスト・リロケート）、一部を置き換える（リプラットフォーム）、製品を替える（リパーチェス）、作り直す（リファクタ）。ここは期限と、そのアプリが事業の差になる度合いで決めます。
CHOOSING THE R7R を2軸で絞る
差になるのに時間が無いなら先に運んで後で作り直す
そのアプリが事業の差になる度合い →
リホスト → 後でリファクタ
期限までは変えずに運び、移行後に作り直す
リファクタ
時間があり、俊敏性や拡張性が事業の差になる
リホスト／リテイン
差にならず時間も無い。運ぶか、当面は残すか
リパーチェス／リプラットフォーム
SaaS に替えるか、DB などをマネージドに置き換える
作り直しに使える時間 →
図の2軸はこの記事の整理です（使っていないアプリは、リタイアとして先に外してから置きます）。期限が短く、しかも事業の差になるアプリは、まずリホストで運び、移行後にリファクタする二段構えが現実的です。規範ガイダンスも「一般に、まず移し、それからモダナイズする」という順を示しています。規範ガイダンスは大規模な移行でよく使う戦略としてリホスト・リプラットフォーム・リロケート・リタイアを挙げており、リファクタは移行の期限とは切り離して計画するほうが、期限を守りやすくなります。
CHECK 1ここまでの確認
この記事が、7R を決めるときに最初に置いた問いはどれ?
答えと解説
答え: 2. そのアプリを使い続けるか、今移す事業上の理由があるか
7R の最初の分かれ道は「使い続けるか（リタイア）」と「今移す理由があるか（リテイン）」です。道具は戦略が決まってから選びます。「7R はどの軸で決めるのか」を読み直してください。
移行の順番（ウェーブ）はどう組むのか
戦略が決まったら、アプリを「一緒に運ぶ束」にまとめて順番に並べます。この束をウェーブ（移行の波）と呼びます。規範ガイダンスは、ウェーブの計画には次の4つが揃っている必要があるとしています。
- アプリのポートフォリオの全体像（何があり、誰が持ち主か）
- それぞれが載っているインフラ（計算・ストレージ・ネットワーク）
- アプリ同士の依存関係
- アプリごとの移行戦略（7R）
依存関係で束ねる
頻繁に通信する2つのアプリを別のウェーブに分けると、片方が AWS、片方がオンプレミスという期間ができ、その間の遅延と回線の費用が問題になります。同じデータベースを読むアプリ群、同じバッチの連鎖にあるアプリ群は、同じウェーブに入れるのが基本です。依存の洗い出しは、構成管理の台帳だけでなく、実際の通信の記録から確かめます。
低リスクから始めて、手順を固める
最初のウェーブは、依存が少なく、失敗しても影響の小さいアプリをパイロットにします。目的は移行そのものより、手順書（ランブック）と体制とツールの設定を実地で固めることです。規範ガイダンスでは、1つのウェーブは詳しい評価、移行の準備、インフラの構築とテスト、データ転送、カットオーバー、振り返りまでを含み、長さは4〜8週間が目安とされています。
棚卸しの道具は受付状況を確かめる
棚卸しと依存の把握に使われてきた AWS Migration Hub と AWS Application Discovery Service は、2025年11月7日から新規の顧客を受け付けていません（既存の顧客は進行中の移行に使えます）。これから始める場合、公式は後継として AWS Transform を案内しています。どの道具を使っても、台帳に残すべきものは「アプリ・持ち主・インフラ・依存・戦略・ウェーブ」の6項目で変わりません。
CHECK 2ここまでの確認
最初のウェーブに入れるアプリとして、規範ガイダンスの考え方に合うのはどれ?
答えと解説
答え: 1. 依存が少なく、失敗しても影響の小さいアプリ
最初は低リスク・低複雑さのアプリをパイロットにし、手順と体制を固めてから重いものに進みます。「移行の順番（ウェーブ）はどう組むのか」を読み直してください。
MGN・DMS・DataSync はどう使い分けるのか
道具は「何を運ぶか」で分かれます。サーバーをまるごと運ぶのか、データベースの中身を運ぶのか、ファイルを運ぶのかです。
| 運ぶもの | 主な道具 | 何をしてくれるか | 設計で決めること |
|---|---|---|---|
| サーバー（リホスト） | AWS Transform MGN（旧 AWS Application Migration Service） | ブロックレベルで継続的に複製し、EC2 で起動できる形に変換する。テスト起動を経てカットオーバーする | 複製の経路（プライベート IP で専用線経由にするか）、テスト起動の範囲、切替の時間帯 |
| データベース（同じエンジン） | AWS DMS | 全ロードのあと CDC（変更データキャプチャ）で変更を追いかける | 差分が追いついたと判断する基準、切替の手順 |
| データベース（違うエンジン） | AWS SCT または DMS Schema Conversion ＋ AWS DMS | スキーマとストアドプロシージャなどのコードを変換し、変換できない部分を示す。データは DMS が運ぶ | 変換できないコードの書き直しの工数、アプリ側の SQL の修正 |
| ファイル（NFS・SMB など） | AWS DataSync | エージェントを介して S3・EFS・FSx などへ転送し、差分だけを送り、整合性を検証する | スケジュール、帯域の上限、最終同期のタイミング |
AWS Application Migration Service は 2026年6月に AWS Transform MGN へ改称されました。公式によれば API と複製の仕組みは変わっていません。練習問題や過去の資料では旧名で出てくるので、両方の名前で読めるようにしておきます。
DMS の CDC は、データベースのログから変更を読み取って移行先へ反映します。ただし公式ドキュメントは、CDC はリアルタイムの複製ではなく、遅延は移行元の負荷や回線、複製インスタンスの性能によって変わると明記しています。「差分がゼロになる瞬間」を待つのではなく、遅延が許容範囲に収まったことを確かめてから書き込みを止める、という設計にします。
READ ALSO — 学習中向け・段2 構成
Amazon RDS とは何か｜マネージドの範囲と、EC2 に DB を置く場合との責任の違い
データ量と回線から転送手段を決める
転送にかかる日数は、データ量を回線の実効帯域で割れば見積もれます。たとえば 100 TB を 1 Gbps の回線で送ると、帯域を使い切っても約80万秒、およそ9日強かかります。実際には業務の通信と帯域を分け合うので、使ってよい割合が半分ならその倍です。
- 日数が期間に収まる → DataSync で初回の転送を前倒しし、以後は差分だけを定期的に送る。公式によれば1つの DataSync タスクで 10 Gbps の回線を使い切れる設計です。
- 日数が期間に収まらない → 回線の増強（Direct Connect の追加など）を計画の最初に入れる。データの一部をリタイアやアーカイブに回して総量を減らす。
- 物理デバイスでの輸送 → AWS Snowball Edge は 2025年11月7日から新規の顧客に提供されておらず、公式は代替に DataSync などのオンライン転送を挙げています。新しい計画では前提にしません。
CHECK 3ここまでの確認
エンジンの違うデータベースへ移すとき、スキーマやストアドプロシージャの変換を受け持つのはどれ?
答えと解説
答え: 3. AWS SCT（または DMS Schema Conversion）
DMS はデータを運び、変更を追いかける道具で、コードの変換はしません。異種エンジンではスキーマとコードの変換を先に済ませます。「MGN・DMS・DataSync はどう使い分けるのか」を読み直してください。
カットオーバーはどう設計するのか
カットオーバー（本番の切り替え）の設計は、「停止できる時間」から逆算します。数分しか止められないなら、継続的な複製（MGN、DMS の CDC、DataSync の差分）で移行先を追いつかせておき、最後の短い停止で書き込みを止め、最終同期をして接続先を切り替えます。週末に数時間止められるなら、ダンプと戻しのような単純な方法も候補に入り、仕組みが少ないぶん失敗の箇所も減ります。
CUTOVER PLAN切り替えの4段階
停止を短くするのは複製、戻れるようにするのは期限と判断者
-
複製
継続的な複製と同期 — MGN・DMS の CDC・DataSync の差分
移行先を移行元に追いつかせておく
-
検証
テスト起動 — 複製を止めずに移行先で起動して確かめる
依存先・名前解決・証明書・バッチ・監視
-
切替
書き込みを止め、最終同期をして接続先を切り替える
止まる時間はここだけ。リハーサルで測る
-
見守り
切り戻しの手段・期限・判断者を決めて見守る
期限を過ぎるほど戻すときに失うものが増える
テスト起動を切り替えと分ける
MGN では、複製を止めずにテスト用のインスタンスを起動して検証し、問題がなければ改めてカットオーバー用のインスタンスを起動します。検証で見るのは、起動するかだけではありません。依存先に届くか、名前解決と証明書が合うか、バッチが時刻どおりに動くか、監視に載るか。ウェーブのパイロットで見つかった確認項目を、ランブックに足していきます。
切り戻しの手段と期限を先に決める
規範ガイダンスは、ウェーブの中で切り替えの計画と並べて「切り戻しの計画」を磨くことを求めています。書いておくのは次の3つです。
- 手段 — 移行元をいつまで止めずに残すか。切り替え後の書き込みを移行元へ戻す手段を用意するか。
- 期限 — 切り替え後、何時間・何日までなら戻すか。移行先で受けた書き込みが増えるほど、戻すときに失うものと手間が増えます。
- 判断者 — 誰が、どの指標を見て戻すと決めるか。その場で合議しない。
並行稼働（新旧を同時に動かして結果を突き合わせる）は安心ですが、二重の費用と二重の運用がかかります。体制と予算の軸で、どのアプリに並行稼働を許すかを決めます。切り戻しは災害復旧と同じく「戻す手順を試したか」で効き目が決まるので、復旧の設計と合わせて考えると抜けが減ります。
READ ALSO — プロフェッショナル向け・段4 設計
災害対策（DR）の設計｜RTO と RPO から4つの方式を選び、訓練で確かめる
CHECK 4ここまでの確認
カットオーバーの計画に「切り戻しの期限」を書いておく理由として正しいのはどれ?
答えと解説
答え: 1. 期限を過ぎると移行先の書き込みが増え、戻すときに失うデータが増えるから
切り替えた後に移行先で受けた書き込みは、移行元には無いものです。時間がたつほど戻す費用が上がるので、戻せる時間と判断者を先に決めます。「カットオーバーはどう設計するのか」を読み直してください。
要件が変わると答えはどう変わるか
ここまでの判断を、要件ごとに並べ直します。同じ会社の同じアプリでも、条件が1つ変わると答えが変わります。
| 要件の変化 | 戦略への影響 | 道具と手順への影響 |
|---|---|---|
| 期限が短い（数か月） | リホスト中心。作り直しは移行後に回す | MGN の継続的な複製で台数を運ぶ。ウェーブを並行させる |
| 期限に余裕がある | リプラットフォーム・リファクタを混ぜられる | DB は SCT と DMS で異種エンジンへ。作り直しと移行を一度に |
| 停止は数分まで | 変更の少ない戦略を選び、切り替えの操作を最小にする | 継続的な複製＋最終同期。切り戻しの期限を短く決める |
| 週末に数時間止められる | 戦略の自由度が上がる | ダンプと戻しなど単純な方法も候補。リハーサルで時間を測る |
| データが多く回線が細い | アーカイブ・リタイアで総量を減らす | 回線の増強を先に。DataSync の初回転送を前倒し |
| 体制が薄い・予算が小さい | マネージドへの置き換え（リプラットフォーム）や SaaS（リパーチェス）で運用を減らす | 並行稼働の期間を短くし、パイロットで手順を固めてから広げる |
移行後は何から最適化するのか
移した直後の構成は、オンプレミスのサイズをそのまま写した「大きめ」の状態であることが多いです。移行後の最適化は、次の順が安全です。
- 見えるようにする — 監視とコストの内訳（タグ・アカウント）を先に整える。測れないものは直せません。
- 適正サイズにする — 使用状況がたまってから、AWS Compute Optimizer の推奨などでサイズを見直す。
- 使い方が落ち着いてから契約で下げる — Savings Plans などのコミットは、サイズを直したあとの安定した量に対して買う。先に買うと、大きめの構成を固定してしまいます。
- 置き換える・作り直す — リプラットフォームやリファクタを、事業の差になるアプリから順に。
移行は「運び終えたら終わり」ではなく、運び終えた時点が最適化の出発点です。判断の軸をアプリごとに台帳へ残しておくと、移行後に何を直すかの順番もそこから引けます。
参照ソース
- About the migration strategies（AWS Prescriptive Guidance） — 7R の名前と定義、大規模移行でよく使う戦略（2026年9月時点の記載）
- Phases of a large migration（AWS Prescriptive Guidance） — 評価・準備・移行とモダナイズの3段階、「まず移してからモダナイズ」の順（2026年9月時点）
- Wave planning（AWS Prescriptive Guidance） — ウェーブ計画に要る4つの情報、パイロットの選び方、ウェーブの期間の目安、切り戻しの計画（2026年9月時点）
- What Is AWS Transform MGN?（AWS ドキュメント） — ブロックレベルの継続的な複製、テスト起動とカットオーバー（2026年9月時点）
- AWS Application Migration Service is now AWS Transform MGN（What’s New） — 改称と、API・機能が変わらないこと（2026年6月の発表）
- Creating tasks for ongoing replication using AWS DMS（AWS DMS ユーザーガイド） — 全ロード＋CDC の仕組み、CDC の遅延が条件で変わること（2026年9月時点）
- What is the AWS Schema Conversion Tool?（AWS SCT ユーザーガイド） — 異種エンジンへのスキーマとコードの変換（2026年9月時点）
- What is AWS DataSync?（AWS DataSync ユーザーガイド） — ファイル転送の対象と、差分転送・検証（2026年9月時点）
- AWS Snowball Edge availability change（AWS ドキュメント） — 2025年11月7日から新規の顧客に提供しないこと、代替の DataSync と1タスクで 10 Gbps を使い切れる設計（2026年9月時点）
- AWS Migration Hub availability change（AWS ドキュメント） — 2025年11月7日から新規の顧客を受け付けないこと、後継の AWS Transform（2026年9月時点）
- AWS Application Discovery Service availability change（AWS ドキュメント） — 2025年11月7日から新規の顧客を受け付けないこと（2026年9月時点）
