ナビゲーションをスキップする

データ移行とは何ですか? クラウドへのデータの移行

データ移行は、多くの場合、オンプレミスの場所からクラウド プラットフォームにデータを移動することを意味します。

データ移行の定義

一般に、データ移行とは、デジタル情報を移動することを意味します。この情報を別の場所、ファイル形式、環境、ストレージ システム、データベース、データセンター、またはアプリケーションに転送する処理はすべて、データ移行の定義に適合します。

データ移行のさらに具体的な定義:

データ移行とは、データを選択、準備、抽出、変換し、あるコンピューターのストレージ システムから別のシステムに完全に転送するプロセスのことです。

データ移行は一般的な IT アクティビティです。しかし、データ資産はさまざまな状態でさまざまな場所に存在する可能性があるので、ある移行プロジェクトは他のプロジェクトよりも複雑で技術的に困難になります。データ資産の例を以下に示します。

  • さまざまなデバイスに保存されている、整理されていないファイルの詰め合わせ。
  • アプリケーション、オペレーティング システム、環境。
  • SQL Server、MySQL、PostgreSQL、MariaDB などのリレーショナル データベース。
  • MongoDB、Azure Cosmos DB、DocumentDB、Cassandra、Couchbase、HBase、Redis、Neo4j などの非構造化データベース。
  • データ レイク、データ BLOB、データセンター全体。

結果として、データ移行プロジェクトが確実に成功するには、計画、実装、検証が必要になります。

データ移行の計画

データ移行の要件の収集とスコープ指定を始める前であっても、最初に組織は実際に所有しているデータを検出して評価する必要があります。データをマップする必要があります。データの量、多様性、品質や条件を調べます。

同様に、組織に対する移行の影響を評価し、利害関係者および関連した得意分野を持つ人物を確立し、担当を割り当て、予算とタイムラインを設定し、データ移行プロジェクトに関して全員が通信する方法について合意します。

プロジェクトのスコープを指定した後、チームは移行をデザインします。このデザインには、データの移動時に使用するデータ移行ソフトウェアとハードウェアの選択、データ移行の仕様の作成、データの移行率の決定などが含まれます。これらを一度にすべて行ったり、一度に少しずつ行ったり、その折衷案を採用したりします。多くの組織は、移行を適切なサイズに調整することについて支援とガイダンスを求めます (特にクラウドに移行する場合)。

データ移行の実装

計画が完了し、移行をデザインしたら、チームは実装を開始します。計画フェーズで定められた要件とステップ バイ ステップの移行のガイダンスに従ってデータ移行ソリューションをビルドし、データの転送を開始します。

データ移行の際に、チームではモニターとテストを行って、データが正しく転送されており、競合、データ品質の問題、重複、異常がないことを確認します。このモニターとテストは、運用環境を反映しており、チームがデータ移行に関する問題をすばやく特定して修復できる環境で行います。

データ移行の検証

すべてのデータが移行され、実装が完了すると、チームは新しい構成内のデータを監査し、データが正確に転送されたことを検証します。チームは、技術的な利害関係者やビジネス上の利害関係者、およびデータを使用する可能性があるその他の人物 (顧客を含む) によってデータ移行が検証された後にのみ、古いデータ構成をサービスから除外します。

組織では、さまざまな理由でデータを移行する必要が生じたり、データ移行を選択したりする場合があります。大まかには、これらの理由にはコストの削減、革新の可能性、パフォーマンスの向上、可用性の向上、セキュリティの強化などが考えられます。組織がデータの移行を判断する際には、データの整合性、移行のコスト、ビジネスとその顧客への影響を考慮する必要があります。

データ移行が必要になる可能性のある特定のシナリオとビジネス ケースには、次のものが含まれます。

  • レガシ ハードウェアまたはソフトウェアをアップグレードするか置き換えて、組織がパフォーマンス要件を満たしたり、競争力を高めたりできるようにします。
  • メモリ占有領域が小さく、電力消費が少ないシステムに移動することで、環境影響量を軽減し、運用コストを削減します。
  • クラウドに移行すると、オンプレミスのデータセンターでデータをホストする際の費用が減ったりなくなったりします。
  • データを一元化して相互運用機能を有効にして支援するか、より安全なデータセンターに再配置します。
  • データをバックアップして、組織がディザスター リカバリーの準備と実行を改善できるようにします。

