「オンプレミスのデータベースをクラウドに移行したいが、AWS・Azure・Google Cloudで何が違うのか分からない」「各クラウドのネイティブ移行ツールで十分なのか、それとも別途ツールが必要なのか判断できない」——クラウド移行の担当者からよく聞かれる悩みです。
クラウドDB移行は、移行先のクラウドによって使えるツール・移行パターン・注意点が大きく異なります。また、同じクラウドでも、移行元のDBの種類や規模によって最適なアプローチは変わります。
本記事では、AWS・Azure・Google CloudそれぞれのDB移行パターンを比較しながら、ネイティブツールが向いているケース・向いていないケースを整理します。「どのクラウドにどう移行するか」の判断材料として活用してください。
この記事で分かること
- クラウドDB移行の基本的な考え方（Lift & Shift / Re-platform / Re-architectureの違い）
- AWS・Azure・Google Cloudそれぞれのネイティブ移行ツールの特徴と限界
- ネイティブツールでは対応しにくいケースとその選択肢
- 自社環境に合ったクラウド・ツールの選び方
1. クラウドDB移行の基本的な考え方
移行アプローチの3パターン
クラウドDB移行には、大きく3つのアプローチがあります。自社の状況や目的に応じて、どのパターンを選ぶかが最初の判断となります。
Lift & Shift（リフト＆シフト）
オンプレミスで動いているDBをそのままクラウドに持ち上げる方法です。既存の構成を大きく変えないため、移行リスクが低く短期間で実施できます。ただし、クラウドのメリット（コスト最適化・スケーラビリティ）を最大限に活かしにくい面もあります。
Re-platform（リプラットフォーム）
移行の機会に、DBエンジンをクラウド最適化されたマネージドサービスに切り替えるアプローチです。例えば、オンプレのOracleをAmazon RDS for Oracleに移行しつつ、運用管理をAWSに委ねる形です。Lift & Shiftよりも効果が高い反面、互換性の確認が必要です。
Re-architecture（リアーキテクチャ）
クラウドネイティブなDBに移行する、最も変化が大きいアプローチです。例えば、OracleからAurora PostgreSQLへの移行がこれにあたります。長期的なコスト削減・パフォーマンス向上が期待できますが、アプリケーションの改修を伴うケースも多く、移行コストは最も高くなります。
同種DB移行と異種DB移行の違い
移行の複雑さを左右するもう一つの要素が、移行元と移行先のDBエンジンが同じか異なるかです。
同種DB移行（例：Oracle → RDS for Oracle）は、スキーマやSQL構文の互換性が高く、移行ツールの選択肢も多いため、比較的スムーズに進められます。
異種DB移行（例：Oracle → Aurora PostgreSQL）は、SQL構文・データ型・ストアドプロシージャの非互換部分が発生するため、事前のアセスメントと変換作業が必要です。ダウンタイムを最小化するためにはCDC対応のツールが必要となるケースがほとんどです。
異種DB移行の詳細については「異種データベース移行の課題とは？Oracle→PostgreSQL、SQL Server→Redshift移行を成功させる方法」で詳しく解説しています。
2. AWS（RDS / Redshift）への移行パターン
AWSのDB移行に使えるネイティブツール
AWS DMS（Database Migration Service）は、AWSが提供するデータベース移行サービスです。マネージドサービスとして提供されており、サーバーの構築・管理が不要で手軽に利用できます。
- 対応ソース：Oracle / SQL Server / PostgreSQL / MySQL / MariaDB / MongoDB 等
- 対応ターゲット：RDS各種 / Aurora / Redshift / S3 等
- CDCによる継続的なレプリケーションにも対応
主な移行パターン
RDS for Oracle：オンプレミスのOracleからAmazon RDS for Oracleへの同種移行。Oracleライセンスを持ち込む（BYOL）か、RDSのライセンス込みプランを選択できます。HA構成にはMulti-AZが利用可能です。
RDS for PostgreSQL / Aurora PostgreSQL：Oracle / SQL ServerからPostgreSQLへの異種移行先として最も選ばれるターゲットの一つです。オープンソースのため追加ライセンスが不要で、コスト削減を目的とした移行案件で多く採用されています。
RDS for MySQL / Aurora MySQL：既存のMySQLやPostgreSQL環境からのリフト＆シフト先として定番。Aurora MySQLはMySQLの最大5倍のパフォーマンスを謳うマネージドサービスです。
RDS for SQL Server：オンプレミスSQL ServerからRDS for SQL Serverへの移行。Windows認証やSSRS等の機能要件がある場合は制限事項の確認が必要です。
Redshift：オンプレミスのRDBMSデータをRedshiftに連携してDWH・分析基盤を構築するパターン。バッチ連携のほか、CDCを使ったリアルタイム連携も可能です。
AWS DMSが向いているケース
- AWSへの移行に特化した、比較的シンプルな移行プロジェクト
- 小〜中規模のデータ量で、移行期間が短いケース
- 移行元・移行先ともにAWS DMSの対応DBリストに含まれているケース
- AWS公認のマネージドサービスを使ってコストを抑えたいケース
AWS DMSでは対応しにくいケース
- 大規模なエンタープライズ環境で、高精度のCDCが求められるケース（AWS DMSのCDC精度に限界がある場合がある）
- メインフレーム・SAP・AS/400など、特殊なソースからの移行
- マルチクラウド構成（移行先がAzureやGCPに分散しているケース）
- 移行後もオンプレミスとの継続的なハイブリッド連携が必要なケース
Redshiftへのデータ連携
RDBMSのデータをRedshiftに連携してデータ分析基盤を構築する場合、AWS DMSに加えて、AWS Glueなどのデータ変換サービスとの組み合わせが一般的です。ただし、本番DBのデータをリアルタイムに近い形でRedshiftに連携したい場合は、CDCに特化したレプリケーションツールの方が効率的です。
3. Azure（SQL Database / Synapse Analytics）への移行パターン
Azureのネイティブ移行ツール
Azure Database Migration Service（DMS）は、AzureへのDB移行を支援するマネージドサービスです。特にSQL Server環境との親和性が高く、オンプレミスSQL ServerからAzure SQL Databaseへの移行実績が豊富です。
- 対応ソース：SQL Server / Oracle / MySQL / PostgreSQL / MongoDB 等
- 対応ターゲット：Azure SQL Database / Azure SQL Managed Instance / Azure Database for PostgreSQL等
- オンライン移行（ダウンタイム最小化）とオフライン移行（一括移行）の両方に対応
主な移行パターン
Azure SQL Database：オンプレミスSQL ServerからのRe-platform先として最も一般的なターゲットです。サーバーレスのフルマネージドサービスで、パッチ適用・バックアップ・HA構成をAzureが管理します。ただし、SQL Server Agentなど一部機能は非対応のため、事前の互換性確認が必要です。
Azure SQL Managed Instance：SQL Serverとの高い互換性を保ちながらクラウド化したい場合の選択肢です。SQL Server AgentやCLR、リンクサーバーなど、Azure SQL Databaseでは使えない機能を多数サポートしています。オンプレミスSQL Serverからの移行で「ほぼそのまま動かしたい」というニーズに適しています。
Azure Database for PostgreSQL / MySQL：オープンソースDBのマネージドサービスです。オンプレミスのPostgreSQL / MySQLからの移行先として、またOracleやSQL Serverからの異種移行先としても採用されます。
Azure Synapse Analytics：大規模データ分析基盤の構築を目的とした移行先です。RDBMSからのデータ連携にはAzure Data FactoryやCDCツールとの組み合わせが一般的です。
Azure DMSが向いているケース
- SQL Server中心の環境からAzure SQL Databaseへの移行
- Microsoft製品で統一されたシステム環境のクラウド化
- Azure Active Directory連携など、Microsoft製品との統合を重視するケース
Azure DMSでは対応しにくいケース
- Oracle → Azure SQL Databaseなど、異種DB間の移行（SQL構文の変換が発生）
- 大規模エンタープライズ環境での高精度CDCが必要なケース
- AWSやGCPとのマルチクラウド構成
Azure Synapse Analyticsへのデータ連携
分析基盤としてAzure Synapse Analyticsを活用する場合、オンプレミスのRDBMSからのリアルタイムデータ連携にはCDC対応ツールが有効です。Azure Data Factoryと組み合わせることで、ETLパイプラインを構築するアプローチも一般的です。
4. Google Cloud（Cloud SQL / BigQuery）への移行パターン
Google Cloudのネイティブ移行ツール
Database Migration Service（Google Cloud版）は、Google Cloudが提供するマネージドな移行サービスです。特にPostgreSQL・MySQL・SQL Serverとの親和性が高く、Cloud SQLへの移行をサポートします。
- 対応ソース：PostgreSQL / MySQL / SQL Server（Oracle対応は限定的）
- 対応ターゲット：Cloud SQL for PostgreSQL / MySQL / SQL Server
- 継続的なCDCレプリケーションにも対応
主な移行パターン
Cloud SQL for PostgreSQL：オンプレミスPostgreSQLからのリフト＆シフト先として最も自然な選択肢です。またOracleからの異種移行先としても採用が増えています。Cloud SQLはフルマネージドで、バックアップ・HA・レプリカをGoogle Cloudが管理します。
Cloud SQL for MySQL：既存のMySQLをそのままGoogle Cloudに移行したい場合の定番ターゲットです。Cloud SQL for MySQLはMySQLとの高い互換性を持ち、移行時の改修コストを最小化できます。
Cloud SQL for SQL Server：SQL Server環境をGoogle Cloudに移行するための選択肢です。Windows認証やActive Directory連携など一部機能に制限があるため、要件の事前確認が必要です。
BigQuery：データ分析・BIを目的とした大規模データ基盤の構築先です。サーバーレスで従量課金のため、分析ワークロードのコスト最適化が図れます。オンプレミスRDBMSからのリアルタイム連携にはCDCツールの活用が有効です。
Google Cloud DMSが向いているケース
- PostgreSQL / MySQL中心の環境からCloud SQLへの移行
- Google CloudのエコシステムとBigQueryを活用した分析基盤構築
- 比較的新しいシステムで、既存のDB構成がシンプルなケース
Google Cloud DMSでは対応しにくいケース
- OracleからCloud SQL / BigQueryへの移行（Google Cloud DMSのOracle対応が限定的）
- メインフレーム・SAP等の特殊ソースからの移行
- マルチクラウド構成
BigQueryへのリアルタイムデータ連携
BigQueryはデータ分析に特化したサーバーレスのデータウェアハウスです。オンプレミスのRDBMSからBigQueryにリアルタイムでデータを連携する場合、Google Cloud DMSよりもCDC対応のレプリケーションツールを利用した方が、データ鮮度・処理効率の面で優れているケースがほとんどです。
5. AWS・Azure・Google Cloudのネイティブツール比較
AWS・Azure・Google Cloudのネイティブ移行ツールを主要な観点で比較します。
| 比較項目 | AWS DMS | Azure DMS | Google Cloud DMS |
| 得意なソースDB | 幅広く対応 | SQL Server中心 | PostgreSQL / MySQL中心 |
| Oracle対応 | ○ | △（制限あり） | △（限定的） |
| CDCによる継続同期 | ○ | ○ | ○ |
| マルチクラウド対応 | × | × | × |
| 特殊ソース対応（メインフレーム・SAP等） | × | × | × |
| エンタープライズCDC精度 | △ | △ | △ |
| コスト感 | 低〜中 | 低〜中 | 低〜中 |
比較表からも分かる通り、各クラウドのネイティブツールはそれぞれのクラウドへの移行に特化しており、マルチクラウド構成や特殊なソースDB、エンタープライズ規模の高精度CDCが求められるケースでは限界があります。
6. ネイティブツールでは対応しにくいケースの選択肢
前章で整理した通り、各クラウドのネイティブツールだけでは対応が難しいケースがあります。具体的には以下のような状況です。
- マルチクラウド・異種DB間の移行（AWS→AzureやOracle→Aurora PostgreSQLなど）
- エンタープライズ規模の大量データ・高精度CDC要件
- メインフレーム・AS/400・SAPなど特殊なソースからの移行
- 移行後もオンプレミスとの継続的なハイブリッド連携が必要な場合
こうしたケースでは、クラウドを問わず幅広いDB・環境に対応した専用のレプリケーションツールを検討することになります。代表的なツールとしては、Qlik Replicate / Oracle GoldenGate / AWS DMSのエンタープライズ版などが挙げられます。
各ツールの詳細な比較・選定方法については、「CDC（Change Data Capture）とは？DB移行・クラウド移行でダウンタイムを最小化する技術」で詳しく解説しています。
まとめ
クラウドDB移行のアプローチと、各クラウドのネイティブツールの特徴を整理しました。
- 移行アプローチはLift & Shift / Re-platform / Re-architectureの3パターン。自社の目的・リスク許容度で選択する
- AWS DMSはOracle含む幅広いDBに対応、Azure DMSはSQL Server環境に強み、Google Cloud DMSはPostgreSQL / MySQL中心
- いずれのネイティブツールもマルチクラウド・特殊ソース・高精度CDCには対応が難しい
- 異種DB移行・エンタープライズ規模・マルチクラウド構成の場合は、専用レプリケーションツールの検討が必要
インサイトテクノロジーでは、AWS・Azure・Google Cloudを問わずクラウドDB移行を支援しています。「自社環境に最適な移行パターンを確認したい」「ネイティブツールで対応できるか相談したい」という方は、お気軽にご相談ください。
▼ Qlik Replicateの資料をダウンロード
https://www.insight-tec.com/download/document_0006
▼ Qlikが実現できるDB移行について詳しく見る
https://www.insight-tec.com/products/qlik-data-integration-platform
▼ DB移行の悩みをまず相談する
https://www.insight-tec.com/products/qlik-data-integration-platform/#f
