組織は、合併と買収、会社の売却、データ所在地の要件、または地域のコンプライアンスニーズに基づく、Power BIのさまざまなテナント移行シナリオに直面しています。 テナントの移行は、慎重な計画、包括的なバックアップ戦略、体系的な実行を必要とする複雑な作業です。 この記事では、移行が必要かどうかを判断するのに役立つ意思決定フレームワークや、さまざまな移行パターンの詳細な実装手法など、エンタープライズ規模のPower BI テナントの移行に関するガイダンスを提供します。
Important
テナントの移行には大きなリスクがあり、広範な手動作業が必要です。 Microsoftでは、リージョンの再配置中にテナント間または同じテナント内でコンテンツを移行するための直接的なサポートは提供されません。 移行を続行する前に、テナントの完全な移行の複雑さとリスクなしに多くのシナリオに対処できるマルチ地理的な容量などの代替手段を慎重に評価します。
テナントの移行シナリオ
Power BIテナントの移行には、3 つのシナリオが含まれます。 移行を計画する前に、状況に該当するものを特定します。
| シナリオ | Description | 一般的なトリガー |
|---|---|---|
| 並行移行 (クロステナント) | 2 つの個別のMicrosoft 365 テナントが並列で動作します。 成果物は、ソース テナントからターゲット テナントに個別に移動されます。 | 2 つの組織を 1 つのテナントに統合する合併と買収。 |
| テナント分割 | 1 つのPower BI テナントは、2 つの独立したテナントに分割されます。 出発するビジネス エンティティに属する成果物、ワークスペース、ユーザーは、選択的に切り取られます。 | 事業売却と会社分割。 |
| テナントの再マップ (テナントの再配置) | Power BI テナントは削除され、同じMicrosoft 365 テナント内の新しいホーム リージョンに再作成されます。 Microsoft 365テナント ID、ドメイン、およびユーザー ID は保持されます。 詳細については、「Power BI を地理的リージョン間で移動する」を参照してください。 | テナントのホーム リージョンを特定の国/リージョンに強制するデータ所在地の要件。 |
サイド バイ サイドの移行とテナント分割は、 テナント間の 操作です。 テナントの再マップは、同じMicrosoft 365 テナント内のリージョンの再配置です。
Note
Microsoft サポートでのテナントの再マッピング (リージョン再配置) に関する考慮事項と制限事項については、「Power BI テナントを別のリージョンに移動するを参照してください。 Microsoft サポートサポートは、前のテナントの削除と、指定したリージョンへの新しいテナントの再マップに限定されます。移行のサポートは提供されません。 スクリプト化されたバックアップと復元、手動アクション、再作成と再読み込みプロセスのいずれを使用する場合でも、データとメタデータの両方のリハイドレート計画が必要です。 この手順では、バックアップが不完全な場合や成果物が省略された場合の潜在的なデータやアーティファクトの損失など、かなりのリスクが伴います。 テナントの再マップ中のダウンタイムは 3 時間から 24 時間の範囲で、成果物の復元に必要なダウンタイムが増えます。
移行前に代替手段を評価する
テナントの移行には、かなりのリスクと労力が伴います。 続行する前に、別のオプションを確認してください。 次の戦略は、テナントの移行や再配置を回避するのに役立つ場合があります。
複数地域デプロイ
multi-geo デプロイでは、テナント のホーム リージョンを変更せずに、選択したリージョンにPower BIとFabric容量をデプロイできます。 これらの容量内のデータはエンド ユーザーの近くにとどまり、同じテナントの異なるリージョンに複数の容量を持つことができます。
成果物を別のリージョンの容量に移行する方が、テナント自体を移行するよりも簡単です。 ワークスペースを別のリージョンに移動するには、ワークスペースをあるキャパシティから別のキャパシティに再割り当てします。 再割り当ては、Power BI項目に対してシームレスに行われます。
Important
Fabric項目は、異なるリージョンの容量間でのワークスペースの再割り当てに耐えられません。 ワークスペースの再割り当て前にFabric項目を削除して再作成するか、Git 統合を使用してFabric項目をバックアップおよび復元します。
次の要件については、複数地域のデプロイを検討してください。
- データ待機時間。 リージョンに容量をデプロイして、エンド ユーザーの近くにデータとコンピューティングを配置します。
- データ所在地。 データとコンピューティング リソースは、テナント リージョンではなく、キャパシティ リージョンに紐付けられています。 複数地域デプロイでは、ほとんどのワークロードのデータ所在地の境界内にデータが保持されます。
テナントのメタデータ (ワークスペース定義、セマンティック モデル メタデータ、ビジュアル メタデータ、設定、ポリシー) やMicrosoft 365ユーザー情報をデータ所在地の境界内に保持する必要がある場合にのみ、データ所在地の要件が厳密である場合にのみ、テナントの再マップを検討してください。
Dataflow Gen1 用の独自のストレージ アカウントを持ち込む
Dataflow Gen1 はAzure Data Lake Storage (ADLS) Gen2 アカウントに出力を書き込みます。既定では、Power BI テナントのホーム リージョンに配置されます。 Dataflow Gen1 ストレージの場所が唯一の所在地の問題である場合は、テナントを再配置するのではなく、必要なリージョンに独自の ADLS Gen2 アカウントを構成します。
ゲートウェイ リージョンの不一致に対するカスタム Azure リレー
容量がテナント のホーム リージョンとは異なるリージョンにデプロイされている場合、既定のオンプレミス データ ゲートウェイ エンドポイントはトラフィックをホーム リージョンにルーティングします。 ゲートウェイ トラフィックを容量リージョンに保持するには、custom Azure relayを構成します。 ゲートウェイ リージョンの不一致だけでは、テナントの移行はトリガーされません。
ビジネス ケースを確認する
テナントの移行がビジネス ニーズ (課金の統合など) によって推進される場合は、労力とリスクを結果と比較します。 小規模なテナントは簡単に移行できます。重要なFabricコンテンツを持つ大規模なテナントでは、続行する前にビジネス ニーズを再検討する必要があります。
移行でサポートされる内容
ほとんどのPower BI項目は、Power BI Admin API または Workspace Scanner API を介した定義のエクスポートをサポートしており、スクリプト化できます。 ほとんどのFabric項目は定義のエクスポートをサポートしないため、手動で再作成する必要があります。
次の表は、各成果物の種類の移行パスをまとめたものです。
| 順序 | アーティファクト | 移行経路 |
|---|---|---|
| 1 | Gateways | 移行パスはありません。 Power BI管理者がターゲット テナントで再構成する必要があります。 |
| 2 | ワークスペース | 移行パスはありません。 ターゲット テナントで再作成する必要があります。 Power BI Admin API を使用して一括作成できます。 |
| 3 | ファブリックアイテム | Git 統合をサポートする項目は、Git にコミットし、ソース ワークスペースからリンクを解除し、ターゲット テナント内の新しいワークスペースに再リンクすることでバックアップできます。 定義のみがバックアップされます。データは含まれません。 Git 統合をサポートしていない項目は、手動で再作成する必要があります。 Lakehouse の場合、メタデータのみが保持されます。デルタ テーブルとスキーマは転送されません。 |
| 4 | Dataflows | 定義 JSON をダウンロードし、ターゲット テナントに再インポートします。 Admin API を使用してスクリプトを作成できます。 |
| 5 | セマンティック モデル/データセット | ADLS Gen2 ストレージ アカウントへの バックアップと復元 を使用するか、定義をダウンロードして再インポートします。 Admin API を使用してスクリプトを作成できます。 |
| 6 | Reports | 所有者または管理者 が .pbix をダウンロード し、ターゲット テナントに再発行します。 または、JSON 定義をエクスポートします。 Admin API を使用してスクリプトを作成できます。 |
| 7 | ダッシュボード | 移行パスはありません。 手動で再作成する必要があります。 |
| 8 | Power BI アプリ | 移行パスはありません。 手動で再作成する必要があります。 |
| 9 | ページ付けされたレポート | 所有者または管理者は、RDL ファイルをダウンロードし、ターゲット テナントに 発行 します。 |
Important
アーティファクトは常にこの順序で再作成します。 ダウンストリーム成果物はアップストリーム成果物に依存し、順序をスキップすると、実行中に参照が破損する可能性があります。 Git 同期を実行すると、リポジトリに存在しないワークスペース内のすべての項目がワイプされます。
移行方法
次の参照アクティビティについて考えてみましょう。 ほとんどの手順は、3 つのシナリオすべてに適用されます。 シナリオに固有の手順は、その見出しで呼び出されます。
手順 1: 検出とインベントリの評価
成果物と依存関係の完全なインベントリを作成し、移行できる、できない、または移行してはならないものを特定します。
活動
- 次の組み合わせを使用してテナント全体の検出を実行します。
- Power BI管理 API
- Fabric 管理 API
- アクティビティ ログ (ワークスペース、レポート、データセット、更新)
- API によって公開されない項目の手動ドキュメント
- キャプチャ：
- ワークスペース (種類、容量、リージョン)
- レポート、セマンティック モデル (特に大きなストレージ形式)、データフロー
- Fabric アイテム (Lakehouse、Warehouse、Eventhouse、ノートブック)
- ゲートウェイ、データ ソース、資格情報
- 行レベル セキュリティ (RLS) ロール、ワークスペースのアクセス許可、リンクの共有
- 含まれている成果物と依存関係に基づいて、移行の複雑さ (低、中、高) で各ワークスペースを分類します。
出力
- プライマリ インベントリ スプレッドシート。
- すべてのワークスペースの移行の複雑さの分類。
手順 2: ユーザーとセキュリティの検出
ユーザー ID、ライセンス、アクセス許可をキャプチャし、必要に応じてテナント間でマップします。
テナントの再マップでは、ユーザー オブジェクト ID は保持されます。 サイド バイ サイドの移行またはテナント分割の場合、ユーザーはターゲット テナント内に異なるオブジェクト ID を持ちます。 各ソース テナント ID をターゲット テナント ID にマップします。 Power BI ライセンスの割り当てを再割り当てする（Free、Pro、PPU） 新しいMicrosoft 365 テナントのセキュリティ グループをミラー化します。
活動
識別と記録:
- Power BI ライセンスの割り当て (
Microsoft Graph ) - ソース テナント内のユーザー オブジェクト ID
- ターゲット テナント内のユーザー オブジェクト ID (並列または分割の場合のみ)
- ユーザーのアクセス許可とワークスペースのアクセス レベル
- 現在のテナント レベルの設定 (管理ポータルを使用して手動でキャプチャ)
- 現在のガバナンス構成 (秘密度ラベル、保証ポリシー)
ワークスペースと成果物のアクセス許可は、Power BI Admin API と Workspace Scanner API を使用して抽出できます。
手順 3: 利害関係者のコミュニケーションと変更管理
移行計画を早めに共有して、抵抗とサポート負荷を軽減します。
主要な利害関係者グループ
- エグゼクティブ スポンサー
- ワークスペースの所有者とレポート作成者
- 最終利用者
- IT チーム、セキュリティ チーム、ID チーム
活動
- 以下をカバーするコミュニケーション計画を策定します。
- 移行の概要と根拠。
- 何が移行され、何が移行されないか（たとえば、個人用ワークスペース、アイドル状態のワークスペース）。
- 変更内容 (URL、アクセス、更新タイミング)。 POWER BI URL を参照するダウンストリーム Power AppsリンクとSharePoint リンクも影響を受ける。
- 何が変わらないか (データ セマンティクス、ビジュアル、ビジネス ロジック)。
- 重要な日付を伝える:
- ウィンドウを固定します (通常、最終的なバックアップ中にソース テナントに変更がない状態で約 1 週間)。
- 予想されるダウンタイム (テナントの再マップ シナリオの場合)。
- 利害関係者がターゲット テナントで独自のレポートを検証するための検証期間。
- ソース テナントの切り替えマイルストーンと廃止日 (サイドバイサイド シナリオ)。
出力
- 利害関係者ブリーフィング デッキ。
- エンド ユーザーに関する FAQ。
手順 4: テナントの再マップ要求を送信する (テナントの再マップのみ)
移行日がロックされたら、 サポート チケット を送信し、特にテナントの再マップ オプションを選択します。 Microsoft サポート エンジニアが要求を受け取ります。
活動
- サポート チケットを送信します。
- Microsoftによって提供される準備チェックリストを完了します。
- 予備の時間帯を含め、移行日と時間帯を決めます。
- テナントの再マップが行われる前に、既存の容量を削除します。
予想される結果
- 一般的な再マップには約 3 時間かかりますが、合併症が発生した場合は最大 24 時間の遅延が発生する可能性があります。
- 再マップが完了すると、新しいテナントは同じテナント ID を持ち、要求されたリージョンに配置されます。
手順 5: ターゲット テナントの準備
新しく作成されたテナントまたは新しく再マップされたテナントは、コンテンツをすぐに受信する準備ができていません。 最初に構成します。
活動
- Power BI のテナント設定を構成する:
- ワークスペース作成コントロール
- 共有と外部アクセス ポリシー
- カスタム ビジュアル ガバナンス
- 秘密度ラベルと情報保護
- 監査ログと監視の有効化
- ソースと同等以上の SKU の Fabric 容量を購入してください。
- ゲートウェイ、ゲートウェイ クラスター、およびデータ接続を構成して検証します。
- サイド バイ サイドまたはテナント分割シナリオの場合:
- ソース テナント内のすべてのユーザーのターゲット テナントにユーザーを作成し、ユーザー マッピングを記録します。
- ソース テナントからユーザー グループを再作成します。
- ターゲット テナントPower BIライセンスを割り当てます。
- ガバナンスを調整する: 秘密度ラベル、Microsoft Purview統合、保証ポリシー。
手順 6: 移行パイロット
運用環境の移行の前に、代表的なサンプル ワークスペースでテスト移行を実行します。
サイド バイ サイド移行の場合、ソース テナントは再試行のフォールバックとして引き続き使用できます。 テナントの再マップの場合、再マップ前に正しくバックアップされなかったコンテンツは回復できません。 パイロット導入を成功させることは、リマップの進め方に伴うリスクを軽減するための最も重要な手段です。
パイロット ワークスペースの選択条件
- レポート、セマンティック モデル、データフロー、およびFabric項目の組み合わせが含まれています。
- 現実的なデータ ソースと更新スケジュールを使用します。
- ワークスペース レベルのアクセス許可があり、可能であれば RLS も備えていること。
- 積極的に使用されますが、ミッション クリティカルではありません。
手順 7: 移行の実行
移行を実行します。 サポートされている項目は、最初にスクリプト化されます。サポートされていない項目は手動で再作成されます。
大規模なテナントの場合は、Power BI Admin API をラップして成果物を一括エクスポートおよび一括再作成するスクリプトを記述します。
移行でサポートされている内容で定義されている順序で成果物を再作成します。 順序をスキップすると、依存関係が中断されます。
手順 8: 検証とテスト
コンテンツが正常に移行され、正しく動作することを検証します。
エクスポートされたセマンティック モデル定義には、基になるデータは含まれません。 インポートされたすべてのセマンティック モデルには、ターゲット テナントで少なくとも 1 つの手動更新が必要です。
Tip
検証中に、より高い容量の SKU に一時的にスケーリングすることを検討してください。 多数の同時更新によって、ターゲット容量が飽和する可能性があります。
活動
- データの検証: 行数、キー集計、更新の成功。
- セキュリティを検証する: RLS ルール、ワークスペース アクセス、共有スコープ。
- パフォーマンスを検証: レポートの読み込み時間、クエリの応答性、容量の余裕。
手順 9: ユーザーの切り替えと定着
ターゲット テナントにユーザーを移動し、ダウンストリーム アプリケーションを更新します。
活動
- ターゲット テナント内のワークスペースと成果物へのアクセス権をユーザーに付与します。
- Power BI コンテンツを参照する埋め込みレポートの URL、SharePoint リンク、Power Apps 接続、および Power Automate フローを更新します。
- 最終的な使用停止の前に、ソース テナント (読み取り専用フェーズ) で編集を無効にします。
- 変更内容とコンテンツの検索場所に関する短い有効化セッションを実行します。