最新化の作業の一環としてデータを移行する必要がある組織は、多くの場合、クラウド環境のセットアップとエンドツーエンドの移行のガイドについて専門家のアドバイスと支援求めます。

データ移行とデータ変換: 違いは?

データ移行の意味を明確に理解するために、データ変換とは何か、データ移行とどのように関連しているかを把握することが重要です。定義上、データ移行にはデータ変換が含まれているので、アクティビティやプロジェクトの対象がデータ変換とデータ移行のどちらなのか混乱することがよくあります。しかし、データ変換はデータ移行の 1 つの側面に過ぎないので、この 2 つの用語は相互に類義語として使用できません。

データ移行とはある環境から別の環境にデータを移動することを意味しますが、データ変換とはデータをある形式から別の形式に変換することを意味します。次の比較では、データ移行とデータ変換のその他の違いと類似性に注目しています。

データ移行 データ変換
新しいデータセンター、場所、システム、または環境にデータを移動します。 データが新しいアプリケーションに移動されます。データセンター、システム、または環境は同じままである可能性があります。
データの形式は変わらない場合があります。 データの形式が変換されます。
プロセスは、計画、実装、検証から成ります。 このプロセスは、抽出、変換、読み込みから成ります。
データ移行にはデータ変換が含まれることがよくありますが、データ変換が必ずしも必要とは限りません。 多くの場合、データ変換はデータ移行の最初のステップの 1 つですが、データ変換を行わずにデータ移行が行われることもあります。

データ移行では、レガシ アプリケーションが情報を読み取る方法とは異なる方法で情報の読み取りを行う新しいアプリケーションが導入される可能性があります。レガシ アプリケーションと連動したデータが新しいアプリケーションと連動するには、チームは新しいシステムで解釈されて使用できる形式にそのデータを変換する必要があります。この変換プロセスが、データ変換です。データ変換を行うと、チームはデータをレガシ アプリケーションからまったく異なるアプリケーションまたは別のバージョンの同一アプリケーションに移動できます。データは、ソースから抽出され、新しい形式に変換され、新しいアプリケーションに読み込まれます。

多くの場合、正常なデータ移行を実行するには、チームはデータを変換する必要があります。これは、データ移行プロセスの早い段階で、データを新しい環境に移動する前に行います。データ変換には、プロファイル作成、クリーニング、検証、(データ移動後の) データに対する品質保証テストの実行は含まれません。そのため、データ移行とデータ変換の違いに関する問題より、プロジェクトにデータ移行とデータ変換を組み込む方法に関する問題の方が大きくなります。

データ移行のタイプ

すべてのデータ移行プロジェクトは、関連するシステムとデータ、および組織の目標に応じて異なりますが、次の 5 つの広範なカテゴリにデータ移行を分類できます。

データ移行のタイプはこれらだけではなく、データ移行プロジェクトに複数のタイプのデータ移行を含めることができます。たとえば、組織がオンプレミス サーバーからクラウド プロバイダーにより運用されるサーバーにデータを移動することに決めた場合、このプロジェクトはクラウド移行とデータベースの移行になる可能性があります。この 5 つのカテゴリは、データ移行シナリオの一般的なアウトラインと、組織がその特定のタイプのデータ移行を実行する理由が明示されているので、役に立ちます。

ストレージの移行

ストレージの移行は、データ移行の最も基本的なタイプで、データ移行のリテラル定義に適合します。この移行は、データをある記憶装置から新しい記憶装置または別の記憶装置に移動することから成ります。このデバイスは、同じ建物内でも、遠く離れた別のデータセンター内でもかまいません。ハード ディスク ドライブからソリッド ステート ドライブへの移動など、デバイスの種類が異なる場合もあります。データのクラウドへの移行やクラウド プロバイダー間での移行も、ストレージの移行の一種ですが、これらのタイプのデータ移行の特性は、クラウド移行と解釈する方が望ましいです。

