データ移行とは何ですか?どうすれば正しく移行できますか?

公開: 2023-12-14

データは文字通りあらゆるビジネスや組織にとって、最大ではないにしても最大の資産の 1 つであることは長い間知られていました。 このメッセージは新しいものではなく、これ以上詳しく説明する必要はほとんどありません。大小を問わず、ますます多くの組織がデータの真の価値を認識し、その変革力を活用しようとしているからです。 2023 年だけでも、91.9% の組織がデータと分析への投資から測定可能なビジネス価値をもたらしました。

戦略的意思決定のためにデータに大きく依存している企業は、ある時点で、パフォーマンス最適化の取り組みまたは大規模なデジタル変革プロジェクトの一環として、ビジネス データを移行する必要性に直面します。 企業がデータ移行を実行し、データ移行コンサルタントの支援を求める必要がある理由は、ケースバイケースです。

このブログ投稿では、データ移行とは何か、いつ必要になるか、および堅牢なデータ移行戦略を作成する手順を定義します。 さらに、データ移行時に企業が直面する可能性のある主要な課題とリスクのいくつかを明らかにし、それらに対処する方法に関する ITRex からのベスト プラクティスのヒントと推奨事項をいくつか共有します。 読み続けてください。

データ移行とは何ですか?

大まかに言うと、データ移行とは、IT システム間でデータを移動することを意味します。 具体的には、データ移行は、あるストレージ タイプから別のストレージ タイプ、またはあるアプリケーションから別のストレージ タイプにデータを転送するプロセスであり、通常は新しいアプリケーションまたはソフトウェアの実装によって行われます。

ただし、データ移行の詳細を詳しく説明する前に、データ移行、データ統合、およびデータ レプリケーションの違いを説明することが重要です。これらは誤って同じ意味で扱われ、一緒にグループ化される可能性があります。 これらはすべてデータの移動を扱いますが、これらの用語は異なる目的を果たしているため、まったく異なります。 それでは、これらの用語の意味を定義しましょう。

データ移行には内部情報の処理が含まれますが、データ統合とは、異種の内部および外部ソースに存在するデータを単一のデータ ウェアハウスまたはデータベースに結合するプロセスを指します。 これは、企業全体のすべてのビジネスクリティカルなデータの統一されたビューを提供するために行われます。 しかし、違いはそれだけではありません。 データ移行は、すべてのデータがターゲットの場所に到達した時点で終了する 1 回限りのアクティビティですが、データ統合は継続的なプロセスです。 この継続的なプロセスにより、データは常にリアルタイムで行き来することができるため、分析が加速され、情報に基づいた堅牢な意思決定が可能になり、日常業務がサポートされます。

データ レプリケーションは、1 回限りの移行プロセスとは対照的に、データの複数のコピーをリアルタイムで、スケジュールに従ってバッチで、またはオンデマンドで作成し、複数の場所に保存する永続的なプロセスを意味します。 このアプローチにより、災害後の迅速かつ効率的なデータ回復が可能になり、より高速なデータ アクセスが可能になり、データの可用性が向上し、サーバーのパフォーマンスの最適化に役立ちます。 さらに、レプリケーション プロセス中に、ソース ストレージが削除されたり放棄されたりすることはありません。 対照的に、データ移行は、データが宛先ストレージ システムに移行された後のソース データベースの廃止を意味します。

データ移行が必要になるのはどのような場合ですか?

データ移行の簡潔な定義を示し、それが統合プロセスやレプリケーション プロセスとどのように異なるかを説明したところで、企業がデータ移行を実行する必要がある理由を見てみましょう。

データ移行が必要な場合の最も一般的なシナリオのリストを次に示します。

  • 数十年前のものである可能性のあるレガシー ソフトウェアおよびデータベース システムのアップグレードまたは置き換え
  • 複数の異種ソースからのビジネス データを一元化されたリポジトリに統合して、データ サイロを排除し、企業全体の情報を 1 つの 360 度ビューで把握できるようにします。
  • データの統合や分離が必要となる可能性のある、合併、買収、売却などの事業の再構築と拡大
  • クラウドベースのストレージに移行して拡張性とセキュリティを実現し、オンプレミスのデータ ストレージに関連するコストを削減する
  • ビッグデータ分析、モノのインターネット、機械学習など、さまざまなデータストレージと処理能力を必要とする新しいテクノロジーの導入
  • 増え続けるデータプライバシー法および規制へのコンプライアンスの維持 – たとえば、データローカライゼーション法に従って規制対象データを本国を離れる前にローカライズする、または居住規則の変更に伴うデータを再配置する

