データ移行とは

データ移行とは、ある場所から別の場所、ある形式から別の形式、またはあるアプリケーションから別のアプリケーションにデータを移動するプロセスです。これは、通常、新しいシステムを導入する際やデータの保存場所を変更する際に行われます。つまり、データを新しい環境に移すことを指します。ビジネスの推進要因となるのは、通常、アプリケーションの移行や統合です。この場合、従来型システムを交換したり、同じデータセットを共有する新しいアプリケーションによって拡張したりします。企業がオンプレミスのインフラやアプリケーションからクラウドベースのストレージやアプリケーションに移行し、自社を最適化したり変革したりする中で、データ移行が始まることがよくあります。

データ移行のハイリスク要因の簡単な答えは「データの重力」です。データの重力という概念は以前からありましたが、クラウド インフラへのデータ移行が進むにつれて、課題はますます重要になってきています。簡単に言うと、データの重力は次のような特徴を持つ比喩です。

• データの増加に伴って他のデータがどのようにデータを惹きつけるか
  データの相違影響で、データが増えるにつれて、他のデータも引き寄せられるように相違影響し合います。データが増えれば触れるほど、新たな洞察や意味が生まれることを指します。
• データをどのようにビジネスに統合するか
  データの重力は、ビジネスが異なるデータ源から得られた情報を統合して活用するさいの需要性を強調しています。企業はさまざまなデータソースから情報を取り入れ、組み合わせることで包括的な洞察を得たり、戦略的な意志決定を行ったるすることができます。
• 時間の経過に伴うデータのカスタマイズ方法
  データは時間と共に変化します。データの増加や変化に合わせて、カスタマイズされたアプローチや対策が必要です。データの特性やかたちは変化し続けるため、定期的な更新や調整が必要となります。

アプリケーションやデータをより有利な環境に移動するために、 Gartner はデータの重力を克服する手段として、「データとアプリケーションの分離」を推奨しています。プロジェクトの開始時に時間をかけてデータやアプリケーションの複雑さを解消することで、データ管理を最適化し、アプリケーション モビリティを実現し、データ ガバナンスを改善できます。

主な問題は、すべてのアプリケーションがデータ管理階層にアプリケーションロジックの要素を導入することでデータ管理を複雑化し、各アプリケーションが次のデータユースケースには適していないことです。ビジネスプロセスでは、データを個別に使用し、独自の形式を出力して、次のプロセスのための統合を維持します。したがって、アプリケーション設計、データアーキテクチャ、およびビジネスプロセスはすべて相互に対応する必要がありますが、これらのグループの 1 つでは変更ができない場合もあります。これにより、アプリケーション管理者は理想的なワークフローとシンプルなワークフローをステップステップ実行し、最適でない設計を行うことができますまた、現時点では回避策が必要になっているかもしれませんが、この技術的負債は、最終的にはデータ移行または統合プロジェクトで対処する必要があります。

このような複雑さを踏まえて、適切なレベルの認知度とリソースを取得できるように、データ移行を「戦略的武器」に推進することを検討してください。プロジェクトがそのニーズに確実に対応できるように、移行の中で最も刺激的な要素、つまりレガシーシステムがオフになるという事実に焦点を当て、主要な関係者に注意を払い、保証します。

システムのアップグレードやデータセンターのクラウドへの拡張には、ビジネス上のさまざまなメリットがあります。多くの企業にとって、これは非常に自然な進化です。クラウドを利用している企業は、業務上の優先事項にスタッフを集中させ、売上の増加を促進し、俊敏性を高め、設備投資を削減し、必要な分だけ料金を支払うことができるようにしたいと考えています。ただし、実施される移行の種類によって、他のプロジェクトで作業するために IT スタッフのまず、移行のタイプを定義します。

まず、移行のタイプを定義します。

