Before and during a Microsoft Fabric migration, set up four things: an inventory of your reports, a list of what to retire, a named owner per report and one agreed definition per KPI. The migration is the cheapest moment to do it, because every report is being opened, rebuilt or dropped anyway. Purview and Fabric then handle security, labels and lineage. Leave this until after go live and you move the old confusion onto a new platform.
Why the migration is the moment to sort out governance
Most project plans put governance after go live, once the platform is stable. That sounds sensible. It's also the most expensive order to do it in.
During a migration, someone opens every report to decide whether it moves. That's the natural moment to ask three questions: does anyone still use this, who owns it, and what do its KPIs mean? After go live, nobody opens a working report to ask them. The questions only come back when two numbers disagree in a meeting.
For example: a team migrates a sales report that shows "revenue" one way and a finance report that shows it another. Both move to Fabric unchanged. Six months later, the CFO asks why the board pack doesn't match the sales dashboard, and the team has to untangle it on a live platform.
Microsoft's own Fabric adoption roadmap on Microsoft Learn treats content ownership and governance as areas to plan from the start, not to bolt on later.
The four-part checklist: Inventory, Retire, Own, Define
1. Inventory
List every Power BI report and semantic model in scope, with its workspace and how often it's used.
- This month: export the list of workspaces and items, and add usage from Power BI usage metrics or the Fabric admin monitoring workspace.
- Output: one sheet with every report, its workspace, its technical owner and its recent views.
2. Retire
Decide what doesn't move. Reports nobody opens, duplicates and one-off analyses are migration cost with no benefit.
- This month: mark each report as move, merge or retire. Agree a rule, for example "no views in the last quarter means retire unless someone objects".
- Output: a retire list signed off by the business, not just IT.
3. Own
Give every report that moves one named business owner. Not a team, and not the developer who built it.
- This month: for each report on the move list, ask the technical owner who decides what its numbers should be. Record that person.
- Output: a named owner per report, and per KPI where a KPI appears in several reports.
4. Define
Write one agreed definition for each KPI that reaches a management or board report.
- This month: start with the KPIs that appear in more than one report. Settle each one with its owner, in one plain sentence.
- Output: one definition per KPI, used by every report that shows it after migration.
What Purview and Fabric already give you
You don't have to build platform governance from scratch. Based on Microsoft's documentation, Fabric and Purview give you:
- Domains and workspaces to group content by business area.
- Workspace roles to control who can view, build and publish.
- Endorsement, so a report or semantic model can be marked Promoted or Certified.
- Sensitivity labels and data loss prevention from Microsoft Purview, applied to Fabric items.
- Lineage inside Fabric, and Purview Data Map scanning for metadata and lineage across the tenant.
- A business glossary and data quality checks in Purview's Unified Catalog, for data stewards.
Set these up during the migration too. But notice what's missing. None of them decides which reports to retire, who owns a KPI or what it means. Those are business decisions, and the migration is when you can make them.
What goes wrong when you skip it
Skipping governance doesn't slow the migration down. It speeds it up. The cost arrives later.
| Task | During the migration | After go live |
|---|---|---|
| Retire unused reports | Don't migrate them | Find them, check nobody uses them, then delete |
| Name an owner | Ask while the report is open anyway | Chase people who've moved on |
| Settle a KPI definition | Decide once, before reports are rebuilt | Rebuild reports that already went live |
| Explain numbers to users | Ship definitions with the new reports | Answer the same questions in tickets |
In practice, the result of skipping it is a copy of the old mess on a new platform. Users notice nothing has changed, and trust in the new platform starts low.
Where dScribe fits
Most of this checklist is decisions your team makes. dScribe takes some of the manual work out of them and keeps them visible after go live. It reads metadata only, so your data doesn't move.
- Inventory: dScribe crawls the metadata of your old systems and builds an inventory of them, so you start from a full list rather than a manual export.
- Retire: smart suggestions help detect duplicates. Flexible properties let you mark a report as retired, and give you an overview of retired reports to delete in the source.
- Own: you define the owner of each report and KPI in dScribe, so the name lives somewhere people can find it.
- Define: smart suggestions help define KPIs and link them to the reports and datasets they appear in. Defining a KPI is still partly manual, but the suggestions reduce the work. You can also see which reports use a given measure definition.
- Navigate: you define lineage in dScribe, with smart suggestions helping, so users can find their way from a report back to its sources.
After go live, the browser plugin shows the definition and the owner on the Power BI reports people open. That way the decisions you make during the migration stay visible, instead of ending up in a project spreadsheet.
In short
A Fabric migration is the one time your team opens every report on purpose. Use it. Decide what to drop, who owns what stays and what each KPI means, before the reports are rebuilt. Purview and Fabric will govern the platform. The meaning of the numbers is yours to settle, and it's never cheaper than now.
Frequently asked questions
What should we set up for data governance during a Microsoft Fabric migration?
An inventory of reports, a list of what to retire, a named owner per report and one definition per KPI. Alongside that, set up Fabric domains, workspace roles, endorsement and Purview sensitivity labels.
Should governance come before or after a Fabric migration?
During it. Every report gets opened in a migration, so decisions about ownership and definitions cost least then. After go live, nobody revisits a report that works.
Is Microsoft Purview enough for governance in a Fabric migration?
It covers platform governance: labels, data loss prevention, audit, lineage and a glossary for data teams. It doesn't decide which reports to retire, who owns a KPI or what it means.
Which Power BI reports should we not migrate to Fabric?
Reports nobody has opened recently, duplicates of other reports and one-off analyses. Use usage metrics to find them, and get the business to sign off the retire list.
Who should own a Power BI report after migration?
One named business person who decides what its numbers should be. Not a team, and not only the developer who built it.