Guidance Needed - End-to-End Migration Lifecycle — Pre-Migration to Post-Migration
'd also appreciate guidance on the complete migration lifecycle, from planning through post-migration support. Pre-Migration Assessment: How do you inventory and assess 400+ SSRS reports, identify dependencies, document business logic, analyze report usage, and decide which reports to migrate, consolidate, or retire? Migration Planning and Design: How do you map existing SQL tables, stored procedures, SSRS expressions, and report-level queries to reusable Power BI semantic models, DAX measures, and the target architecture? Migration and Development: What is the recommended approach for migrating reports in phases, building shared semantic models, implementing security, and eventually transitioning data pipelines to Microsoft Fabric? Testing and Validation: How do you reconcile SSRS and Power BI results, validate business calculations, test performance and security, and obtain business-user sign-off? Deployment and Cutover: How do you manage development, test, and production environments, deployment pipelines, parallel report availability, user acceptance testing, and the retirement of legacy SSRS reports? Post-Migration Support and Optimization: How do you monitor refresh failures, report performance, data accuracy, user adoption, and production issues? What documentation, knowledge transfer, and support processes should be in place? Governance and Continuous Improvement: How can Microsoft Purview or other tools help maintain business definitions, data lineage, report ownership, and centralized documentation as the organization moves toward Fabric? For anyone who has completed a similar enterprise migration, what methodology, tools, checklists, or lessons learned would you recommend at each stage?
How are teams handling AI-driven automation around Power BI Embedded applications?
I’m exploring patterns for adding AI-driven automation around Power BI Embedded applications. For example: Power BI Embedded → user interaction → backend/API event → AI analysis → business action I’m particularly interested in how teams are handling: event-driven actions from embedded reports calling backend APIs securely using AI to summarize or interpret report context triggering workflows based on report interactions authentication with service principals or managed identities keeping the architecture maintainable in production Are there recommended patterns for combining Power BI Embedded, Fabric APIs, and AI services without putting too much logic into the client application?
Dashboard Rendering Issue – Existing Dashboard Tiles Changed
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Description We are experiencing an unexpected rendering issue in Power BI Service dashboards. Several existing dashboards that had been functioning correctly for a long time have recently changed their appearance without any modifications made by report authors, dashboard owners, workspace administrators, or tenant administrators. Environment Product: Power BI Service / Microsoft Fabric Dashboard theme: Custom dark theme (ALS corporate branding) Reports published and functioning correctly Issue observed in multiple dashboards Multiple users affected Problem Details The underlying reports display correctly and retain the intended formatting. However, dashboard tiles have unexpectedly changed appearance: White background areas appear within visuals that previously had transparent or dark backgrounds. Some visuals no longer respect the original report styling. Dashboard appearance changes depending on the selected dashboard theme. When switching the dashboard from dark theme to light theme, affected visual areas change color accordingly, suggesting that dashboard theme rendering is overriding or incorrectly applying visual formatting. No reports have been republished. No dashboard tiles have been re-pinned. No changes have been made to visual formatting settings. No known administrative or tenant-level changes were performed before the issue appeared. Expected Behavior Existing dashboard tiles should maintain their previous appearance and continue rendering consistently with their saved configuration. Actual Behavior Dashboard tiles are rendered differently than before, displaying unexpected background colors and theme-driven formatting changes. Troubleshooting Performed We verified that: The underlying reports render correctly. Visual formatting inside reports has not changed. The issue is visible only on dashboards. Multiple users observe the same behavior. Reopening the dashboard does not resolve the issue. No recent report publication or dashboard modification was performed. Potential Cause The issue appears related to dashboard theme rendering within Power BI Service rather than report configuration.
Developer mode & git for reports with live connection
Hello! I currently have two reports that share the same dataset published, hence are connected to that dataset via live connection I want to start using version control for this reports and that includes for example any metrics created at the dataset level but i'm not sure what are the best practices right now. In the future I want to have everything being automated via deployment pipelines as well So my questions is, has anyone tried the developer mode with live connection and if yes what best practices or setup do you recommend?
Direct Lake on OneLake + Deployment Pipelines + Git: parameter rules deploy but semantic model refre
Hi all, I’m trying to make a Fabric / Power BI semantic model deployment flow work for Dev -> Prod with Git and Deployment Pipelines, but I’m stuck on Direct Lake on OneLake source rebinding. Setup: I have two Fabric workspaces: DEV workspace: TPA-BI-Hub-Dev DEV lakehouse: lh_tpa_bi_hub PROD workspace: TPA-BI-Hub PROD lakehouse: lh_tpa_bi_hub The semantic model is a Direct Lake on OneLake model. In TMDL, the source expression uses: AzureStorage.DataLake( "https://onelake.dfs.fabric.microsoft.com/<workspace-id>/<lakehouse-id>", [HierarchicalNavigation=true] ) Tables have Direct Lake partitions, for example: partition dim_kontakt = entity mode: directLake source entityName: dim_kontakt schemaName: gold expressionSource: 'DirectLake - lh_tpa_bi_hub' Microsoft docs say Direct Lake on OneLake does not directly support deployment pipeline data source rebinding rules, but a parameter expression can be used in the connection string. Reference: https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview Attempt 1: split parameters We changed the expression to: AzureStorage.DataLake( "https://onelake.dfs.fabric.microsoft.com/" & WorkspaceId & "/" & LakehouseId, [HierarchicalNavigation=true] ) with parameter rules in the Production stage: WorkspaceId = <PROD workspace id> LakehouseId = <PROD lakehouse id> The model deployed and showed data, but refresh/reframe failed with: DirectQuery schema evaluation is not supported by the service-side ServiceLegacySchemaEvaluations. DirectQuery schema evaluation is a desktop-only path. Attempt 2: single full URL parameter Based on community examples, we changed to: expression 'DirectLake - lh_tpa_bi_hub' = let Source = AzureStorage.DataLake(#"OneLakeSource", [HierarchicalNavigation=true]) in Source expression OneLakeSource = "https://onelake.dfs.fabric.microsoft.com/<DEV workspace id>/<DEV lakehouse id>" meta [IsParameterQuery = true, Type = "Text", IsParameterQueryRequired = true] annotation PBI_ResultType = Text Then Production parameter rule: OneLakeSource = https://onelake.dfs.fabric.microsoft.com/<PROD workspace id>/<PROD lakehouse id> But Fabric validation failed with: ConceptualSchemaSettings should not be provided for non-Direct Lake queries That sounds like the service no longer classifies the parameterized expression as Direct Lake, even though the table partitions are still mode: directLake. Questions: 1. What is the recommended Git-compatible Dev -> Prod deployment pattern for Direct Lake on OneLake semantic models? Specifically: 2. Is parameterizing AzureStorage.DataLake(...) officially supported for semantic model refresh/reframe in the Power BI service, or only for deployment-time rule substitution? 3. Is the single URL parameter pattern expected to work with Git-integrated semantic models and Deployment Pipelines? 4. If parameter rules are unreliable here, is the recommended approach to maintain environment-specific branches, e.g.:develop has static DEV OneLake URL main / release-prod has static PROD OneLake URL 5. Or should we migrate to Direct Lake on SQL endpoint to use deployment pipeline data source rules properly? Related sources I found: Microsoft Direct Lake overview: https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview Microsoft Direct Lake development/TMDL source types: https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-develop Community example using OneLakeURI parameter: https://www.datazoe.blog/post/deployment-pipelines-and-power-bi-semantic-models-with-direct-lake-on-onelake-tables Direct Lake on OneLake vs SQL identification: https://data-mozart.com/direct-lake-models-are-they-onelake-or-sql-and-how-to-check/ Any confirmation of a working production-grade pattern would be very helpful.