理由が何であれ、データ移行は決して小さな仕事ではなく、危険を伴うものであることは言うまでもなく、場合によっては結果が不確実になることもあります。 しかし、移行しないという選択は、多くの場合さらにリスクが高くなります。 リスクを軽減し、データ移行を簡単にするには、信頼できる経験豊富なパートナーにすべての面倒な作業を依頼することをお勧めします。

データ移行の種類

データ移行にはいくつかの種類があり、特定のビジネス要件、システム、関連するデータに応じて重複する可能性があります。 ここでは、最も一般的なデータ移行シナリオの概要を示します。

ストレージの移行

最も基本的なタイプのデータ移行であるストレージ移行は、オンプレミス サーバーからクラウドベースのストレージへの移行、あるクラウド ストレージ プロバイダーから別のクラウド ストレージ プロバイダーへの切り替え、地域のデータ センターから別のクラウド ストレージ プロバイダーへのデータ移行など、あらゆる移行シナリオを実行します。中央データセンター。

データベースの移行

データベースがデータベース管理システム (DBMS) を通じて管理されることを考えると、データベースの移行は通常、ある DBMS から別の DBMS への移動 (異種移行) か、同じ DBMS の新しいバージョンへのアップグレード (いわゆる同種移行) のいずれかを意味します。 前者の例は、MySQL から PostgreSQL への切り替え、または Oracle Database から MongoDB への切り替えです。

アプリケーションの移行

アプリケーションの移行とは、アプリケーションをあるコンピューティング環境から別のコンピューティング環境に移動することを指します。 これは、他のいくつかを組み合わせることができる単なる移行タイプです。 この移行シナリオの例としては、オンプレミスの顧客関係管理 (CRM) アプリケーションをクラウドベースの Salesforce ソリューションに移行したり、モノリシック e コマース アプリケーションを一連のマイクロサービスに移行したりすることが挙げられます。

クラウドへの移行

クラウド移行の重要な側面は、オンプレミスのデータベース サービスからクラウドへ、および異なるクラウドベースの環境間でデータを移動することを指します。たとえば、オンプレミスの Microsoft SQL Server から Microsoft Azure SQL Database への移行です。

ビジネスプロセスの移行

大規模なビジネス プロセス リエンジニアリングの取り組みに関連して、このタイプのデータ移行では、アプリケーションと、ビジネス メトリクス、プロセス、運用情報などのビジネス クリティカルなデータを新しい環境に移行する必要があります。

データ移行へのアプローチ

データ移行戦略を立てる方法は複数ありますが、ほとんどのアプローチは基本的に 2 つの最も一般的なカテゴリのいずれかに分類され、それぞれに独自の長所と制限があります。 どうぞ。

ビッグバン移行

ビッグバン移行では、データ資産全体が 1 回のアクションでソース システムからターゲット環境に転送されます。 時間はかかるかもしれませんが、ユーザーにとっては古いシステムを一度に廃止して新しいシステムを起動するような感じで、ビッグバンに似ているため、この名前が付けられました。

利点としては、ビッグバン アプローチにより、可能な限り最短時間で新しいシステムに切り替えることができるため、従来のシステムと新しいデータベースを同時に使用する手間が省けます。

欠点としては、ビッグバン移行ではシステムのダウンタイムが必要になることが多く、データが変換されて移行先のストレージ システムに移動される限り、ユーザーはシステムを利用できない状態が続くことになります。 そのことを念頭に置いて、このような移行は、ユーザーがシステムを使用することが予想されない営業時間外、または週末や祝日などのオフピーク時に実行する必要があります。 さらに、ソース システム内に蓄積されたギガバイトやテラバイトのデータは、送信中にネットワークの輻輳を引き起こす可能性があり、その結果、データの損失が発生したり、最良のシナリオではデータ転送が遅くなる可能性があります。 したがって、ビッグバンの導入は、大規模なデータセットを生成せず、ダウンタイムを許容できる中小企業に適している可能性があります。

トリクルマイグレーション

名前が示すように、トリクル移行アプローチは対照的に、データをより小さく管理しやすいチャンクに分けて移行することを目的としています。 この戦略により、企業が新しいシステムに最終的に切り替える準備が整うまで、レガシー システムとターゲット システムの両方を同時に実行することができます。 これにより、ダウンタイムが排除され、ネットワークの輻輳の問題が軽減され、エラーや予期せぬ障害の可能性が軽減されます。 データ移行はバックグラウンドで継続的に行われます。これは、データ転送中に動作を維持する必要があるシステムにとって特に重要です。