組織は、パフォーマンスの高速化を実現したり、スケーリングのコストを節約したりするために、備品やインフラストラクチャをアップグレードする必要があることが判明した場合に、ストレージの移行を行うことを選択できます。新しいテクノロジーにより、組織がデータの管理、セキュリティ保護、バックアップ、復旧を行う際の効率が上がる可能性もあります。ストレージの移行中に、組織はデータをクリーニングして検証することもできますが、このタイプのデータ移行中に組織がデータ形式の変更を選択することは多くはありません。

データベースの移行

このタイプのデータ移行ではデータ変換が必要なことがよくあります。通常データベースの移行には、更新済みまたは別個のデータベース エンジンやデータベース管理システムに大量のデータを移動することが関係するからです。転送されるデータが多いだけでなく、データの形式も変更される可能性も高いので、データベースの移行はストレージの移行よりも複雑です。

データベース ソフトウェアのアップグレード、データベースのクラウドへの移行、またはデータベース ベンダーの変更が必要な場合、組織ではデータベースの移行が必要になる場合があります。移行を開始する前に、チームはデータベースにとって適切な容量があることを確認し、データベースを使用するアプリケーションに影響がないことをテストして確認する必要があります。

アプリケーションの移行

アプリケーションの移行には、データを新しいコンピューティング環境に移動することが関係します。このタイプのデータ移行は、他の複数の移行を組み合わせたデータ移行の一例です。アプリケーションの移行には、データベースの移行とストレージの移行の両方が必要になる場合があります。アプリケーションに使用されるデータベースを再配置する必要が生じます (データ変換により新しいデータ モデルに合わせて形式を変更する必要も生じることもあります)。また、アプリケーションにとってインストールして実行する必要があるファイルとディレクトリ構造も共に再配置する必要が生じます。

組織は、ビジネス機能の実行に組織が使用するソフトウェア、ソフトウェアを提供するベンダー、またはソフトウェアがあるプラットフォームに変更がある場合に、アプリケーションの移行を実行できます。

クラウド移行

このタイプのデータ移行には、他の 2 つのタイプのデータ移行 (ストレージの移行とアプリケーションの移行) と同様に、データまたはアプリケーションの移動が含まれます。重要な側面として、クラウド移行は具体的に、データまたはアプリケーションを個人用のオンプレミス データセンターからクラウドに、またはクラウド環境間で転送することを指しています。移行のエクステントは変わります。クラウド移行には、すべてのデータ、アプリケーション、サービスをクラウドに移動することが関係する場合もありますし、戦略的な目的やビジネス上のニーズを満たす数個だけを選択して移動することを伴う場合もあります。

クラウドに移行すると、組織にとっては、スケーリングの制限が少なくなり、リソースのプロビジョニングが簡単になり、アップグレードの際のフィクションが少なくなり、より効率的に時間やコストを費やし、より迅速に革新することができるようになります。クラウドにデータとアプリケーションがあると、これらの組織は、オンプレミスでそれらの資産を保存していたマシンとインフラストラクチャを保守する必要がなくなります。

ビジネス プロセスの移行

このデータ移行のタイプは、ビジネス自体の管理または運用を改善するために、データとアプリケーションを移動することを指します。ビジネス プロセス移行では、製品、カスタマー エクスペリエンス、運用、プラクティスに関するあらゆる種類のデータ (データベースやアプリケーションを含む) を組織が転送する場合があります。

組織は、ビジネスの運営方法の最適化や再構成、市場での競争力の向上、新しい製品やサービスの提示、合併と買収の達成のために、このタイプのデータ移行を行う場合があります。

データ移行ツール

移行を実行するために、チームはさまざまなデータ移行ツールを使用してデータを移動し、必要に応じて変更します。独自のデータ移行ツールを最初からビルドすることを選択するチームもあります。データ移行ツールをビルドする利点は、チームが特定のシステムや用途に合わせてツールを調整できることです。しかし、データ移行ソフトウェアのコーディングには時間がかかる場合があり、多くの手動の統合と再実装の作業が必要になり、データ移行プロセスの他の部分に費やす方が望ましいコストを割くことになる可能性があります。セルフスクリプト データ移行ツールは、多数の入力ソースのスケーリングや処理に関する問題が発生する可能性もあります。

