次の方法で共有

複雑なデータ移行の推奨ワークフロー

この記事では、大量のデータを移行する手順について説明します。 強力なクラウドベースの CRM からデータを転送する場合は、カスタム オブジェクト、データ間のリンク、一意のレコード ID など、複雑なセットアップのために慎重に計画することが重要です。 技術的な手順と、実際の移行のしくみの両方を検討する必要があります。

  • 技術的アプローチ: 整合性の確保、リレーションシップの維持、検証とエラー処理によるパフォーマンスの最適化を実現しながら、データの抽出、変換、Dataverse への読み込みなどの主要な移行手順について説明します。
  • 機能アプローチ: データのセグメント化やアーカイブなどの機能移行タスクについて説明し、ビジネス関係者がデータがニーズを満たしていることを確認する必要性を強調します。

データ移行の技術的アプローチ

整合性を維持し、中断を最小限に抑えながら、データの抽出、変換、読み込みという構造化されたアプローチに従って、スムーズな移行を実現します。

6 つの相互接続された円をステップとして持つデータ移行ワークフローを示す図。

ソースからステージング データベースへのデータの抽出

複雑なデータ移行の場合は、別のデータベース (SQL Server など) にデータをステージングすることをお勧めします。 このステージング領域は、進行中のビジネス操作を中断することなく、ソース システムのスナップショットをキャプチャします。

主な考慮事項:

  • 完全読み込みと差分読み込み: データを完全読み込みまたは増分 (差分) 読み込みとして整理します。 自動生成されたタイムスタンプを使用して、データ到着を追跡し、将来の読み込みのための変更を識別します。
  • フェールオーバー処理: 移行を停止せずに、失敗したレコード (フィールドの長さ、無効な参照など) をスキップするプロセスを設計します。 再処理する前に、問題をログに記録して解決します。
  • フィールド マッピング: データを Dataverse に移行して効率を向上させる前に、ステージング 層のターゲット形式とステージング データベースの値範囲に一致するようにソース値を変換します。
  • データの検証: 整合性チェックを実行して、参照の欠落などの問題をキャッチします。 データ抽出は数時間または数日に及ぶ可能性があるため、ステージング 層を使用して不完全なレコードをフィルター処理し、一貫性を確保します。
  • データの視覚化: ステージング データベースを使用して、最終移行の前にデータの監査と分析 (レコードのカウントや財務フィールドの合計など) を行います。

データをターゲット ステージング データベースに変換する

ソース システムからデータを抽出した後、Dataverse スキーマをミラー化し、直接挿入または更新できる値を含むターゲット ステージング データベースに変換します。

主要な変換手順:

  • フィールド マッピング: ソース列をターゲット Dataverse 列にマップします。 スクリプトを使用して、必要に応じテーブルを結合およびマージします。

  • オプションセットの変換: マッピング テーブル (OptionSetMapping など) と一括更新クエリを使用して、テキスト ベースのオプションセット値を Dataverse 整数に変換します。 ソース システムからターゲット システムへのオプション セット値の変換を標準化および自動化するテーブルを作成します。

    テーブル: オプションセットマッピング

    列名 データの種類
    ソース テーブル名 文字列
    ターゲット テーブル名 文字列
    ソース テキスト 文字列
    ターゲット テキスト 文字列
    ターゲット値 文字列

    OptionSetMapping テーブルを使用して、オプションセットの値を一括で効率的に変換および更新します。 たとえば、一致するテキスト値に基づいて Contact テーブル内のすべてのオプションセット値を更新するには、次のようにします。

    Update C.\<OptionsetValue\> = M.\<TargetValue\> 