ただし、ビッグバン戦略とは異なり、反復的な移行は計画と実行の両方の点で時間とリソースを大量に消費するプロセスです。 移行チームは、移行プロセス全体を通じてデータの一貫性と整合性を確保するために、継続的なデータ検証とテストを実行するだけでなく、ターゲット システムがソース システムと同期しているようにする必要があります。 その点で、大規模なデータセットを扱い、ダウンタイムの許容度が低い組織にとっては、トリクル移行アプローチの採用を選択することが最良の選択肢となる可能性があります。

データ移行プロセス: 問題なく移行する方法

データ移行の意味、その種類、重要性、アプローチについて完全に理解できたので、次はデータ移行プロセスの詳細を詳しく掘り下げていきます。

どのようなアプローチであっても、すべてのデータ移行プロジェクトは同じ重要なフェーズを経ます。 大まかに言うと、これらのフェーズには通常、移行前の計画、実装、移行後の監査が含まれます。 各段階は、特定のビジネス ニーズと要件に基づいて、さらにいくつかの段階に細分化できます。 ここでは、データを適切に移行するための重要な手順の概要を説明します。

企画

データ移行プロジェクトを成功させるには、綿密な戦略計画が鍵となります。 通常、既存のデータセットを評価し、明確な計画をまとめることから始まります。どのデータを移行する必要があるか、どこに移動する必要があるか、そしてそこにどのように移行するかを正確に理解する必要があります。 計画段階には次の手順も含まれる場合があります。

  • ソース データを調べて、データ形式、その場所、構造、属性を特定します。
  • 適切なターゲット ストレージ ソリューションを選択し、宛先システムを分析して、ソース データが新しい環境に適合するかどうか、宛先の仕様に合わせて何を再構築する必要があるかを判断します。
  • 最適なデータ移行アプローチ (ビッグバンまたはトリクル) を選択します。
  • 最適なリソースを割り当て、予算を設定し、データ転送のタイムスケールを定義します。
  • データ監査

データを移行する前に、移動するデータの完全な監査を実行することが極めて重要です。 データ監査の目的は、重複レコード、不正確さ、不一致などのデータ品質の問題を検出し、続行する前にトラブルシューティングを行って、高品質のデータのみが新しいシステムに転送されるようにすることです。 ここで、ターンキー データ品質ソリューションが非常に役立つ可能性があります。

古いデータの削除

新しいシステムに存在する必要のない、未使用または期限切れのオブジェクトを特定して削除します。 古いデータを削除すると、移行がよりスムーズになると同時に、移行後にチームがクリーンなデータセットを操作できるようになります。

データバックアップ

技術的には義務ではありませんが、移行を実装する際のベスト プラクティスとして、データをできれば複数の場所にバックアップすることが推奨されます。 これにより、移行が失敗した場合に追加の保護層が提供されます。

移行設計

ここでは、移行プロセスの詳細を説明します。つまり、移行先環境のセットアップ、完全なデータ マッピングの実行、移行とテストのルールの定義、受け入れ基準の作成、移行の役割と責任の割り当て、データ移行テクノロジと方法の指定です。

後者については、ソース システムからターゲット システムにデータを転送できるデータ移行方法がいくつかあります。 例としては、物理ストレージの移行、バックアップと復元、1:1 コピー (バッチ EL)、または ETL テクノロジ (抽出、変換、ロードの略) などが挙げられます。 データ移行ツールに関しては、最も一般的なツールには、AWS Database Migration Service、Azure Data Box、Apache NiFi、または特定の複雑な移行ニーズに対応するカスタム Python スクリプトがあります。

実行とテスト

ここで実際に移行が行われます。 堅牢なデータ移行プロセスには、データが仕様に従って変換およびロードされていることを確認するための定期的なテストが必要です。 データの移動に伴い、移行されたデータをテストおよび再テストして、その完全性、正確性、信頼性を検証することが重要です。 ソース システムに障害やダウンタイムの兆候があるかどうかを確認し、問題をできるだけ早く修正するには、頻繁または継続的なテストが絶対に必要です。

移行後の監査

実装が完了したら、移行結果の監査を実行して、データがターゲット インフラストラクチャに安全に移動されたかどうか、またデータが完全で実行可能であるかどうかを確認することが重要です。 新しいシステムが稼働し、問題なく稼働したら、古い環境を安全に廃止できます。

データ移行の課題: 注意すべき点

ビジネスのモダナイゼーション プロジェクトの一環としてデータ移行が必要であると認識したら、どのような課題が発生する可能性があるかを明確に理解することが重要です。

