データ移行とは、ある場所から別の場所、ある形式から別の形式、またはあるアプリケーションから別のアプリケーションにデータを移動するプロセスです。これは、通常、新しいシステムを導入する際やデータの保存場所を変更する際に行われます。つまり、データを新しい環境に移すことを指します。ビジネスの推進要因となるのは、通常、アプリケーションの移行や統合です。この場合、従来型システムを交換したり、同じデータセットを共有する新しいアプリケーションによって拡張したりします。企業がオンプレミスのインフラやアプリケーションからクラウドベースのストレージやアプリケーションに移行し、自社を最適化したり変革したりする中で、データ移行が始まることがよくあります。
簡単に言ってしまえば、理由は「データの重力」です。データの重力という概念は以前からありましたが、クラウド インフラへのデータ移行が進むにつれて、課題はますます重要になってきています。言い換えると、データの重力とは次のような特徴を持つ現象を指します。
アプリケーションやデータをより有利な環境に移動するために、Gartnerはデータの重力を克服する手段として、「データとアプリケーションの分離」を推奨しています。プロジェクトの開始時に時間をかけてデータやアプリケーションの複雑さを解消することで、データ管理を改善し、アプリケーション モビリティを実現し、データ ガバナンスを改善できます。
主な問題は、すべてのアプリケーションがデータ管理階層にアプリケーション ロジックの要素を導入することでデータ管理が複雑化され、各アプリケーションが次のデータ ユースケースには対応しなくなることです。ビジネス プロセスでは、データを個別に使用し、独自の形式を出力して、次のプロセスのための統合を維持します。そのため、アプリケーション設計、データ アーキテクチャ、ビジネス プロセスはすべて相互に対応する必要がありますが、場合によっては、これらのいずれか1つが対応しなくなることがあります。これにより、アプリケーション管理者は理想的かつシンプルなワークフローを諦めて、ベストではない設計を選択しなければなりません。また、当面の対応策が必要になる場合もありますが、この技術的な課題は、最終的にはデータ移行または統合プロジェクトのプロセスにおいて対処する必要があります。
このような複雑さを踏まえて、適切なレベルの専門知識とリソースを取得できるように、データ移行を「戦略的武器」として推進することを検討してください。プロジェクトがニーズに確実に対応できるように、移行の中で最も注意が必要な要素、つまりレガシー システムがオフになるという事実に焦点を当てれば、主要な関係者にも確実に関心を持ってもらうことができます。
システムのアップグレードやデータセンターのクラウドへの拡張には、ビジネス上のさまざまなメリットがあります。多くの企業にとって、これは非常に自然な進化です。クラウドを利用している企業は、業務上の優先事項にスタッフを集中させ、売上の増加を促進し、俊敏性を高め、設備投資を削減し、必要な分だけ料金を支払うことができるようにしたいと考えています。ただし、実施される移行の種類によって、他のプロジェクトで作業するために IT スタッフのまず、移行のタイプを定義します。
まず、移行のタイプを定義します。
データの移行、以下の 3 つの基本的な手順
重要なデータや機密データの移動やレガシーシステムの運用停止は、関係者のエッジに配置される可能性があります。確かな計画を持っていることは必須ですが、車輪を改革する必要はありません。データ移行計画やチェックリストの例は Web で多数確認できます。たとえば、データ移行スペシャリストのコミュニティである Data Migration Proには、 包括的なチェックリストがあります。
これは膨大な量の作業と思われるかもしれませんが、す7 段階のプロセスの概要を示すべてのデータ移行にこれらの手順が必要とされるわけではありません。それぞれの状況は異なり、企業ごとに異なるアプローチを採用しています。
データ移行は数十年にわたってITの生命線であり続けてきたにもかかわらず、移行の問題は毎年報告されています。企業のデータ移行には、以下に挙げる10の課題があります。
主要な利害関係者への通知不足：移行の規模に関係なく、データを移動することに敏感な反応をする人もいます。このような関係者を事前に把握して、このプロジェクトの必要性やプロジェクトへの影響をあらかじめ説明しておきます。事前に説明をしておかないと、関係者からプロジェクトの途中で待ったをかけられ、進行が妨げられる可能性も出てきます。
ビジネス関係者への連絡不足：プロジェクトを関係者に説明したら、常に進捗状況を伝えるようにしておきます。毎週同じ日にステータス レポートを作成することをお勧めします。特に、状況が予定どおりに進んでいない場合は、このレポートを作成する必要があります。定期的なコミュニケーションは、影響を受けるすべての人々との信頼関係を構築するために欠かせません。
明確なデータ ガバナンスの欠如：ソース システムのデータを作成、承認、編集、削除する権限を持つユーザを明確に把握し、プロジェクト計画の一部として文書化しておきます。
専門知識の不足：データの移動自体は単純な作業ですが、実際には多くの複雑なプロセスが伴います。経験豊富な専門家のアドバイスや充実した参考資料があれば、プロセスをスムーズに進めることができます。
計画性の欠如：家族で休暇をとる場合、平均すると10～20時間が計画に費やされると言われていますが、ITチームが小規模なデータ移行の計画に費やす時間は、おそらくその半分程度でしかないでしょう。計画に費やす時間で成功が保証されるわけではありませんが、明確なデータ移行計画を策定しておけば、実際にデータを移動するときの時間を節約できます。
データ準備のためのソフトウェアとスキルが不十分：数百万件のレコードや数百個のテーブルを扱うような大規模な移行の場合は、最高クラスのデータ品質を保証するソフトウェアに投資してください。また、外部の専門企業と契約してアドバイスを受けることも検討してください。外部企業からソフトウェアをレンタルすることで、費用を節約できる場合もあります。
ターゲットの完璧な仕様を待つ：実装チームが設計条件を選別している場合は、ステップ2と3を積極的に進めます。ターゲットの準備はプロジェクトの後半では重要になりますが、プロセスを中断させないようにしてください。
実績のない移行手法：データ移動の手順がお客様のような他の企業でうまく機能していることを確認するために、いくつかの調査を行います。ベンダーが提供する一般的な手順をそのまま採用することは避けてください。
サプライヤおよびプロジェクトの管理：ベンダーとプロジェクトを管理する必要があります。日々の業務も並行して行っている場合は、プロジェクトおよび関連するサプライヤを管理する時間を確保してください。
オブジェクト間の依存関係：現在提供されている管理ツールのテクノロジと機能を利用しても、元の計画には含まれていなかった依存データセットが見つかることがあります。オブジェクト間の依存関係は、移行プロセスの後半に進むまで判明しないことが多いため、必ずコンティンジェンシー プランを構築しておき、全体の納期に支障が出ないようにしてください。
「データ移行」と「データ変換」という用語は、インターネット上で同じ意味で使用される場合があるため、このことを明確にしてみましょう。実際には、異なる意味を持っています。まず、データ移行とは、場所、フォーマット、またはシステム間でデータを移動するプロセスです。データ移行には、データプロファイリング、データクレンジング、データ検証、ターゲットシステムでの継続的なデータ品質保証プロセスが含まれます。一般的なデータ移行シナリオでは、データ変換は複雑なプロセスの最初のステップ過ぎぎません。
データ変換とは、ある形式から別の形式にデータを変換するプロセスを指します。これは、レガシーアプリケーションからアップグレードされた同一アプリケーションのバージョンにデータを移動する場合、または新しい構造を持つまったく別のアプリケーションにデータを移動する場合に必要です。データを変換するには、一連の要件に基づいて、ソースからデータを抽出して変更し、新しいターゲットシステムにロードする必要があります。
データ移行と混同されることがあるもう 1 つの用語は、データ統合です。データ統合とは、異なるソースに存在するデータを結合して、ユーザに一貫性のあるデータビューを提供するプロセスのことです。データ分析には、複数のソースのデータを統合することが不可欠です。データ統合の例 としては、データウェアハウス、データレイク、 NetApp ® FabricPools があります。これは、オンプレミスのデータセンターとクラウドの間のデータ階層化を自動化したり、 AWS EBS ブロックストレージと AWS S3 オブジェクトストアの間でデータを自動的に階層化したりします。
プラットフォーム サービス（PaaSへの移行：
ビジネス要件に合った導入モデルを選択することは、あらゆるデータ移行をスムーズかつ確実に行い、パフォーマンス、セキュリティ、 ROI の点でビジネスバリューを提供するために必要不可欠です。
アプリケーションをクラウドの新しいサービスと統合し、技術的負債の一部を解消することもできます。