代わりに、チームは既存のデータ移行ソフトウェアを使用して、データをより簡単、迅速、効率的に移動することを選択できます。多くの場合ソフトウェアは、クラウドへの SQL Server データベースの移行などの特定の種類の移行の支援に特化しています。ただし、ソフトウェアを使用する場合でも、チームは移動しようとしているデータについて、移行する量、移行する時点、加える必要がある変更内容、転送の完了後に解決する必要がある問題があるかどうかをすべて把握する必要があります。また、これらのチームは、オンプレミスのデータ移行ツールかクラウドのデータ移行ツールのどちらかを選択する必要もあります。

使用するデータ移行ソフトウェアのタイプ

チームは、オンプレミス、クラウドベース、またはセルフスクリプトのデータ移行ソフトウェアから選択できます。通常、オンプレミスのツールは、データとターゲット システムがすべてオンサイトで同じ組織内にある場合に適しています。クラウドベースのツールは、異なるデータ システムを移動したり、クラウドにプラットフォームを再構築したりする場合に最適です。また、セルフスクリプト ツールは、小規模で特殊なプロジェクトに適しています。しかし、データ移行プロジェクトは複雑なので、使用可能なさまざまなタイプのデータ移行ソフトウェアから選択する際に考慮すべき要因がさらにあります。次の表は、特定の移行シナリオの特徴に応じて、どのツールが優れているかを示しています。

利用できません セルフスクリプト ツール オンプレミスのツール クラウドベースのツール
データ ボリュームとタイプ
少量 利用可能 利用可能 利用可能
大量 利用できません 利用可能 利用可能
サポート対象の形式 利用できません 利用可能 利用可能
サポート対象外の形式 利用可能 利用できません 利用できません
ソースと移行先
単一サイトのソース 利用可能 利用可能 利用可能
複数サイトのソース 利用できません 利用できません 利用可能
クラウドの移行先 利用できません 利用できません 利用可能
オンプレミスの移行先 利用可能 利用可能 利用できません
共通のソースと移行先 利用できません 利用可能 利用可能
一般的でないソースと移行先 利用可能 利用できません 利用できません
プロジェクトのニーズ
スケーリングが必須 利用できません 利用可能 利用可能
スケーリングが不要 利用可能 利用可能 利用可能
ストレージ デバイスのコントロール 利用可能 利用可能 利用できません
ローカル アクセス 利用可能 利用可能 利用可能
グローバル アクセス 利用できません 利用できません 利用可能
オンデマンドのコンピューティングとストレージ 利用できません 利用できません 利用可能
高いアップタイムと信頼性 利用できません 利用できません 利用可能

データ移行ツールを選択する方法

上記の条件に加えて、チームと組織は、データ移行ソリューションの選択に際してその他の要因を検討します。これらの要因には次のものが含まれます。

  • 予算とタイムライン
  • チームの得意分野とエクスペリエンス
  • 組織に必要なスケーリングと柔軟性の程度
  • データ移行ツールのプロバイダーとのリレーションシップ
  • セキュリティと規制コンプライアンス
  • アップタイムまたはその他の SLA
  • 潜在的な影響
  • データのユーザー
  • オペレーティング システム

作業を開始するためのリソース

組織がデータ移行を検討する準備ができたら、データ移行ツールやデータ移行パートナーのオプションを探し始めることもできます。Azure への移行の背後にある利点とプロセスの詳細については、次のリソースを参照してください。

データ移行に関するよく寄せられる質問

  • データ移行とは、デジタル情報を移動することを意味します。デジタル情報を別の場所、ファイル形式、環境、ストレージ システム、データベース、データセンター、またはアプリケーションに転送する処理はすべて、データ移行の定義に適合します。
  • データ移行とはある環境から別の環境にデータを移動することを意味しますが、データ変換とはデータをある形式から別の形式に変換することを意味します。データ移行中にデータ変換が行われる場合もあります。
  • データ移行は、ストレージの移行、データベースの移行、アプリケーションの移行、クラウド移行、ビジネス プロセス移行の 5 つの広範なカテゴリに分類できます。
どのようなご用件ですか?