データ移行プロセスの邪魔になる可能性のある問題が多数あるため、移行は実装の中で最も複雑で困難な部分の 1 つとなります。 これを考慮してください。Gartner によると、データ移行プロジェクトの 83% 以上が失敗するか、予算やスケジュールを超過しています。 ほとんどの場合、これは組織がリスクを無視したり、データ移行プロセスを成功させるために必要な労力を過小評価したりして、データ移行をポイント A からポイント B への移動だけとして扱っていることが原因です。データ移行の取り組みが無駄になるのを防ぐには、データ移行の取り組みに着手する前に、データ移行のリスクと課題に注意することを強くお勧めします。 以下に主な考慮事項のリストを示します。

運用の中断とダウンタイム

組織はデータの整合性の必要性とシステムを稼働し続けるための要件のバランスを取る必要があるため、データ移行に関してビジネス継続性を達成することは非常に困難な場合があります。 これは、ダウンタイムが許されない大量のデータを生成する企業に特に当てはまります。 ビッグバン データ移行アプローチの場合と同様に、計画されたダウンタイムは避けられませんが、伝送障害、アプリケーションのパフォーマンスの問題、または当初計画できなかったその他の多数の緊急事態により、ビジネス プロセスが予期せず停止する可能性があります。初期段階。

コストの過小評価

予算設定によって、データ移行の取り組みが成功するか失敗するかが決まる可能性があります。 データ移行プロジェクトをリスクにさらすのはコストの過小評価です。 計画外のダウンタイムや緊急事態に関連する隠れた間接コストを含む、データ移行の実装のあらゆる側面を考慮に入れていない場合、予期せず指定された予算をはるかに超えてしまう状況に陥る可能性があります。 Gartner が述べているように、データ移行プロジェクトのコスト超過は平均 30% です。

不十分なデータマッピング

データベース アーキテクチャの違いにより、レガシー システムのデータ フィールドは新しいシステムのデータ フィールドと同期していない可能性があります。 したがって、単にフィールドをマッピングしてターゲット システムにデータを詰め込もうとするだけでは、大きな損害が発生する可能性があります。 データ マッピングが不完全または不正確であると、特定のデータ要素が間違ったフィールドに配置される可能性があり、定期的な更新とフィールドの再マッピングに多大な時間と労力が必要になる可能性があります。

データセキュリティとコンプライアンス

法令順守を確保し、移行中に機密データを保護すると、プロジェクトがさらに複雑になります。 クライアントの個人データを扱うときは、地域によって異なるプライバシーとデータ保護の規制を理解し、遵守する方法を模索する必要があります。 問題は、米国には包括的な連邦データ保護法が存在しないということです。 むしろ、規制は州や業界によって大きく異なります。 対照的に、欧州連合ではデータは一般データ保護規則 (GDPR) によって保護されています。 このデータ プライバシー ルールの統一フレームワークは、データ所有者に厳格な義務を課し、適切なデータ保護措置が欠如している第三国への個人データの転送を禁止します。 これらの移転は、欧州委員会が十分性に関する決定を出した場合にのみ発生します。

その結果、大西洋を越えたデータフローに関しては、GDPR違反を防ぐ方法を模索することが最大の懸案事項となっている。なぜなら、13億米ドルという記録破りのGDPR罰金を科されたテクノロジー大手メタ社の場合のように、これらの違反は制裁を受ける可能性があるからである。 — GDPR史上最大規模。

変化への抵抗

大規模なデータ移行は、世界全体に一度に変化をもたらすため、システム ユーザーにとっては常にイライラすることになります。 既存のデータベースでクエリを実行することに慣れているユーザーは、新しい環境やデータ形式の変更に適応するのに苦労する可能性があり、これは多くの場合、変更への抵抗として現れます。

ITRex チームによるデータ移行のベスト プラクティス

