Migrating to Microsoft Fabric is now a required step for teams using Power BI capacity. Understanding the process is key to ensure continuity, improve scalability, and take advantage of the full Fabric ecosystem.
Microsoft has officially begun the phase-out of Power BI Premium per capacity (P-SKU) licenses. This change marks a strategic shift in how Microsoft delivers business intelligence and data services, moving towards a more integrated and powerful platform: Microsoft Fabric.
Fabric is not simply a replacement for Power BI Premium. It is a broader ecosystem that brings together tools for analytics, data engineering, storage, and data science, all within a unified experience. Because of this expanded scope, legacy licenses such as the P-SKU will no longer be renewed. Organizations currently operating under a P-SKU model will be required to transition to Fabric’s F-SKU capacity to ensure continuity.
Once a current P-SKU subscription expires, Microsoft will automatically provide a 30-day grace period. During that time, users will receive an equivalent level of Fabric capacity, allowing them to migrate without service disruption. After this grace period ends, the system will continue operating but with limitations—up to a maximum of 90 days from the initial expiration date. From day 91 onward, Microsoft will block access and may permanently delete any remaining data if the migration has not been completed.
Organizations under an active Enterprise Agreement (EA) will be allowed to continue renewing their P-SKU licenses until their contract ends. However, once the agreement expires, they will be subject to the same Fabric migration process as everyone else.
How to migrate to Microsoft Fabric
To transition successfully, the first step is to purchase the appropriate Fabric capacity (F-SKU) directly from the Azure portal. It’s critical to choose a configuration that is equal to or greater than the current usage level, and located in the same data region to avoid latency or compliance issues.
Once provisioned, administrators must reassign all Power BI workspaces to this new Fabric capacity. This can be done manually via the Power BI portal or automated using PowerShell scripts or API calls. Following a successful reassignment, it’s necessary to decommission the old P-SKU capacity to prevent Microsoft from blocking or deleting it after the 90-day grace window.
For teams looking to stay ahead of this shift, a few actions are recommended today. First, verify if your organization has an active EA and determine the expiration dates associated with it. Next, calculate the Fabric capacity that will be required based on your current consumption. Purchase the new Fabric license well before the current one expires, to allow for buffer time during migration. Once acquired, plan and execute the reassignment of all workspaces, and ensure the old P-SKU is removed from your tenant before the grace period ends.
A three-phase migration plan
Preparation
Organizations should first audit their current Power BI workspaces, determine which are critical, and verify the data region each one uses. Estimating Fabric needs can be approached through suggested equivalences—P1 roughly equals F64, P2 aligns with F128, and P3 maps to F256—though a more precise assessment is encouraged based on actual usage. The new capacity should be provisioned in advance, assigned to the correct admins or user groups, and confirmed to be active.
Execution
Once the Fabric capacity is configured in Azure, each workspace must be accessed through the Power BI portal, where it can be reassigned under Settings > Advanced > Assign to capacity. After migration, teams should validate that all dashboards, reports, refresh schedules, and integrations are working as expected. It’s essential to monitor performance, user access, and third-party connections like databases or APIs to ensure everything operates correctly in the new environment.
Post-Migration
Once satisfied with the outcome, the previous P-SKU should be canceled or allowed to expire—ideally before day 90. This prevents any loss of service or data. The entire migration process should be well-documented: include key dates, details of workspace reassignment, and any configuration changes made along the way. That documentation becomes essential for auditing, continuity, and any internal knowledge transfer needed in the future.