• ストレージ移行 : 既存のアレイから他のシステムからアクセス可能な最新のアレイにデータを移動するプロセス。パフォーマンスの大幅な向上とコスト効率の高い拡張を実現しながら、クローニング、 Snapshot 、バックアップ、ディザスタリカバリなど、期待されるデータ管理機能を実現します。
• クラウドへの移行 : データ、アプリケーション、その他のビジネス要素を、オンプレミスのデータセンターからクラウドに、またはクラウド間で移動するプロセス。多くの場合、ストレージの移行も必要になります。
• アプリケーションの移行 : アプリケーションプログラムをある環境から別の環境に移動するプロセス。たとえば、アプリケーション全体をオンプレミスの IT センターからクラウドに移行したり、クラウド間で移動したり、単にアプリケーションの基盤となるデータをソフトウェアプロバイダがホストする新しい形式のアプリケーションに移動したりできます。

データの移行、以下の 3 つの基本的な手順

1. データを抽出
2. データの変革
3. データのロード

重要なデータや機密データの移動やレガシーシステムの運用停止は、関係者のエッジに配置される可能性があります。確かな計画を持っていることは必須ですが、車輪を改革する必要はありません。データ移行計画やチェックリストの例は Web で多数確認できます。たとえば、データ移行スペシャリストのコミュニティである Data Migration Proには、 包括的なチェックリストがあります。

• 移行前の計画：移動するデータの安定性を評価します。
• プロジェクトの開始：主な関係者を特定し、簡潔にする。
• ランドスケープ分析堅牢なデータ品質ルール管理プロセスを確立し、レガシーシステムのシャットダウンなど、プロジェクトの目標についてビジネスに説明します。
• ソリューションの設計移動するデータ、移動前と移動後のデータの品質を確認。
• 構築とテスト：移行ロジックをコーディングし、本番環境のミラーで移行をテストします。
• 実行と検証：移行が要件に準拠しており、移動するデータがビジネスに利用できる可能性があることを実証。
• 運用停止と監視：古いシステムをシャットダウンして廃棄します。

これは膨大な量の作業と思われるかもしれませんが、す7 段階のプロセスの概要を示すべてのデータ移行にこれらの手順が必要とされるわけではありません。それぞれの状況は異なり、企業ごとに異なるアプローチを採用しています。

データ移行は数十年にわたって IT の生命の事実だったにもかかわらず、ホラーの物語は毎年報告されています。企業がデータの移動で直面する 10 の課題は次のとおりです。

1. 関係者の関心と計画の重要性。データ移行に関心を持つ関係者が存在します。関係者に懸念やニーズを追跡し、そのプロジェクトの必要性を説明し、さらにはタスクに取り組む前にそのプロジェクトがもたらす影響を説明しておく必要があります。そうでない場合は、ある段階で相手の要求はなんなのかを理解する時間を要することになります。結果的にはこれが、タイムラインを妨げる可能性も高くなります。 
2. 報告とコミュニケーションの重要性。プロジェクトを関係者に説明したら、進捗状況を常に伝えておいてください。毎週同じ日にステータスレポートを作成して共有ことをお勧めします。特に、状況が追跡されない場合は、このレポートを作成するのが望ましいと言えます。定期的なコミュニケーションは、プロジェクトに影響を与えるすべての人との信頼関係を構築する効果的な方法です。
3. データガバナンスの確立。ソースシステムのデータを作成、承認、編集、削除する権限を持つユーザーを明確にし、プロジェクト計画の一部として記述することを文書化します。詳しく言えば、プロジェクトにおけるソースシステムのデータの取り扱いに関して、どのユーザーがどの操作を行う根源を持っているかを明確に定義し、それをプロジェクト計画の一部として詳しく記述することが需要です。このように、明確化と文書化にすることによって、混乱や誤解を防ぐことができます。 
4. 専門知識の不足。データの移動という作業は簡単そうに思えてしまいますが、実際にはその背後には多くの複雑な側面が絡んでいます。異なるデータソースやフォーマット、システム間の連携データ品質の保持など、さまざまな要因がデータ移動を複雑なプロセスに変えています。こうした複雑性に対処するには、経験豊富な専門家の知識とリソースを活用することが重要です。 
5. データ移行の効率。家族は通常、休暇の計,画を立てるのに平均で10 ～ 20 時間を費やしています。一方、 IT チームは、小規模なデータ移行の計画にかかる時間の半分程度の時間費やしています。計画に費やす時間は、成功を保証するものではありませんが、確かなデータ移行計画を策定すれば、実際にデータを移動するときの時間を節約できます。つまり、計画段階で時間をかけることで、効率的なデータ移行ができるというわけです。
6. データー移行の成功の鍵。大規模な移行（数百万レコードまたは数百のテーブル）の場合は、成功を確保するためには、高品質なデータソフトウェアを活用することや、専門の企業を協力に迎えることが検討されます。うれしいことに、外部の企業は、ソフトウェアを賃借することで費用を節約する手助けをする可能性があります。 
7. 外部協力とソフトウェアの利用。専門の会社を協力に迎えることも検討してみましょう。そしてうれしいことに、外部の企業はおそらくソフトウェアの賃借によって費用を節約する手助けをしてくれるかもしれません。 
8. 確認と評価。他の企業の成功事例を調査することで、データ移行の手順がお客様のような組織で実際に機能するかどうかを確認してください。ただし、ベンダーが提供する一般的な手順を受け入れるだけに流されることなく、注意深く検討し、誘惑に負けないようにしてください。 
9. サプライヤおよびプロジェクト管理。ベンダーとプロジェクトを管理する必要があります。それでも日々の業務を行っている場合は、プロジェクトおよび関連するサプライヤを管理する時間を確保できるように確認しておきましょう。 
10. オブジェクト間の依存関係。現在提供されているデータ管理ツールのテクノロジと機能により、元の計画には含まれていない依存データセットについての情報は、今でも重要な意味を持ちます。オブジェクト間の依存関係は、移行プロセスが進行中でない限り見逃されてしまいますが、必ずそれらの依存関係を構築して、配信スケジュール全体が滞ることのないようにしましょう。 