以下は、上記のデータ移行のリスクと課題に対処するために役立つ、ITRex のビッグ データ コンサルタントによる明確なガイドラインの一部です。

  • ダウンタイムを最小限に抑えるか、ダウンタイムが発生した場合の影響を軽減するために、中断を計画します。 はい、正しく聞こえました。 どのような状況でもどうすれば前進し続けることができるかを知りたいと思いませんか? このため、混乱に対応した堅牢な戦略を構築することが重要です。 さまざまな災害シナリオと復旧方法を概説した具体的な事業継続計画を策定することは、長期にわたる中断から事業運営を守り、できるだけ短期間で事業を軌道に戻すための確実な方法です。 避けられないダウンタイムに関しては、組織にとって都合の良い時間に適切にスケジュールを設定することが、予期せぬ問題や計画外の速度低下の可能性を最小限に抑えながら、シームレスなデータ移行を確保するための優れた方法です。
  • 潜在的な隠れたコストに重点を置きながら、データ移行コストを正確に見積もります。 これには、アプリケーションの依存関係の管理、外部請負業者の雇用、追加のテスト サイクルの実行、データ品質の問題への対処などのコストが含まれます。 同じシステムの重複バージョンを実行するだけでなく、生産性の低下や移行後の問題もコストに大きく影響する可能性があります。 これらの要因が総合すると、長期的には予算超過につながります。
  • マッピング スクリプトを作成する前に、すべてのソース データをプロファイリングして、その構造、品質、関係を特定することが重要です。 データをロードする前にソースから宛先への包括的なデータ マッピングを実行することは、すべてのデータが正確に配置されていることを確認するための重要な手順です。
  • 機密データを移行する場合、データのセキュリティとプライバシーの考慮事項を優先することがミッションクリティカルになります。 機密データが転送中と新しい環境の両方で安全に扱われるようにします。 移行プロセス全体を通じて機密データを保護するために、データ暗号化、匿名化、またはマスキング技術を適用することができます。 さらに、データ移行を GDPR や業界固有のガイドラインなどの関連するデータ保護規制に合わせて行うようにしてください。
  • 見落とされがちですが、役割と責任に基づいてカスタマイズされたユーザー トレーニングは、データ移行のプロセスと結果に大きな違いをもたらす可能性があります。 既存のチームの再スキル化に適切な時間と予算を割り当てることで、データ移行中および移行後のスムーズな移行に貢献し、ユーザーの受け入れを確保し、運用の中断を最小限に抑えることができます。 実際のデータ移行が行われるかなり前に、ユーザーが変化を受け入れる機会を提供できるよう、今後のデータ移行に関するコミュニケーションや実践的なトレーニング セッションを早い段階で開始することをお勧めします。 このようなコミュニケーションは、新しい環境をよりよく理解し、その中で活動するための準備を整えるのにも役立ちます。

ITRex データ移行チームからの同様に重要なヒントをさらにいくつか紹介します。

  • 急いで時流に加わるのではなく、新しいテクノロジーへの移行の必要性を評価、理解し、正当化します。何が必要で、なぜそれが必要なのかについて明確なビジョンを持つ必要があります。 移行のメリットは何ですか?
  • 概念実証 (PoC) を作成します。データ移行に本格的に取り組む前に、まず小規模で試して実際にテストしてください。
  • 代替案を検討し、各選択肢に関連するリスクと利点を評価します。 同じ役割を果たす他のテクノロジーにはどのようなものがありますか? なぜこれを選んだのですか?
  • 新しいテクノロジーの限界を評価します。 たとえば、Oracle や他の多くのリレーショナル データベース管理システム (RDBMS) に共通するストアド プロシージャは、クラウド ベースの超並列処理 (MPP) データ ウェアハウスでは同じ形式で利用できない場合があります。
  • データ処理ロジックを書き直す必要性を評価します。
  • ユーザーがどのような影響を受けるかを評価し、顧客と従業員が直面するあらゆる課題に対処できるよう、単一の連絡窓口を設けることを検討してください。

すべてをまとめる: データ移行が必要な理由

デジタル変革に関して言えば、データ移行の取り組みに着手することは選択の問題ではなく、必然の問題です。 データ移行に関しては、一定のリスク、不確実性、考慮事項を伴いますが、変更は避けられません。 データ移行を重要なイノベーション プロセスの一部として扱うことで、戦いは半分終わります。

データ移行とは何か、そしてなぜそれが必要なのかをしっかりと理解できたので、データ移行プロジェクトを簡単に開始できるようになります。

83% の失敗率は、必ずしもデータ移行の取り組みが最初から失敗する運命にあることを意味するわけではありません。 データ移行は困難で多少イライラすることもありますが、十分に計画されたデータ移行戦略があれば、すべてがスムーズに進むはずです。 当社のトップレベルのデータ管理スペシャリストによる的確な推奨事項とベスト プラクティスが、お客様にとって有益であることを願っています。

データ移行とは何か、またそれを正しく行う方法について理解したいですか? お気軽にお問い合わせください。 データ移行チームによる実証済みのアプローチにより、データ移行のメリットを最大化します。

この記事は元々 ITRex Web サイトに掲載されたものです。