
RiverMeadowを使ってAWSに移行してみた 〜OSベース編〜
クラスメソッドテクノロジーズの佐沢です。
オンプレミス環境からAWSへ仮想マシンを移行する手段として、多くの方がAWS Transform MGN(最近、名称が変わりました)やVM Import/Exportを使われているのではないでしょうか。
ただ、2025年から2026年現在においてサポート対象外になるOSもどんどん増えており、その影響によって移行計画を見直さないといけないこともあるかと思います。
今回は、AWS Transform MGNではサポートアウトしたレガシーOSにも幅広く対応している「RiverMeadow」を使ったAWS移行をやってみます。
RiverMeadowとは
RiverMeadowは、パブリッククラウドやプライベートクラウド、ハイブリッド環境間でのワークロード移行・モダン化・最適化を迅速に実現するサードパーティ製のSaaSツールです。
現時点で、RiverMeadowは幅広いプラットフォームを移行先としてサポートしているため、マルチクラウドやハイブリッド構成などを検討されている方でも、本ツール1つで移行ができるのは大きな利点です。
| サポートする移行先プラットフォーム |
|---|
| Amazon Web Services (AWS) |
| AWS Outposts Racks |
| Microsoft Azure |
| Google Cloud Platform (GCP) |
| Red Hat OpenShift Virtualization |
| Azure Red Hat OpenShift (ARO) |
| HPE Morpheus VM Essentials |
| Nutanix AHV |
| Nutanix Cloud Clusters (NC2) on AWS |
| Nutanix Cloud Clusters (NC2) on Azure |
| VMware vSphere |
| Azure VMware Solution (AVS) |
| Google Cloud VMware Engine (GCVE) |
| VMC on AWS |
| Amazon Elastic VMware Service (Amazon EVS) |
移行方式
RiverMeadowで提供される移行方式は2つに分かれます。
- VMベース(エージェントレス)
- OSベース(エージェントあり)
となっており、呼称は異なるもののAWS Transform MGNと同じような移行方式があります。
それぞれでサポートされる移行元環境や機能は大きく異なります。
| 機能 | VMベース(エージェントレス) | OSベース(エージェントあり) |
|---|---|---|
| サポート対象の移行元 | VMware vSphere(6.0 以降) | 物理または仮想環境 |
| サポート対象のOS | VMware vSphereがサポートするゲストOS | Windows および Linux(x86 および ARM) |
| OSのモダン化 | 不可 | 可能 |
| コンピュート・リサイジング | 可能 | 可能 |
| ストレージ・リサイジング | 不可 | 可能 |
RiverMeadowの2つの移行方式における大きな違いは、VMベースの場合はAWS Transform MGNと同様にvSphere環境に限定されていることです。
ただ、AWS Transform MGNのエージェントレス移行はvCenter ClientがvCenter Serverのバージョン6.7、7.0、8.0のみサポートされるため、その分RiverMeadowの方が対応可能なバージョンは多いです。
AWS Transform MGNでの移行を考えた時に、システム要件等で仮想マシンにMGNのエージェントを入れられないためエージェントレスにしようと思いつつ、vCenter Serverのバージョン満たせないという時にも使えそうです。
2026年6月時点でRiverMeadowにおいてOSベースでサポートするOSは以下の通りです。
| カテゴリ | バージョン |
|---|---|
| Windows Client※ | 7 / 8 / 10 / 11 |
| Windows Server※ | 2008 R2 / 2012 / R2 / 2016 / 2019 / 2022 / 2025 |
| Amazon Linux | Amazon Linux 2 / Amazon Linux 2023 |
| Azure Linux | 3.0 |
| CentOS | 6 / 7 / 8 / Stream |
| Debian | 9 / 10 / 11 / 12 |
| Oracle Enterprise Linux | 6 / 7 / 8 / 9 |
| Red Hat Enterprise Linux | 6 / 7 / 8 / 9 / Fedora |
| SUSE | 11 / 12 / 15 |
| openSUSE | 11 / 12 / 13 / 15 |
| Ubuntu | 14 / 16 / 18 / 20 / 22 / 24 |
| VMware Photon OS(64bit) | サポート対象 |
※Windows 7、8、2008 R2 は、最新の更新プログラムとパッチがすべて適用されている場合のみ
この一覧を見ても、AWS Transform MGNで今後サポートされなくなるOSもRiverMeadowでは対応可能なため、かなり有効そうです。
OSモダナイゼーション
移行のタイミングでOSのアップグレードを行いたいという方は少なくありません。
AWS Transform MGNの起動後アクションでは、Windows Serverの特定のバージョンでアップグレードを行うことができました。
RiverMeadowでは、OSベースにおいてさまざまなOS種別に対してアップグレードをサポートします。
Windows
| 移行元 OS バージョン | エディション | 移行先 OS バージョン(アップグレード先) |
|---|---|---|
| Windows Server 2008 R2 | Datacenter SP1 | 2012 R2 / 2016 / 2019 / 2022 / 2025(Datacenter) |
| Windows Server 2008 R2 | Enterprise SP1 | 2012 R2 / 2016 / 2019 / 2022 / 2025(Datacenter) |
| Windows Server 2008 R2 | Standard SP1 | 2012 R2 / 2016 / 2019 / 2022 / 2025(Standard) |
| Windows Server 2012 / R2 | Datacenter | 2016 / 2019 / 2022 / 2025(Datacenter) |
| Windows Server 2012 / R2 | Standard | 2016 / 2019 / 2022 / 2025(Standard) |
| Windows Server 2016 | Datacenter | 2019 / 2022 / 2025(Datacenter) |
| Windows Server 2016 | Standard | 2019 / 2022 / 2025(Standard) |
| Windows Server 2019 | Datacenter | 2022 / 2025(Datacenter) |
| Windows Server 2019 | Standard | 2022 / 2025(Standard) |
| Windows Server 2022 | Datacenter | 2025(Datacenter) |
| Windows Server 2022 | Standard | 2025(Standard) |
| Windows 7 Desktop(64bit) | Professional | Windows 10 / Windows 11(Pro) |
| Windows 7 Desktop(64bit) | Enterprise | Windows 10 / Windows 11(Enterprise) |
| Windows 8 Desktop(64bit) | Professional | Windows 10 / Windows 11(Pro) |
| Windows 8 Desktop(64bit) | Enterprise | Windows 10 / Windows 11(Enterprise) |
| Windows 10 Desktop | Professional | Windows 11 Pro |
| Windows 10 Desktop | Enterprise | Windows 11 Enterprise |
Linux
| 移行元 OS バージョン | 移行先 OS バージョン(アップグレード先) |
|---|---|
| RedHat Enterprise Linux 6.x | 7.9 / 8.10 / 9.5 |
| RedHat Enterprise Linux 7.x | 8.10 / 9.5 / 10.0 |
| RedHat Enterprise Linux 8.x | 9.5 / 10.0 |
| RedHat Enterprise Linux 9.x | 10.0 |
| CentOS 6.x | 7.9 / 8.10 |
| Oracle Enterprise Linux 6.x | 7.9 / 8.10 / 9.5 / 10.0 |
| Oracle Enterprise Linux 7.x | 8.10 / 9.5 / 10.0 |
| Oracle Enterprise Linux 8.x | 9.5 / 10.0 |
| Oracle Enterprise Linux 9.x | 10.0 |
| SUSE Linux Enterprise Server 11.x | 15 SP6 |
| SUSE Linux Enterprise Server 12.x | 15 SP6 |
| Ubuntu 14.04 / 16.04 / 18.04 / 20.04 / 22.04 | 24.04 LTS |
| Rocky Linux 8 | 9 |
やってみた
構成図
とりあえず、移行の動きを見てみたいので以下のような簡単な構成としています。
ソース環境:Hyper-V
ターゲット環境:AWS
移行元VM:Windows Server 2016(Datacenter)
ネットワーク:Hyper-V上のVyOSからAWS環境へSite-to-Site VPN接続

