Microsoft は、Power BI Premium の容量単位 SKU (P SKUs) を廃止します。 各 P SKU サブスクリプションは現在の契約期間の終了時に終了し、Microsoftは新しい P SKU を販売しなくなります。 Power BI ワークロードを引き続き実行するには、Microsoft Fabric の容量 SKU (F SKU) に移行してください。 この記事では、移行のエンド ツー エンドのビューを提供します。Fabric F SKU が今後のパスである理由、エンド ユーザーと管理者に対してどのような変更と変更が同じままであるか、一般的な移行の段階、移行の複雑さを決定するシナリオです。
この記事は、移行を計画して実行するFabric管理者、Power BI管理者、IT アーキテクト、容量所有者を対象としています。
Important
P SKU サブスクリプションが終了する前に、移行を完了することを計画します。 サブスクリプションが終了すると、容量は 30 日間の猶予期間に入ります。 31 日目から、アクセスが制限されます（対話型操作に遅延が発生します）。 91 日目以降は、すべての操作が拒否されます。データは保持されますが、ワークスペースを Fabric F SKU 容量に移行するか、容量を削除するまでアクセスできません。 中断を回避するには、P SKU サブスクリプションが終了する前に、ワークスペースを Fabric F SKU 容量に再割り当てします。 手順については、「Power BI Premium から Microsoft Fabric にワークスペースを移行する」を参照してください。
Note
Enterprise Agreement のお客様。 Enterprise Agreement がまだアクティブな場合は、EA 期間が終了するまで、既存の P SKU 容量を引き続き実行し、契約を通じて毎年更新できます。 期限切れの Enterprise Agreement または Microsoft Cloud 契約のお客様は、契約を通じて新しい P SKU 容量を追加または購入することはできません。 移行する時期を決定する前に、Microsoft アカウント担当者に特定の契約条件を確認してください。
Note
この廃止の適用範囲には、次の2つの重要な制限があります。
- ユーザーごとのライセンスは影響を受けません。Power BI Proと Power BI Premium Per User (PPU) は引き続き as-is。 詳細については、「Power BI Premium Per User (PPU) も廃止されますか?」を参照してください。
- 埋め込みライセンス (EM、A) は影響を受けません。 これらの SKU は、この廃止の一部ではありません。
- ソブリンクラウドはまだ影響を受けていません。 Microsoft Fabricはソブリン クラウドでは使用できないため、P SKU は引き続きサポートされます。 Microsoftでは、これらの環境でFabricが使用可能になったときに個別のガイダンスを提供します。
Microsoft Fabricに移行する理由
P SKU の廃止は即時のドライバーですが、Fabric F SKU は、P SKU では実現できない機能も提供します。
- 使用した分だけ支払えばよいのです。 F SKU では、既定では Azure の従量課金が適用され、予測可能なワークロード向けに、オプションで年単位または複数年単位の予約も利用できます。 また、時間外に課金を停止するためにアイドル状態のときに容量を一時停止し、後でオンデマンドで再開することもできます。
- いつでもスケールアップまたはスケールダウンできます。 サブスクリプションの期間の固定サイズにコミットするのではなく、ワークロードの変化に合わせて、Azure ポータルを使用して容量のサイズを変更します。
- Azureネイティブの運用モデルを使用します。 Azure portal を通じて容量のプロビジョニングと管理を行い、チャージバック用の Azure タグを適用し、Fabric の支出を Microsoft Azure Consumption Commitment (MACC) に算入できます。 多くのFabricワークロード (Lakehouses、Warehouses、Notebook、Data Factory パイプラインなど) は P または F のいずれかの容量で実行されますが、Azure運用モデルは F 専用です。
- 個別の SKU を使用せずにPower BI Embeddedを使用します。 埋め込みシナリオはすべての F SKU でカバーされるため、個別の EM または A SKU は必要ありません。
- Azureネイティブのセキュリティと操作を使用します。 マネージド プライベート エンドポイント、信頼されたワークスペース アクセス、Azure Monitor、Microsoft Cost Managementはすべて F SKU で使用できます。
機能ごとの完全な比較については、「Power BI Premium P SKU と Fabric F SKU の主な違い」を参照してください。
何が変わり、何が変わらないか
移行には、主にライセンスとインフラストラクチャの変更が含まれます。 エンド ユーザー エクスペリエンスとほとんどの管理動作は同じままです。 一部の運用領域は変更されます。
| 面積 | 変更。 | F SKU に移行した後 |
|---|---|---|
| レポート、セマンティック モデル、ダッシュボード | 同じ | F64 以上の容量で変更せずに作業を続けます。 |
| ユーザー ライセンス (Pro、PPU、無料) | 同じ | 変更なし。 F64 以降では、Fabric無料ライセンスとビューアー ロールを持つユーザーは、P SKU と同じようにコンテンツを表示できます。 F2 から F32 では、すべてのビューアーに Pro または PPU ライセンスが必要です。 |
| ワークスペースとアプリ | 同じ | ワークスペースは新しい容量に再割り当てされます。 ワークスペース アプリ、デプロイ パイプライン、Git 統合は引き続き機能します。 |
| スケジュールとパイプラインを更新する | 同じ | 引き続き新しい容量で実行します。 再割り当て中にアクティブな更新が中断される場合があります。 |
| Power BI Report Server | ライセンスの変更に伴う同じ | Fabric 容量予約または Software Assurance 付きの SQL Server Enterprise Edition で、引き続きご利用いただけます。 |
| Power BI Embedded | 同じ、より簡単 | すべての F SKU に含まれます。 EM 用と A 用の別個の SKU は不要です。 |
| 購入と請求 | Changes | Microsoft 365コミットメント課金からAzure課金に移行します。 F SKU では、従量課金制と年単位または複数年の予約がサポートされます。 |
| 容量管理 | Changes | 主にFabric ポータル (ワークスペースの割り当てと容量レベルの設定) で管理されます。 一時停止、再開、スケールアップ、スケールダウンの操作は、Azure ポータルを使用して実行されます。 |
| Autoscale | Changes | F SKU に P SKU 自動スケールが存在しません。 代わりに、F SKU はオンデマンドのサイズ変更を使用します。Azure ポータルを使用して手動でスケールアップまたはスケールダウンします。 |
| 容量ガバナンス | 新機能 | ワークスペース レベルのサージ保護や容量超過保護など、F SKU で新しいコスト ガバナンス機能を利用できます。 これらを使用して消費を制御し、暴走コストを防ぎます。 |
| リージョン間項目のサポート | 新しい考慮事項 | 標準Power BI項目は、リージョン間の再割り当て後も存続します。 大規模なストレージ形式のセマンティック モデルでは、再割り当て前に、バックアップと復元または消去と小さなストレージ形式への変換が必要です。 すべての Fabric アイテム（Lakehouses、Warehouses、Notebooks、Data Factory パイプライン）があると、再割り当ては失敗します。 |
移行の過程の概要
最も純粋な形式では、P から F への移行は、同じAzure リージョン内の同等の F SKU に 1 対 1 で移行されます。 多くの場合、お客様は、容量の統合、リージョン間の移動、またはサイズ変更の機会として移行を使用します。 これらの変更のそれぞれにより、複雑さとリスクが増します。 これらの変更は、ライセンス移行の完了後に実行される個別のワークストリームとして扱います。
移行は、サイズや複雑さに関係なく、同じ 5 つのステージに従います。
- 決定。 移行するタイミング、開始する F SKU、および同じAzure リージョンにとどまるかどうかを選択します。 Premium P SKU の移行決定ガイドPower BI参照してください。
- 計画。 ワークスペースを棚卸しし、Microsoft Fabric Capacity Metrics app を使用して CU 使用量のベースラインを把握し、Fabric SKU Estimator を使用して将来の使用量を見積もります。 Azureに
Microsoft.Fabricリソース プロバイダーを登録し、パイロット ワークスペースを選択します。 購入前にハンズオン検証を行う場合は、ワークロードをテストするためにFabric試用版の容量をプロビジョニングします。 - 提供。 何かを再割り当てする前に、F SKU を購入します。 従量課金制または予約を選択し、使用する場合Power BI Report Serverライセンスを確認します。
- 移行して検証します。 Fabric管理ポータルで、または容量移行ノートブックを使用してワークスペースを再割り当てします。 リージョンをまたがる移動の場合は、新しいリージョンに大きなストレージ形式のセマンティック モデルとFabric項目を再作成します。 更新、レポート、ゲートウェイを検証します。 「Power BI Premium から Microsoft Fabric にワークスペースを移行する」を参照してください。
- 廃止して運用する。 P SKU の取り消しは手動で行います。Fabricは、F SKU をプロビジョニングするときに P SKU の使用を自動的に停止しません。 移行を検証したら、Microsoft 365 管理センターで P SKU サブスクリプションを明示的に取り消します。 その後、Microsoft Cost Managementを使用してコスト監視を設定し、Fabricの一時停止、再開、スケーリングの柔軟性を活用します。
移行シナリオ
ほとんどのお客様は、次の 4 つのシナリオのいずれかに分類されます。 最初の 3 つのシナリオは、「ワークスペースを Power BI Premium から Microsoft Fabric に移行する」の標準的な移行手順に従います。
| シナリオ | Complexity | Notes |
|---|---|---|
| 同じテナント、同じリージョン | 低 | 推奨される既定値。 各ワークスペースを新しい F SKU に再割り当てします。 アクティブな更新とは別に、予想されるダウンタイムをゼロにします。 |
| 同じテナント、リージョン間 | 中程度から高 | 標準的な移行手順に従いますが、大きなストレージ形式のセマンティック モデルとFabric項目は、Git にバックアップまたはキャプチャし、新しいリージョンで削除して再作成する必要があります。 「リージョン間の移行: 特別な処理」を参照してください。 |
| Multigeo（異なるリージョンにまたがる複数の F SKU、同じテナント） | Moderate | 標準的な移行手順に従いますが、各ターゲット リージョンで F SKU を購入し、リージョン固有のコンテンツのガバナンスを計画します。 Multigeo の移行に関する説明を参照してください。 |
| テナント間 | 高い; ワンクリック移行はサポートされていません | 標準の移行手順には従いません。 ゲートウェイ、セマンティック モデル、ワークスペース、レポート、アプリ、ダッシュボードを手動で再作成する必要があります。 最初に multigeo を検討してください。 テナント間の移行に関するページを参照してください。 |
Caution
リージョン間の移行には、同じリージョンの移行よりも大幅に多くの作業が必要です。 リージョン間の再割り当てに耐えない項目の種類以外に、次の点を計画します。
- Fabric の項目は、リージョンをまたいで移動することはできません。 Lakehouses、Warehouses、Notebooks、および Data Factory パイプラインは、再割り当てに失敗する原因となります。 再割り当て前に定義を Git にキャプチャ (またはエクスポート) してから、ターゲット リージョンで再作成します。
- レポートの再関連付け。 大規模なストレージ形式のセマンティック モデルをバックアップおよび復元 (または削除して再デプロイ) すると、再作成されたモデルは新しい GUID を取得します。 元のモデルを参照したレポートは、再作成されたモデルにリバインドする必要があります。
- ゲートウェイのオーバーヘッド。 多くの場合、リージョン間ターゲットでは、オンプレミスデータ ゲートウェイの追加の構成と検証が必要になります。特に、ゲートウェイが Bring Your Own Relay (BYOR) でAzureリレーを使用する場合は、リレー エンドポイントがリージョンにバインドされているためです。
リージョン間の移行は、データ所在地または別のハード制約で必要な場合にのみ選択します。 同じリージョンへの移行が推奨される既定値です。
移行後
ワークスペースを再割り当てし、レポートと更新処理が新しい F SKU で動作することを確認したら、P SKU を解約する前、および任意のモダナイゼーション作業に着手する前に、安定化期間を設けてください。 次のアクティビティは、移行が正常に移行されたことを確認し、次に何を行うかを決定するのに役立ちます。
コストの安定化
F SKU のコストは、容量を常時稼働させたままにしておけば予測しやすくなります。 月額料金は安定していますが、従量課金制の料金は通常、同等の P SKU よりも高くなります。 安定して稼働するワークロードには予約を利用してコスト削減を確保し、1日のうち一部の時間帯で実際にアイドル状態となる容量には一時停止と再開を使用します。 コストを安定させるために:
- Microsoft Cost Managementを使用して、最初の 30 日間の毎日の支出を追跡します。
- Azure予算とアラートを容量のリソース グループに設定して、支出が計画を超える前に通知されるようにします。
- 1日あたりの使用量が安定したら、Fabric の年間容量予約を評価します。 予約は通常、予測可能なワークロードを割引します。
- 業務時間外にアイドル状態になっている容量を一時停止して、それらの期間に課金を停止します。
パフォーマンスの安定化
同等の F SKU への 1 対 1 のリージョン内移行の場合、CU の使用は、安定化後の P SKU ベースラインと密接に一致する必要があります。 移行に構成の変更 (異なるリージョン、異なる SKU サイズ、ワークロードの統合) が含まれている場合は、パフォーマンスの変動が予想され、P SKU を使用停止する前に検証します。 移行後に報告されるオーバーロードは、多くの場合、移行自体ではなく、ワークロードの変更 (更新のバースト、コンテンツの追加、更新スケジュールの変更) によって発生します。 F SKU が原因であると想定する前に、使用パターンを確認してください。 パフォーマンスを安定させるには:
- カットオーバー後 1 ~ 2 週間、Microsoft Fabric容量メトリック アプリで新しい容量を監視します。
- P SKU でキャプチャしたベースラインと比較します。 サイズを変更する前に、更新頻度、データセットのサイズ、または対話型の負荷に大きな変化がないか確認してください。
- スロットリングが継続的に発生する場合は、Azure ポータルからオンデマンドでスケールアップしてください。 容量のスケーリングを参照してください。
- ベースラインを最終版として扱う前に、完全なビジネス サイクル (月末と四半期ごとのクローズを含む) 全体を検証します。
- 重要な新しいコンテンツを追加したり、更新スケジュールを変更したりするたびに、ベースラインを再確認します。
- エンドで構成が変更された後に再検証します (SKU サイズ、リージョン、ワークロードの割り当て)。
- 容量の増加とガバナンスの計画に関するより広範なガイダンスについては、容量計画ガイドMicrosoft Fabric参照してください。
運用とガバナンスを確認する
一部の操作設定は、ワークスペースが F SKU に移動したときに自動的に引き継がれない場合があります。 次の項目を確認してください。
- 適切な管理者が管理できるように、容量リソースの Azure RBAC 割り当てを確認します。
- P SKU でカスタマイズされた場合は、Fabric管理ポータルで容量レベルのワークロード設定 (セマンティック モデルのメモリ制限など) を再適用します。
- ユーザーは Fabric アイテムを作成できます テナント設定と、任意の容量スコープの委任を再確認してください。
- チャージバック レポートとショーバック レポートで支出が適切なコスト センターに割り当てられるように、容量リソースに Azure タグを適用してください。
- F SKU で使用できる新しい容量使用ガバナンス機能 (ワークスペース レベルのサージ保護や容量超過保護など) を評価して、容量をより広範な消費に開放する前にガードレールを設定します。
モダン化の機会を探る
多くのFabricモダン化シナリオは、P SKU でも技術的に可能です。 F SKU の変更点は、運用モデルです。Azureネイティブのコスト管理、容量ガバナンス機能 (サージや超過分の保護など)、統合されたAzure RBAC により、より明確なコスト ガードレールと運用上の信頼度でこれらのシナリオを簡単に実行できます。 これらのオプションは オプションのフォローアップであり、移行要件ではありません。
- ミラーリングとショートカットを使用して、既存のデータ を OneLake に取 り込みます。
- ワークロードの利点がある DirectQuery セマンティック モデルを Direct Lake に変換します。
- Fabricワークロード全体の統合データ アクセス制御に OneLake セキュリティを採用します。
これらのオプションは、ライセンス移行の完了後に実行される個別のワークストリームとして扱います。 それらは移行を妨げず、その期間を長引かせるべきではありません。