Dataverseの構成データ移行｜環境間移行の手順と確認点

Dataverseの環境間移行では、アプリの構成とレコードを分けて考えます。この記事では、デモ用A環境からB環境へデータを移した2022年の経験をもとに、Configuration Migration Toolによる構成データ移行の手順と確認点を整理します。

2026年10月3日更新。公式資料に基づいて本文を見直しました。掲載する旧画面は撮影当時の資料として区別しています。

このツールで移すもの・別に確認するもの

Configuration Migration Toolは、アプリの動作に必要な構成データやテストデータを環境間で移すためのツールです。取引先・連絡先などの業務データを大量に移す汎用ETLや、環境全体のバックアップ／復元と同じものではありません。用途は Microsoft公式の構成データ移行ガイド で確認できます。

対象	移行時の考え方
テーブル・列・フォームなどの構成	ソリューションで配布する。依存関係と導入順序を確認する。
構成データ・テストデータ	対象テーブル、列、関連、一意性の条件をスキーマで定義して移す。
大量の業務データ	件数、差分移行、変換、停止時間に合う別の移行方式も検討する。
接続・環境変数・ユーザー・権限など	データのインポートだけで同一になると考えず、移行先で設定・検証する。

先にソリューションと依存関係を整える

通常のALMでは、開発環境でアンマネージドソリューションを編集し、テスト・UAT・本番などへマネージドソリューションとして配布します。「どの環境にもアンマネージドをインポートすれば完了」とは言えません。詳細は ソリューションのALM概念 を参照してください。

移行先に必要なテーブル・列・関連が存在することを確認し、依存するソリューションを先に導入します。接続参照、環境変数、クラウドフロー、外部サービスの接続先も確認対象です。

構成データ移行の手順

• 準備：公式ガイドからConfiguration Migration Toolの入手方法を確認します。旧記事の固定バージョンに合わせる必要はありません。移行元・移行先の権限を確認し、重要な移行の前に復旧手段を準備します。
• スキーマ作成：移行元へ接続し、対象テーブル・列・関連を選びます。既存レコードと照合する一意性の条件も定義します。
• エクスポート：定義したスキーマに従ってデータを書き出し、出力ZIPとログ、対象件数を確認します。
• インポート：移行先を確認してZIPを読み込みます。既存データと照合する条件によって、更新されるレコードと新規作成されるレコードが変わります。
• 検証：完了メッセージだけで判断せず、件数、参照関係、代表レコード、アプリの業務操作を確認します。

一意性と関連データで注意すること

一意性の条件は、移行先のどのレコードを更新するかに関わります。公式ガイドでは、条件を指定しない場合はテーブルのプライマリ名フィールドが照合に使われると説明されています。同じ表示名を持つレコードがある場合など、既存データに合う条件かを事前に検証します。

ツールは関連を扱うために複数のパスでインポートします。それでも、対象外のテーブルや未導入の構成まで自動的にそろうわけではありません。ログのエラー・警告と、関連先が意図したレコードになっているかを確認してください。

インポート後のチェックリスト

• 対象件数と主要な値が移行元・移行先で整合している。
• ルックアップなどの関連先と、既存レコードへの更新結果が正しい。
• 接続参照と環境変数が移行先用になっている。
• 利用者のライセンス・権限と、フローや外部連携の動作を確認できる。
• 業務担当者が代表シナリオを実行し、移行結果を受け入れられる。

2022年のデモ環境での実施記録

当時はA環境からエクスポートしたZIPをB環境へインポートしました。画面に記録された51テーブル・41秒という値は、そのデータ量と環境でのエクスポート結果です。一般的な移行時間や性能を保証する値ではありません。

ソリューションとデータの移行を終えても、B環境がA環境と完全に同一になるとは限りません。上記の設定確認と検証までを移行作業に含めます。

2022年当時の画面資料

以下は初回公開時（2022年）のスクリーンショットです。ソリューションのエクスポート／インポートと、スキーマ作成・データ出力・データ取り込みの操作を保存しています。現在の画面や提供条件と一致することを保証するものではありません。