前提条件
OSベース(エージェントあり)において、移行元サーバー(Windows)の要件は以下の通りです。
| 要件 | 詳細 |
|---|---|
| WMI の有効化 | メタデータを収集するために使用 ※ VMベースの移行では WMI は使用されない |
| Power User | ソースマシン上で RiverMeadow Utility を展開できるだけの十分な権限が必要 |
| Volume Shadow Copy Service(VSS)の有効化 | RiverMeadow は Windows VSS 機能を使用 |
| ディスク容量 | 約1GBの空きディスク容量が必要 ※OSをモダナイズする場合、C: ドライブに 25GB の空き容量が必要 |
| メモリ容量 | 最低 2GB の RAM が必要 |
ネットワークの通信要件を表で示したものが以下になります。
| 通信元 | 通信先 | ポート |
|---|---|---|
| RMS 移行アプライアンス | RiverMeadow プラットフォーム (52.9.247.1, 52.9.142.11, 18.218.114.29, 3.143.57.56) |
メッセージバス: 443 |
| 移行先サーバー | RMS 移行アプライアンス | メッセージバス: 443 APIアクセス: 8888 |
| RMS 移行アプライアンス | 移行元サーバー | Windows: 445 (エージェントインストール - SMB) Windows: 5985 (エージェントインストール - WinRM) Windows: 5994 (プリインストール済みエージェント) Linux: 22 (エージェントインストール) Linux: 5994 (プリインストール済みエージェント) |
| 移行先サーバー | 移行元サーバー | データ転送: 5994 |
上記記載の通り、仮想アプライアンスはインターネットを経由してRiverMeadowのプラットフォームへ通信する必要があります。
AWS Transform MGNの場合はPrivateLinkを使って閉域ネットワーク内での通信で完結させられていてましたが、ネットワーク要件としてインターネットで出る必要があることが異なる点だと思います。
仮想アプライアンスのデプロイ
まずは、移行を実施するためにRMS仮想アプライアンスのデプロイが必要です。
管理コンソールからデプロイするための準備を行います。
[Migration Appliances] -> [Add New Migration Appliances] を選択します。

