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

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

• データの増加に伴って他のデータがどのようにデータを惹きつけるか
• データをどのようにビジネスに統合するか
• 時間の経過に伴うデータのカスタマイズ方法

アプリケーションやデータをより有利な環境に移動するために、 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. ターゲットの完璧な仕様を待っている。実装チームが設計条件をソートする場合は、ステップ 2 と 3 を押してください。ターゲットの準備はプロジェクトの後半では重要ですが、今すぐ中止しないでください。

8. 実績のない移行手法。データ移動手順がお客様のような他の企業でうまく機能していることを確認するために、いくつかの調査を行ってください。ベンダーが提供する一般的な手順を受け入れるだけで、誘惑に負けないでください。

9. サプライヤおよびプロジェクト管理。ベンダーとプロジェクトを管理する必要があります。それでも日々の業務を行っている場合は、プロジェクトおよび関連するサプライヤを管理する時間があることを確認してください。

10. オブジェクト間の依存関係。現在提供されているデータ管理ツールのテクノロジと機能により、元の計画には含まれていない依存データセットについての情報は、今でも重要な意味を持ちます。オブジェクト間の依存関係は、移行プロセスが非常に遅くなるまで検出されないことが多いため、必ずそれらの依存関係を構築して、配送日全体が破棄されないようにしてください。

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

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

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

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

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

Platform as a Service （ PaaS ）への移行：

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

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