オンプレミスのデータベースをクラウドへ移行する際、最初につまずくのが「今の資産は何で、どれくらい大変か」を把握する工程です。この工程を担っていたAWSの無料ツール「DMS Fleet Advisor」が2026年5月20日にサポート終了となりました。移行計画をこれから立てるインフラ担当者やSREにとって、代替手段の選び方を整理しておく価値があるはずです。
DMS Fleet Advisorは、DMS（Database Migration Service、AWSが提供するデータベース移行サービス）の一部として、移行対象のDB資産を棚卸しし、移行の難易度を評価する機能でした。無料でフルマネージドという条件が揃っていながら、AWSの公式アナウンスは「慎重に検討した結果、サポートを終了することにした」という一文だけで理由を明かしていません。ただしドキュメントを読めば理由は見えてきます。
なぜ無料の公式ツールが使われなくなったのか
Fleet Advisorを使うには、事前準備が何段階も必要でした。専用のデータコレクター（収集エージェント）をローカル環境にインストールし、Amazon S3バケットを用意し、CloudFormation経由でIAM（AWSのアクセス権限管理機能）のポリシー・ロール・ユーザーを作成します。
さらに各DBサーバーに最小権限のDBユーザーを作り、コレクターからDBへのネットワーク経路も確保しなければなりません。ここまでやっても、一度に評価できるのは最大100データベースまで、対象と移行先のマッピングは1対1のみという制約が残ります。
銀行のような規制の厳しい現場を想像すると、この負担の大きさが分かります。移行の承認を得るための調査をしたいのに、その調査を始めるために本番DBの認証情報申請、エージェントのソフトウェア審査、S3バケットの払い出し、IAM構成のセキュリティレビューが必要になります。承認を取るための調査に、数週間の社内調整が発生する構図です。
この結果、多くの現場で実際に使われていた「代替手段」は、SSMS（SQL Server Management Studio）でストアドプロシージャを開き、人力で読むという方法でした。手作業は遅くミスも起きやすい方法ですが、承認もエージェントも認証情報も要りません。ゼロコンフィグの人力作業が、フルマネージドの公式ツールに競り勝ったことになります。
この構図から得られる教訓はシンプルです。開発者向けツールは機能の豊富さで比較されがちですが、実際の競合相手は他社ツールではなく「面倒なので手作業で済ませる人」であるケースが少なくありません。導入までの摩擦（アプローチのしにくさ）が大きいツールは、機能で勝っていても選ばれない可能性があります。
判断軸を整理する
DB移行アセスメントの手段を選ぶ際、次の4つの軸で比較すると判断しやすくなります。
- 本番アクセス権限の要否: ライブDB接続が必要か、静的ファイル（SQLファイルなど）だけで完結するか
- 事前準備コスト: エージェント導入・IAM設定・ネットワーク疎通にどれだけ時間がかかるか
- 評価対象の規模上限: 数百〜数千のプロシージャ・テーブルを一度に扱えるか
- 運用中の継続コスト: 移行後も定期的に資産棚卸しを続ける前提か、一度きりの調査か
特に金融・医療など規制業界では、本番DBへの接続許可自体が数週間がかりの社内プロセスになりがちです。この場合、最初の軸である「本番アクセス権限の要否」が選定の決め手になります。
選択肢の比較
移行アセスメント関連のツールは、実はそれぞれ「答える質問」が異なります。混同しやすいので整理します。
| ツール | 最初に必要なもの | 答える質問 |
|---|---|---|
| AWS SCT（Schema Conversion Tool） | ライブDB接続 + AWSアカウント | Auroraへの変換は可能か |
| DMS Fleet Advisor | コレクター、S3、IAM、DB認証情報 | 資産全体に何があるか（2026年5月に終了） |
| 商用データリネージツール | 商用ライセンス | データはどこへ流れているか |
| 静的SQL解析ツール（OSS） | SQLファイル一式のみ | 移行対象がどこに触れているか |
AWS SCTは無料でスキーマ変換に強いツールなので、コード変換の可否を知りたい段階ではそのまま使う価値があります。ただし「本番接続が前提」という点はFleet Advisorと共通の弱点です。
静的解析ツールは、Gitリポジトリにある.sqlファイルを読み込むだけで、物理テーブル・スキーマ・カラム・CRUD操作（Create/Read/Update/Deleteの略、データ操作の基本4種）をプロシージャ単位で洗い出せます。DB接続もエージェントも不要という設計上の制約が、逆に導入障壁を下げています。
ケース別の推奨
本番DBへの接続許可がまだ下りていない、かつ承認プロセスに数週間かかる組織なら、静的解析ツールでコードベースの棚卸しから始めるのが現実的です。SQLファイルさえ手元にあれば、ブラウザ上で数十秒程度で依存関係の全体像が見えます。
すでに本番接続許可があり、変換先エンジン（AuroraやRDSなど）を具体的に検討している段階なら、AWS SCTでスキーマ変換の可否を直接確認するのが早道です。静的解析はあくまで着手前の見取り図であり、変換作業そのものを代替しません。
移行規模が数百データベース以上、かつ継続的な棚卸しが必要な大企業のプラットフォームチームなら、AWSのコンサルティング型サービス「Migration Evaluator」の利用も選択肢に入ります。Fleet Advisorの後継としてAWSが案内している手段で、人手を介した評価が前提になります。
あえて見送るべき条件
静的解析だけで移行判断の全てを決めるのは避けたほうがよい場面もあります。動的SQL（実行時に文字列組み立てで生成されるクエリ)を多用しているシステムでは、静的解析がカバーしきれない依存関係が残ります。
また、DBサーバー側の実行計画やパフォーマンス特性を含めた評価が必須な移行では、静的解析だけでは判断材料が不足します。この場合はライブ接続を伴うツールとの併用、または段階的な承認取得を検討したほうが確実です。
コンサルティング型のMigration Evaluatorも、数千万円規模の移行費用が発生する大規模案件では投資対効果が見合いますが、小規模なDB群の棚卸しに使うにはオーバースペックになりがちです。規模に見合わない選択は、運用コストの観点からも見送るべき判断です。
まとめ
Fleet Advisor終了の経緯から見えるのは、機能の豊富さよりも「着手までの摩擦」がツール選定を左右する現実です。
移行アセスメントを検討する際は、まず自分の組織で本番DB接続の承認にどれくらい時間がかかるかを確認してください。数週間かかるなら、静的解析ツールでコードベースからの棚卸しを先に試すのが現実的な一歩になります。
接続許可がすでにあり変換先を具体化する段階なら、AWS SCTで変換可否の確認に進めます。規模や継続性の要件次第では、Migration Evaluatorのようなコンサルティング型サービスも比較検討の対象に加えておくと、判断の抜け漏れを防げます。