データベース エンジンは、データベース管理システム（DBMS）とも呼ばれ、基本的なデータベース運用やソフトウェア アプリケーションとのインターフェースを管理するソフトウェアです。

同種移行とは、移行元（ソース）のデータベースに、移行先（ターゲット）のデータベースと同一またはよく似たエンジンがあることを指します。異種移行とは、移行先のデータベース エンジンが移行元と大きく異なる場合を指します。

移行の複雑さは、主にソース データベースとターゲット データベースの違いによって変わります。異種移行では、スキーマとコードを変換して、ターゲット データベース言語に書き換える必要があります。変換を必要とするソース データベース用に記述されたアプリケーション コードの管理など、移行の複雑な管理には、データベース移行サービスが役立ちます。

多くの企業は、最新のデータベース エンジンによる長期的なメリットを享受するために、長期または複雑なデータベース移行プロジェクトへの投資をためらっています。

データの移行には、4 つの一般的な戦略があります。詳細と推奨される戦略については、クラウド移行戦略をご覧ください。

• 再ホスト: リフト＆シフト。データを移行する最も簡単な方法です。これにより、既存のデータベースの完全なコピーが別の環境に（通常は他のアプリケーション スタックとともに）作成されます。[同種]
• リプラットフォーム: リフト＆最適化。この戦略では、データベース、アプリケーション、仮想マシンをコピーして、新しいクラウド環境用に最適化します。これは、商用データベースから AlloyDB などの PostgreSQL 互換データベースに移行する場合など、異種移行である可能性があります。  [同種/異種]
• リファクタリング: 移行＆改善。リファクタリングによるクラウド移行戦略とは、アプリケーションの変更を含め、アプリケーションをクラウドネイティブに再設計することです。[通常は異種]
• 再構築。クラウド移行戦略の再構築では、アーキテクチャとアプリケーションをクラウド専用に書き換えます。アプリケーションによっては、リファクタリングよりもコストがかからない場合があります。[通常は異種]

任意の 2 つの場所の間でデータベースを移行できますが、移行の大部分はオンプレミスからクラウドへ、またはクラウドから別のクラウドへ行われます。

企業がクラウド（または代替クラウド プロバイダ）に移行する理由はさまざまです。

• アプリケーション開発の加速
• パフォーマンスとスケーラビリティの向上
• コストの節約
• セキュリティ
• より幅広い機能（特に AI 関連の機能など）
• 従来のライセンス データベースで一般的なオンプレミスの資本的支出（CapEx）から、クラウド サービスで一般的な運用支出（OpEx）への移行

クラウドへの移行のメリットについて詳しくご確認ください。

データベースの移行プロセスは、企業が頻繁に行うことがないのが理想です。移行を最大限に活用するには、次の点を考慮する必要があります。

• 新しいアーキテクチャは、将来のビジネスの成長に合わせて拡張できますか？
• 移行によってビジネス運営はどのような影響を受けますか？ダウンタイムと中断を最小限に抑えることは可能でしょうか？
• 新しいシステムにかかる総費用はいくらかかりますか？新しいインフラストラクチャ/サービスの毎月の費用/削減額の観点から移行費用を考慮してください。

データとデータベースの移行は複雑になることがあります。企業のデータだけでなく、組織のデータも新しいアーキテクチャにシームレスに移行できるようにすることが重要です。不適切な方法を使用すると、データ損失、ワークロードの正常な実行の欠如、セキュリティの問題が発生する可能性があります。

一部のベスト プラクティス

• データの把握。特定のビジネスケースとアプリケーションに対するニーズを把握することが不可欠です。
• ビジネスの方向性を評価する。スケーリングを考慮に入れることが、適切なアーキテクチャとプロバイダを選択するうえで重要です。
• 状況に合った適切なデータ移行戦略を選択する。
• 最適なパフォーマンスを実現するために、慎重にデータ移行計画に従う。

考慮事項:

• 最初に移行すべきデータベースとアプリケーションはどれか。
• データモデル（リレーショナルなど）は同じままにすべきか？それとも、このデータモデルを変更することでユースケースにメリットがあるか？
• 同じデータベース エンジンを使い続けるべきか、それとも別のデータベース エンジンに切り替えるべきか？
• データベースを社内で移行すべきか、それとも外部サービス プロバイダに依頼すべきか？
• どのデータベース移行サービスやその他のツールを使用すればよいか。
• 生成 AI はその移行に役立つか？
• 新しいデータベースを自分で管理するか、それともマネージド サービスを選択するか？

移行に必要なフェーズの数は、組織の既存の設定とタイムラインによって異なります。たとえば、セルフマネージドのオンプレミス デプロイメントからマネージド クラウド サービスへの移行は 1 ステップで完了できます。また、時間に余裕がない場合は、まずクラウドのセルフマネージド データベースに移行してから、フルマネージド ソリューションに切り替えることもできます。

異種データベース移行の場合は、変換をこれらのステップのいずれかと組み合わせるか、後で変換するかを検討してください。

プロセスの詳細については、データ移行のコンセプトと原則およびデータ移行プロセスの設定と実行をご覧ください。

詳細は個々のビジネスケースによって異なりますが、移行を成功させるための基本手順は以下のとおりです。

1. 全データに関する現在の所在、データの形式、移行後のデータの場所を特定します。すべてのデータを移行する必要がないと判断した場合は、古いデータをアーカイブまたは削除します。これは、移行の潜在的なリスクに注意する重要な機会でもあります。
2. 移行戦略を計画します。どの移行戦略が最も効果的かを判断し、営業時間中にダウンタイムが発生する可能性があるかどうかを判断して、予算を設定します。
3. 移行を実行します。実装には移行サービスを使用することをおすすめします。
4. カットオーバー前に新しいシステムをテストします。これにより、適切に機能していないワークロードを特定し、問題を解決できます。両方のデータベースを同時に実行する必要があり、一方のシステムから他方のシステムへのデータのレプリケーションが必要になる場合もあります。すべてのワークロードが新しいデータベースで想定どおりに動作していることを確認できて初めて、古いシステムをシャットダウンできます。

データベースを移行した後も、最高のパフォーマンスを維持するために最適化を続ける必要があります。フルマネージド データベース サービスをご検討ください。

前述の理由から、多くの組織はオンプレミスのワークロードをクラウドに移行しています。オンプレミスからの移行には、クラウドからクラウドへの移行と比べて追加の考慮事項があります。

オンプレミス ワークロードを移行する一般的な戦略は、ワークロード全体をクラウドにコピーする再ホストです。これにより、クラウドへの移行に伴うセキュリティ、信頼性、費用面でのメリットが得られます。ただし、この戦略では、オンプレミス アーキテクチャの既存の非効率性もクラウド インフラストラクチャに移行されます。したがって、この戦略では、クラウドネイティブ アーキテクチャに関連するより大きな費用削減と効率性を逃すことになります。また、障害復旧、分析インテグレーション、AI/ML サービス、パートナー サービスのマーケットプレイスなどの分野で、クラウドの豊富な機能を活用できなくなる可能性もあります。

特に異なるタイプの環境間では、移行中、データのセキュリティを確保する必要があります。最適なセキュリティを確保する方法の一つは、信頼できるデータベース移行サービスを使用することです。

数日から数か月かかることがあるため、計画を立てておくことが重要です。要素には、データベースのサイズ、移行戦略、データベース移行サービスを使用するかどうかなどがあります。

データベースの移行では、データを移動するだけでなく、新しいシステムでワークロードがスムーズに実行されるように機能を維持することです。移行の方法は、作成したコードと移行ツールによって異なります。

データベース移行サービスのメリットは次のとおりです。

• シームレスなデータ転送
• 転送中のデータの保護と暗号化
• 全体的な移行の加速
• ダウンタイムの短縮
• データの整合性
• 全体的な経費の削減

また、生成 AI が企業のワークロードでの重要性を高めるにつれ、クラウド プロバイダは Gemini などの大規模言語モデル（LLM）を使用したデータベース エンジン間の AI による変換を提供するようになっています。

データベース移行サービスを提供しているかどうかについては、選択したクラウド プロバイダにお問い合わせください。