FROM Contact C 
JOIN OptionsetMapping M 
  ON C.OptionsetText = M.TargetText 
  AND M.TargetTableName = 'Contact'

  • カスタム GUID を使用しないでください。 断片化とパフォーマンスの問題を防ぐために、Dataverse で GUID を生成できるようにします。

  • 文字列の長さのチェック: 文字列値が Dataverse の制限に適合していることを確認します。 必要に応じてトリミングまたは調整します。

  • 計算フィールド: ソースに存在しない場合は、派生フィールド (ルックアップの名前など) を追加します。

  • その他の考慮事項: Dataverse スキーマに一致するようにテーブルを設計する場合は、次のキー列とサポート テーブルを検討してください。

    • DataMigration_CreatedDateTime: データ読み込みバッチを追跡するための自動設定されたタイムスタンプ。
    • アクション フラグ: Insert (I)、Update (U)、または Delete (D) を示します。
    • 処理フラグ: 状態 (処理済み (P)、未処理 (U)、エラー (E)、成功 (S) を追跡します。
    • 一意の列: レコードをマップするには、一意の ID (ソース システムの一意の ID など) を使用します。
    • 成功/エラー テーブル: 結果をログに記録し、再試行をサポートするために、個別のテーブル (Contact_Success、Contact_Errorなど) を維持します。

シーケンステーブルとプリロードルックアップ

静的変換の後、テーブルを順番に並べて、循環依存関係を減らしてください。これは、テーブルが相互に参照し合うため、個別にインポートすることが不可能になるケースを指します。 この方法を使用します。

  • 移行の対象となるすべてのテーブルを一覧表示します。
  • テーブルごとに一意の参照をカウントします (移行しない場合は、 Created By や他のテーブル参照などの既定のフィールドは無視します)。
  • テーブルをルックアップ数で昇順に並べ替えます。
  • N:N の関連付けテーブルを含め、両方のルックアップをカウントします。
  • 複数テーブル参照 ("関連" フィールドなど) を除外します。

この方法では、データ移行の負荷のシーケンスを定義し、ほとんどのシナリオで適切に機能します。 より複雑なケースの場合:

  • 挿入時に GUID が生成される場合、ステージングと Dataverse 間でレコードを照合するために一意の識別子 (importsequencenumber など) を使用します。
  • 成功ログとエラー ログを分離して、ロックの問題を回避し、パフォーマンスを向上させます。
  • 既に移行されたテーブルから参照 GUID をプリロードして、挿入中に参照を解決します。
  • 循環依存関係を処理する方法:
    • 依存参照なしでレコードを挿入する。
    • 関連レコードの読み込み後にこれらの参照を更新する。

Dataverse にデータを読み込む

次の手順では、Dataverse にデータを読み込む方法を決定して実装します。

  1. ツール: データ サイズと複雑さに基づいてツールを選択します。

    • SDK 構成移行ツール
    • Azure Data Factory
    • KingswaySoft
    • スクライブ
    • XrmToolBox のデータ トランスポーター

  2. 主な考慮事項 (ツールに依存しない):

    • 循環依存関係の処理: 循環参照を最小限に抑えるためにシーケンス テーブルが読み込まれます。 依存参照なしでレコードを挿入し、後で更新します。

    • レコード ID の追跡: 成功テーブルで Dataverse GUID をキャプチャし、一意の識別子 (importsequencenumber など) を使用してメイン テーブルを更新します。

    • バッチ サイズとスレッド数の最適化: 一括操作のパフォーマンスを最適化するためのガイダンスを確認します。 使用するアプリケーションは、大量の要求が Dataverse に送信されたときに発生するサービス保護エラーを管理する必要があります。 独自のコードを記述し、Dataverse Web API を使用する場合は、「 サービス保護 API の制限」の説明に従って、必ず 429 エラーを再試行してください。 Dataverse SDK を使用すると、これらのエラーが管理されます。

      最適なパフォーマンスを実現するには、テーブルの複雑さに基づいてバッチ サイズとスレッド数を調整します。

      • 標準の (OOB) テーブル (取引先担当者、取引先企業、潜在顧客など): 組み込みのプラグインとジョブにより、これらのテーブルのパフォーマンスが低下します。 推奨: バッチ サイズ 200 ~ 300、最大 30 スレッド (≤10 個の参照と 50 ~ 70 列の場合)。
      • 単純なテーブル (参照の数が少ない、または参照なし): 推奨: バッチ サイズ ≤10、最大 50 スレッド。
      • 中程度に複雑なカスタム テーブル (一部の参照): 推奨: バッチ サイズ ≤100、最大 30 スレッド。
      • 大/複雑なテーブル (>100 列、 >20 参照): エラーを減らすために、バッチ サイズ 10 ~ 20、最大 10 ~ 20 のスレッドを推奨します。

  3. インフラストラクチャのヒント: データ移行のパフォーマンスを最大化するには、Dataverse 環境と同じリージョンにある仮想マシン (VM) から移行を実行します。 この方法により、待機時間が大幅に短縮され、プロセス全体が高速化されます。 Dataverse 環境のリージョンを決定する方法について説明します。

  4. エラー処理: エラーを無視しないでください。エラーを解決して、連鎖エラーを防ぎます。 プレースホルダー レコードを挿入して GUID をキャプチャするには、既定値 (空の参照、既定のオプション セット値など) を使用します。

  5. 状態の更新: 最初のレコードの挿入中にのみアクティブな状態を設定します。 非アクティブなレコードまたはカスタムの状態/状態コードの場合は、データ検証後に更新します。 ほとんどのカスタム テーブルでは、状態の更新は挿入直後に実行できます。 ただし、ケース、営業案件、潜在顧客などの特別なテーブルの場合は、移行が終了するまで状態の更新が遅れます。 これらのレコードを閉じると、再び開かなければ変更できません。これは、データの整合性を危険にさらす時間のかかるプロセスです。

  6. 所有権とセキュリティ: Dataverse のユーザー レベルと部署のセキュリティの両方が所有者の部署に関連付けられているので、データの挿入中に正しいレコード所有者を設定します。 作成時に適切な部署を割り当てます。後で更新すると、すべてのセキュリティ ロールが削除されます。

    • スタブ ユーザーを使用する:
      • Dataverse では、スタブ ユーザー (ライセンスなし) がサポートされています。これは、大規模または履歴の移行に役立ちます。 スタブ ユーザーには Salesperson セキュリティ ロールが自動的に割り当てられます。このロールの名前変更や変更は行いません。 スタブ ユーザーは、関連するテーブルへのユーザー レベルの読み取りアクセス権を持っている場合、レコードを所有できます。
    • 推奨事項:
      • 挿入時に正しい部署を設定して、移行中にライセンスのないユーザーをすべて作成します。
      • 作成後に部署を変更しないでください。これにより、Salesperson を含むすべてのロールが削除されます。
      • Salesperson ロールが、移行対象のすべてのテーブルへの読み取りアクセス権を持っていることを確認します。
      • このロールを持つ Dataverse 環境で無効になっているユーザーでも、レコードを所有できます。

  7. 通貨処理: Dataverse は履歴レートをサポートしていないため、事前検証プラグインを使用して挿入中に為替レートを設定します。

データを Dataverse に読み込む

Dataverse にデータを読み込んだ後、次の手順に従ってデータの整合性を確保し、ダウンストリームの問題を最小限に抑えます。

  1. メイン テーブルを GUID で更新します。

    • 読み込みが成功したら、 importsequencenumberなどの一意の識別子を使用して、成功テーブルからメイン テーブルに Dataverse レコード GUID をコピーします。
    • 処理フラグを更新して、レコードを次のようにマークします。
      • P – 処理済み
      • E – エラーが発生しました
      • U – 未処理この戦略は、既に処理されているレコードをスキップして効率的な再実行を可能にし、後続の読み込み時の参照解決をサポートします。

  2. 失敗したレコードを再試行する: リワークを減らし、参照整合性を維持するには、次のアクションを検討してください。

    • 文字列値が許可された長さを超える場合は、文字列値をトリミングします。
    • マッピングがない場合は、既定のオプションセット値を適用します。
    • 元の所有者が利用できない場合（スタブユーザーである場合も含む）、代替所有者を割り当てます。
    • 未解決の参照には、空白または既定値を使用します。
    • プレースホルダー レコードであっても、関連テーブルの参照に必要な GUID を生成するのに役立ちます。

データ移行にエラスティック テーブルを使用する

エラスティック テーブル は、大量のデータをリアルタイムで処理するように設計されています。 エラスティック テーブルを使用すると、スケーラビリティ、遅延、パフォーマンスの問題を発生させることなく、大量のデータをインポート、保存、分析できます。

エラスティック テーブルは、柔軟なスキーマ、水平スケーリング、および特定の期間後のデータの自動削除に固有の機能を提供します。

エラスティック テーブルは Azure Cosmos DB に格納され、サポートされます。

  • JSON 列を使用したスキーマのないデータ
  • 自動水平スケーリング
  • 古いデータの自動削除の Time to Live (TTL)
  • パフォーマンス最適化のためのパーティション分割

エラスティック テーブルは、変数スキーマを使用した一括インポートに最適です。

エラスティック テーブルは、特定のデータ型に最適です。

データの種類 Description
未加工のインジェスト データ ソース ログ、センサー フィード、またはレガシ システムからの一括エクスポート。 たとえば、従来の ERP、古い電子メール スレッド、以前のシステムからのサポート チケットからの顧客との対話ログなどです。
半構造化レコード 固定スキーマに適合しない、省略可能なフィールドまたは進化するフィールドを含むデータ。 たとえば、省略可能なフィールドを含む顧客フィードバック フォームや、カスタム ノートやタグを含むイベント登録フォームなどです。
検証用のステージング データ リレーショナル テーブルにデータを同期する前の一時的な保持ゾーン。 たとえば、メインの潜在顧客テーブルに追加される前に重複除去と検証を待機しているリード データがインポートされました。
時間の影響を受けやすいデータまたは期限切れのデータ 一時 CRM レコードの自動削除には TTL (Time-to-Live) を使用します。 たとえば、キャンペーンに関連付けられているプロモーション割引コード、顧客アンケートまたはオンボーディング ポータルの 1 回限りアクセス リンク、一時的なアンケート回答などです。
パーティション分割された一括データ ID またはカテゴリ別にデータをパーティション分割して、パフォーマンスとスケーラビリティを向上させます。 たとえば、一括データ移行中にアカウント ID またはリージョン ID でパーティション分割したり、分析のためにキャンペーン ID で顧客アクティビティ ログをセグメント化したりします。

エラスティック テーブルに適さないデータ型

エラスティック テーブルは、柔軟で大規模なシナリオ向けに最適化されていますが、すべてのデータ型が適合するわけではありません。 このセクションでは、パフォーマンス、コスト効率、保守容易性を確保するために、他の場所でより適切に保存される一般的な CRM データ パターンについて説明します。 エラスティック テーブルで現在サポートされていない機能の詳細

データの種類 理由
高度なリレーショナル データ エラスティック テーブルでは、結合や参照はサポートされていません
ビジネスに重要なレコード トランザクション整合性またはプラグインのサポートなし
複雑な検証を必要とするデータ ビジネス ルールを使用して標準テーブルでより適切に処理する

機能データのセグメント化とアーカイブ フレームワーク

効果的な技術的計画には、適切なツールとインフラストラクチャの選択、ソースとターゲットのデータ量の調整、監査と調整プロセスの設定が含まれます。 多くの移行は、事前分析が不足しているため、特に移動する必要があるデータとデータが属する場所に関して複雑になります。 このセクションでは、移行の成功をサポートするためのデータ分析の主要な原則について説明します。

データのセグメント化

データのセグメント化は、1 つの CRM システムから Dataverse に移行する上で重要なステップです。 データ テーブルを営業、サービス、マーケティングなどのビジネス機能別に整理し、移行の計画と実行を簡略化します。

テーブルのセグメント化

まず、ビジネス領域 (販売、マーケティング、サービスなど) ごとにグループ化された、移行対象のすべてのテーブルを一覧表示します。 その後、以下を実行します。

  • Excel または同様のツールでスキーマを文書化します。
  • ソース システムで基本的なクエリを実行して、列の使用状況を確認します。
  • 使用率の低い列にフラグを設定します。 値が含まれるレコードの% が 5 個未満の場合は、ビジネス関係者に相談して、保持するか破棄するかを決定します。

この単純な分析により、移行スコープを大幅に削減できます。 実行時間の長い CRM システムでは、30 から 40% の列と最大 20 個の% のテーブルを排除し、プロセスを合理化し、パフォーマンスを向上させるのが一般的です。

列の関連性

一部のソース システム列は Dataverse に直接マップされ、他の列は計算フィールドになります。 これらの列を分離し、ビジネス関係者に相談して、移行ジョブが必要かどうかを判断します。

ソース システムにのみ関連する列、またはターゲットで意味のない列は無視します。 これには、移行で特定の目的を果たさない限り、[作成者]、[変更者]、[行バージョン番号] などの多くの既定のフィールドが含まれます。

ファイルの種類のデータ

ソース システムにファイルの種類のデータが含まれている場合は、これらのフィールドに早期にフラグを設定し、別の移行戦略を計画します。 次のファイルの種類について考えてみます。

  • Office ドキュメント (Word、Excel、PowerPoint など): 最大 20,000 個のファイルについては、SharePoint などのコラボレーション プラットフォームに移行してマルチユーザー アクセスを有効にします。
  • マルチメディア ファイル (画像、ビデオなど): 再生をサポートするプラットフォームを選択します。 オプションには、SharePoint、ストリーミング サービス、またはその他のメディアに優しいストレージ ソリューションが含まれます。
  • 大量またはファイル サイズ: ストレージ コストが懸念される場合は、Azure Blob Storage または Dataverse のネイティブ ファイル列を使用します。この列では、バックグラウンドで Azure BLOB が使用されます。
  • マルウェア保護: セキュリティを確保するために、移行前にマルウェア検出ツール (Azure Advanced Threat Protection など) を使用してファイルを実行します。

ファイルの関連性を確認すると、特に実行時間の長い CRM システムでは、データ量の合計が大幅に減少し、移行がより効率的になることがよくあります。

データアーカイブ戦略

古いメール、クローズド ケース、見込み客の失格など、一部のデータは重要なままですが、ほとんどアクセスされません。 業務を中断することなく移行量を削減するには、スマート アーカイブ戦略を開発します。

手順 1: アーカイブ可能なデータを識別する

一般的な候補は次のとおりです。

  • 3 年以上前のメール
  • クローズされたケース
  • 機会の喪失
  • 見込みなしと評価されたリード
  • マーケティングの電子メール、投稿、監査ログ

システムを確認して、アーカイブできる他のテーブルを特定します。

手順 2: アーカイブアプローチを選択する

  • ソース システムにデータを保持します。 コストを削減するために、他のユーザーを非アクティブ化しながら、アクセスのためにいくつかの管理者ライセンスを保持します。
  • 外部ストレージに移動します。 ローカル データベース、Azure Blob Storage、または Azure テーブルを使用して、アーカイブされたレコードを格納します。 この方法では、ストレージと移行のコストが削減されますが、別の移行戦略が必要です。
  • 別の Dataverse 環境を使用します。 このオプションはあまり一般的ではありませんが、アーカイブされたデータを分離する場合に便利です。 この環境は後で廃止して、カットオーバー計画を簡略化できます。

Dataverse への高速で信頼性の高いデータ移行を保証するには:

  • Dataverse 環境と同じリージョンにある仮想マシン (VM) を使用して、待機時間を短縮し、移行速度を向上させます。
  • 高パフォーマンスの VM を選択します。 少なくとも、8 コア、28 GB RAM、500 GB のストレージを備えた D4 VM を使用して、大規模なデータ ボリュームを効率的に処理します。
  • VM 上のローカル データベースを優先します。 移行中はリモート接続を避けます。 Azure Data Factory を使用する場合は、最適なパフォーマンスを得るための Dataverse 環境と同じリージョンにデプロイします。

次のステップ

Power Platform の Well-Architected に従ってアーキテクチャの卓越性を実現する

  • Last updated on