AWS Application Migration Service

概要

(MGN)は、や他クラウドのサーバーをほぼそのままAWSへ移行するリフト&シフト(リホスト)向けのサービスです。アプリケーションを改修せずにへ移すため、最小限のダウンタイムで大量のサーバーを移行できます。

2026年6月に、名前が AWS Transform MGN に変わりました。機能は同じで、試験ガイドでは AWS Application Migration Service の名前で載っています。

移行元サーバーにエージェントを導入し、ディスクをブロックレベルでAWSへ継続的に複製します。移行元は稼働したまま移行準備を進められます。

本番切り替えの前にテスト用インスタンスを起動して動作確認し、準備が整ったら短いダウンタイムで切り替え(カットオーバー)します。

まず変更なしで移行し、その後にリプラットフォームやリファクタリングへ進む、移行の第一歩として位置付けられます。

AWS は、アプリケーションごとに選ぶ移行の方針を7つの戦略（7R）に整理しています。が自動化するのは、このうちリホストです。

戦略	中身	判断ポイント
リタイア（Retire）	移行せずに廃止・します。	使われていない、業務上の価値がないシステムです。
リテイン（Retain）	移行せず、当面は今の環境に残します。	規制、依存関係、専用ハードウェアなどの理由で、まだ移せません。いずれ移す前提です。
リホスト（Rehost）	アプリケーションを変えずに AWS へ移します（リフト&シフト）。	物理・仮想・他クラウドのサーバーを、期限までに大量に移します。
リロケート（Relocate）	の仮想化基盤を、そのクラウド版へまとめて移します。	新しいハードウェアの購入、アプリケーションの書き直し、運用の変更が要りません。アーキテクチャに影響しないため、最も速く移せる戦略です。
リパーチェス（Repurchase）	など別の製品に買い替えます。	自社で運用してきたシステムを、同等の製品の利用契約へ切り替えます。
リプラットフォーム（Replatform）	移すときに一部を最適化します。	アプリケーションの作りは保ったまま、DB をへ置き換えるなどします。
リファクタリング（Refactor / Re-architect）	クラウドネイティブな機能を活かすように作り変えます。	拡張性や開発の速さへの強い要求があります。7Rで最も複雑で費用がかかります。

大規模な移行では、移行中のリファクタリングは勧められていません。まずリホスト、リロケート、リプラットフォームで移し、移行が終わってからモダナイズします。

「サーバーを変更せずにAWSへ移行」「リフト&シフト」「リホスト」というキーワードでを選びます。

サーバー全体(ごと)の移行は、データベースのデータ移行はです。