「データ移行」と「データ変換」という用語は、インターネット上で同じ意味で使用される場合があるため、このことを明確にしてみましょう。実際には、異なる意味を持っています。まず、データ移行とは、場所、フォーマット、またはシステム間でデータを移動するプロセスです。データ移行には、データプロファイリング、データクレンジング、データ検証、ターゲットシステムでの継続的なデータ品質保証プロセスが含まれます。一般的なデータ移行シナリオでは、データ変換は複雑なプロセスの最初のステップ過ぎぎません。

データ変換とは、ある形式から別の形式にデータを変換するプロセスを指します。これは、レガシーアプリケーションからアップグレードされた同一アプリケーションのバージョンにデータを移動する場合、または新しい構造を持つまったく別のアプリケーションにデータを移動する場合に必要です。データを変換するには、一連の要件に基づいて、ソースからデータを抽出して変更し、新しいターゲットシステムにロードする必要があります。

データ移行と混同されることがあるもう 1 つの用語は、データ統合です。データ統合とは、異なるソースに存在するデータを結合して、ユーザに一貫性のあるデータビューを提供するプロセスのことです。データ分析には、複数のソースのデータを統合することが不可欠です。データ統合の例としては、データウェアハウス、データレイク、 NetApp ^® FabricPools があります。これは、オンプレミスのデータセンターとクラウドの間のデータ階層化を自動化したり、 AWS EBS ブロックストレージと AWS S3 オブジェクトストアの間でデータを自動的に階層化したりします。 

インフラ サービス（IaaS）への移行

• リホスト（移行と切り替え）：変更を加えることなく、 IaaS 上にデータとアプリケーションを再導入
• 修正（再設計）：新しいクラウド環境に合わせて既存のアプリケーションコードを変更または拡張
• リプレース：オンプレミスでホストおよび管理されているレガシー アプリケーションを、Office365など、クラウドでホストされている同等のアプリケーションに移行します。

プラットフォーム サービス（PaaS）への移行：

• リファクタリング：コードを挿入し、クラウド上でアプリケーションを実行します。
• リビルド：既存のアプリケーションのコードを破棄し、クラウドの上にアプリケーションを再構築します。

ビジネス要件に合った導入モデルを選択することは、あらゆるデータ移行をスムーズかつ確実に行い、パフォーマンス、セキュリティ、 ROI の点でビジネスバリューを提供するために必要不可欠です。