Information system migration projects (moving to a new ERP, CRM or business-critical application, or modernizing the data warehouse) are among the riskiest initiatives for a mature Power BI environment. A modified, renamed or deleted data source can silently break dozens of reports, some of them used by top management for weekly strategic decisions.
The classic problem: discovering the impact too late
In many migration projects, the BI team is only involved at the end of the project, once the new data source is ready and the legacy system is already being decommissioned. It then discovers, often in a rush and under heavy time pressure, the real extent of the reports to rebuild: work that could have been anticipated several months earlier if the dependency map had been available from the start of the migration project.
Why Power BI’s native lineage is not enough here
As detailed in our article on data lineage, Power BI’s native lineage remains centred on one workspace at a time: data sources are only visible at report and workspace level, with no global view of the tenant. Yet migrating an ERP, a CRM or a business-critical application generally affects data sources consumed by dozens of different workspaces, managed by separate business teams (finance, sales, supply chain, human resources) that often have no visibility on one another. Without a cross-tenant view, it is impossible to get a reliable answer to the central question: “Are we sure we have identified every report that uses this source?”
The complete method: map before you migrate
Step 1: Precisely identify the sources concerned
Exhaustively list the tables, databases, APIs or files exposed by the current system that will be modified, renamed or removed during the migration.
Step 2: Extract the list of connected semantic models
Using cross-workspace lineage, identify all Power BI semantic models, across all workspaces, that connect directly or indirectly to these sources, including through composite models or shared datasets.
Step 3: Trace through to the final reports and dashboards
For each semantic model identified, follow the chain through to the reports and dashboards that consume it, to obtain the complete, exhaustive list of affected end artifacts, along with their respective owners.
Step 4: Prioritize remediation
Rank the affected reports by business criticality (used by the executive committee, used by a single person, abandoned test report) and by number of active users, to focus rebuilding efforts on what really matters rather than treating all reports with the same priority.
| Priority level | Criterion | Recommended action |
|---|---|---|
| Critical | Used by the executive committee, large audience | Rebuild in advance, test in parallel before cutover |
| Important | Used regularly by a business team | Schedule within the migration project timeline |
| Secondary | Low usage but an active owner identified | Deferred rebuild, inform the owner |
| To archive | No recent usage, no active owner | Do not rebuild, archive |
A benefit that goes beyond the migration project
Once this map has been drawn up for a given migration project, it should not be treated as a throwaway deliverable. It forms the basis of a living lineage, reusable for any future change: later evolution of a data schema, decommissioning of another legacy application, merging of two teams or two systems after a reorganization.
Anticipate rather than repair
The difference between a well-controlled migration project and a chaotic one often comes down to a single decisive factor: the ability to anticipate the impact before the change is deployed to production, rather than discovering it afterwards through complaints from unhappy users and reports that suddenly display errors or inconsistent data.
Frequently asked questions
When should the BI team be involved in the migration project?
Ideally from the initial scoping of the project, even before the final choice of the new system, so that the impact map can influence the overall timeline and avoid costly late discoveries at the end of the project.
Should all affected reports be rebuilt before cutover?
Not necessarily all at once: prioritizing by business criticality often makes it possible to go live with the most important reports ready, and to handle secondary reports in the weeks following the go-live of the new system.
Does cross-workspace lineage also help anticipate changes smaller than a full migration?
Yes, the same method applies to any source change, even a limited one (adding or removing a column, changing a data type, renaming a table), which can have a disproportionate impact on downstream reports.
This article builds directly on the method described in “Power BI data lineage“. See also “Power BI inventory” for the data foundation needed for any impact mapping.
