Skip to main content

Review rationalization decisions in Microsoft Fabric

Last updated: 02/28/2023 (adapted for Microsoft Fabric)

During the initial strategy and planning stages, we suggest applying an incremental rationalization approach to your Fabric estate. However, this method naturally embeds assumptions. It’s important for the Fabric strategy and adoption teams to revisit these decisions based on the detailed documentation of workloads—especially as business stakeholders and sponsors are brought in to define the future state.

Note
Further validation will happen in the Fabric workload assessment phase. This includes business-driven reviews of rationalization logic to align resources and plans effectively.

Validate rationalization decisions​

To validate decisions, use the following questions to structure conversations with business teams. The questions are grouped into innovation indicators and migration indicators to support Fabric-specific workload planning.

Innovation indicators in Microsoft Fabric​

If the answers to the following questions are yes, a workload might be better treated as a candidate for innovation, meaning the business logic or data models would be re-implemented in Microsoft Fabric, rather than simply lifted and shifted.

  • Does this workload create differentiated data products or reports that drive market advantage?
  • Has there been investment approval to enhance the user experience of Fabric-based reports, dashboards, or data apps?
  • Does the data in this workload unlock new business models, predictive insights, or real-time intelligence scenarios?
  • Has there been a business push to activate new insights or AI scenarios with this dataset?
  • Can the business value of the new reports, models, or products be quantified and used to justify a deeper transformation?
  • Will semantic models, dataflows, or notebooks be rearchitected as part of the Fabric adoption effort?
  • Is this workload already integrated into a CI/CD deployment (e.g., through Fabric Git integration or VS Code pipelines)?

If the answer to any of these is "yes", the workload should be flagged as an innovation workload and scheduled for architectural review to identify Fabric-native modernization opportunities.

Migration indicators in Microsoft Fabric​

Migration in Fabric typically refers to "replatforming" existing BI, data warehouse, or analytics workloads with minimal refactoring, such as moving Power BI datasets or SQL warehouses to Fabric Capacities.

Use the following questions to assess if a migration-first approach is more appropriate:

  • Is the Power BI solution or dataset already considered stable, with limited change expected during this phase?
  • Is the Fabric workload already used in production, and will that continue?
  • Are the primary goals cost reduction (e.g., via unified Fabric Capacities), simplified architecture, or improved governance?
  • Does this workload suffer from performance or availability issues in its current platform (e.g., legacy SQL, Azure Synapse)?
  • Is operational complexity (e.g., siloed pipelines, overlapping tools) a key challenge?
  • Is the need for innovation limited by current IT or architecture constraints?

If yes, migrate the workload to Fabric with minimum viable modernization (e.g., switch to Lakehouse, integrate with Data Activator, unify with centralized semantic models). After migration, additional innovation can follow as the Fabric-native capabilities mature.

Important
Migration efforts may still include incremental modernization, such as moving pipelines to Data Factory in Fabric, adopting Lakehouse storage in OneLake, or reconfiguring to leverage capacity-based compute. Only material redesigns of business logic classify as innovation.

Update the Fabric adoption plan​

The skills needed to migrate a Power BI dataset or move a warehouse to Fabric are different from those required to innovate using notebooks, real-time events, or AI-powered transformations.

We suggest managing innovation and migration efforts in separate tracks, each with distinct iterations and release cadences.

In Azure DevOps, you can reflect this by setting the parent work item (epic) to "Fabric Migration" or "Fabric Innovation". This distinction keeps the scope manageable and ensures proper team alignment.

For large-scale Fabric programs with multiple domains, also consider:

  • Assigning workloads to iteration paths per team
  • Organizing teams by Fabric Domains (e.g., Reporting, Governance, Real-time Intelligence)
  • Using Azure Boards Area Paths to limit task visibility and reduce overhead

This approach simplifies coordination while maintaining visibility into transformation progress across the full Fabric estate.

Contributors