移行先の環境を選択する画面に遷移します。
今回は、[AWS] を選択します。

移行アプライアンスをデプロイするAWSアカウントの情報を入力していきます。

IAMロールは、RiverMeadowプラットフォームを使ってAWSへ移行するための権限であり、CloudFormationのテンプレートが用意されています。
今回は、[Download Template] からRiverMeadowが提供するテンプレートをダウンロードし、移行先のAWSアカウントでIAMロールを作成します。
※テンプレートを使ったIAMロールの作成手順は省略しますが、利用されるIAMポリシーは参考までに記載しておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress"
],
"Resource": "arn:aws:ec2:*:*:*",
"Effect": "Allow"
},
{
"Action": [
"iam:ListInstanceProfiles",
"ssm:GetParameter",
"servicequotas:ListServiceQuotas",
"mgh:CreateProgressUpdateStream",
"mgh:ImportMigrationTask",
"mgh:NotifyMigrationTaskState",
"mgh:PutResourceAttributes",
"mgh:AssociateDiscoveredResource",
"mgh:ListDiscoveredResources",
"mgh:AssociateCreatedArtifact",
"discovery:ListConfigurations"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSecurityGroups",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeHosts",
"ec2:DescribeImages",
"ec2:DescribeRegions",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeConversionTasks",
"ec2:DescribeVolumes",
"ec2:DescribeSnapshots",
"ec2:DescribeAddresses",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypeOfferings",
"ec2:DescribeInstanceTypes",
"ec2:CreateSecurityGroup",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:AttachVolume",
"ec2:DetachVolume",
"ec2:DeleteVolume",
"ec2:CreateImage",
"ec2:CreateSnapshot",
"ec2:DeleteSnapshot",
"ec2:DescribeSnapshots",
"ec2:GetConsoleScreenshot",
"ec2:MonitorInstances",
"ec2:GetConsoleOutput"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"kms:ListAliases",
"kms:DescribeKey"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"outposts:ListOutposts",
"outposts:GetOutpostInstanceTypes"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"fsx:DescribeFileSystems",
"fsx:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": [
"ec2:TerminateInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RunInstances"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": "iam:PassRole",
"Resource": "*",
"Effect": "Allow"
}
]
}
[Test connection]で事前にIAMロールのテストを行い、問題ないことが確認できれば [Add Migration Appliance] を選択します。
ここでのタグはRiverMeadowの管理コンソールで利用されるものであって、AWSリソースに付与されるタグのことではありません。複数の環境に移行を行う際に利用すると識別しやすそうですが、今回は単一環境への移行となるためタグは付与しません。

次にRiverMeadowの仮想アプライアンスのデプロイ先を選択します。
今回、移行先となるAWS環境の設定および仮想アプライアンスのEC2の設定値を入れる必要があります。
前述の通り、仮想アプライアンスはRiverMeadowのプラットフォームと通信が必要となるため、デプロイ先のサブネットからインターネットに通信ができるようにしてください。

また、設定のオプションには [Enable VM-based migrations]という項目がありますが、こちらはエージェントレス設定です。
今回はエージェントを利用するので、このままオプションは変更せず、[Initiate Migration Appliance checks]を選択します。

