データベースの移行は、積極的に行うことも、やむを得ず行うこともあります。レガシー システムは、やがて最新のビジネスニーズに対応できなくなるほか、資産としての価値が下がり、維持することがリスクになる可能性もあります。

ここでは、データベースの移行が必要になる主な理由をいくつかご紹介します。

• サポートが終了したハードウェア: 物理サーバーが老朽化し、メーカーがハードウェアやオペレーティング システムのサポートを終了している
• パフォーマンスのボトルネック: 現在のデータベース アーキテクチャでは、データ量やトラフィックの急増に対応できず、ユーザー エクスペリエンスが低下する
• セキュリティとコンプライアンス: 従来のシステムには、現在の規制基準を満たすために必要な最新のセキュリティ機能、パッチ、監査機能が不足している可能性がある
• ベンダー ロックイン: 独自の高価な、または柔軟性のないライセンスに縛られ、イノベーションや特定のニーズに最適なツールの選択が制限される
• データサイロ: データが分離されたオンプレミス システムに閉じ込められているため、競争力を維持するために必要な最新の分析モデルや AI モデルにフィードすることが難しい

既存のアーキテクチャが運用要件をサポートできなくなったとき、ビジネスを安全かつ効率的に継続するためには、「移行」が次の必然的なステップとなります。

データベースの移行において、「同種」と「異種」という用語が使用されることがあります。テクニカル チームが実施する作業を計画する際は、これらの違いを念頭に置く必要があります。

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

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

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

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

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

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

前述の理由から、多くの組織がオンプレミスのワークロードをクラウドに移行しています。オンプレミスからの移行では、クラウド間での移行に比べて、さらに考慮すべき点があります。

オンプレミス ワークロードを移行する一般的な戦略は、ワークロード全体をクラウドにコピーする再ホストです。これにより、クラウドへの移行に伴うセキュリティ、信頼性、費用面でのメリットが得られます。

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

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

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

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

• データを理解する。具体的なビジネスケースやアプリケーションのニーズを把握することが重要です。
• ビジネスの方向性を評価する。スケーリングを考慮に入れることが、適切なアーキテクチャとプロバイダを選択するうえで重要です。
• フィーチャー トグルを使用してテストする。フィーチャー トグルを使用して、まず少数のユーザー グループに新しいデータベースをロールアウトします。これにより、本格的なリリース前にシステムを安全にテストできます。
• 状況に合った適切なデータ移行戦略を選択する。
• 最適なパフォーマンスを実現するために、慎重にデータ移行計画に従う。

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

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

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

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

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