仮想アプライアンスのデプロイが開始されます。
[Appliance Deployment]が Deployed かつ [Appliance Readiness]のステータスに問題なければ、AWSコンソール上にEC2インスタンスとして作成されています。
AWS管理コンソール上に仮想アプライアンスが作成されますが、Security Groupも含め自動で生成されアタッチされます。
RiverMeadow管理コンソール

AWS管理コンソール

続いては、移行元サーバーを登録していきます。[Source Inventory] -> [Add Source] を選択します。

エージェントを事前にインストールする必要はありますが、オプション設定では登録と同時に移行元サーバーの資格情報を一緒に入れることで、仮想アプライアンス経由でエージェントを自動インストールしてくれます。
※Linuxで非rootユーザーを使用する場合は、パスワードなしのsudo権限が付与されている必要があります。
手動で入れる場合は、移行元サーバーから https://仮想アプライアンス:8888/agent へエージェントのインストーラーをダウンロードしてインストールを実施してください。
本手順では、移行元サーバー(Windows Server)の仮想マシンの資格情報を入れて自動でインストールを実施します。
デフォルトで [Source has preinstalled Agent] にチェックが入っていますが、チェックを外し、資格情報を入れます。その後、[OK] を選択します。

登録が完了すると、[Source Inventory] の一覧に出てきます。
先ほど登録した移行元サーバーを選択して [Actions] から [Inspect Source] を選択し、移行元サーバーとして問題ないかチェックします。

移行元サーバーに対する検査結果(OS情報や問題点などがあれば)が表示されます。
データ転送に関する警告が表示されますが、現状は無視しても問題ないのでこのまま移行を進めます。
• RiverMeadow requires the use of a transfer port {0}, which is currently in use by another process or service. You can provide an alternate port by following [url href='http://docs.rivermeadow.com/use-migration-instructions']these intructions[/url].
再度、[Actions]を選び[Inspect & Migrate]を選択します。
仮想マシンを丸ごと移行したいので、[Workload Migration]->[Check Migration Readiness]を選択します。

※他[File Migration]と[Block Migration]を選択でき、ファイル単位やディスク単位でデータ移行(EBSやストレージサービスに対して)可能です。
移行準備ができているか否かの詳細が表示されます。
ステータスで警告はでていますが、先ほどのポートに関する警告なので無視して[Create Migration Profile]を選択します。

そのまま移行プランの設定と移行後のEC2インスタンスに関する設定を選択する画面へ遷移します。
プラン名やタグはRiverMeadowの管理コンソールで利用されるため、識別しやすいようにしておきます。
移行計画に関する通知についても選択できますが、今回は利用しません。(移行完了などが通知される)
移行日程もスケジューリングできるようですが、今回は[now]を選択します。

その後、移行後の設定を個別にカスタマイズもしくはグローバル(全サーバー一律)の設定を選択することができます。
項目をみているとEBSのボリュームタイプなどの設定がなくグローバルで設定値として選べる内容は少ないので、細かな要件がある場合は個別にカスタマイズをしたほうが良さそうです。

今回は必要最低限のカスタマイズだけ行い、[Continue]を選択します。
警告が解消されずに進めようとしていることについて指摘されますが、無視して[Continue Anyway]を選び、[Start Migration]をクリックで移行が開始されます。



移行状況については、[View Migrations]から確認可能です。

移行が完了したらメール通知がきます。
RiverMeadowの管理コンソールでも[Complete]となっていれば完了です。


AWS管理コンソール上にも無事に作成されています!

移行後のEC2インスタンスに対してもRDP接続も問題なくでき、移行完了!

慣れてくると使いやすさがある
RiverMeadowの管理コンソール自体は、見た目は非常にシンプルです。
ただ、現状は英語のみをサポートしているため今後の日本語対応に期待したいところです。
設定項目については、RiverMeadowが提供する公式ドキュメントを確認しながら補完し設定することが多いため、ユーザーが直感的に要不要の設定値の判断ができると移行の作業効率はあがりそうです。
また、ネットワークの要件としてインターネット接続を要件とすることは、場合によっては移行手段として採用しづらいケースではあるものの、それでもこれだけのレガシーOSをサポートかつ移行可能であり、これほど多くのレガシーOSに対応し、移行元・移行先の選択肢が幅広い点は、それを差し引いてもかなり優秀だと思います。
この記事が、移行を検討されているどなたかの助けになれば幸いです。








