A report can look finished and still depend on a refresh nobody owns, a measure nobody understands, or a spreadsheet stored in someone's personal folder.
Taking over a Power BI report is not just a matter of opening the .pbix and changing a chart. Before you improve it, you need to learn where its data comes from, how its model filters that data, which numbers have been checked, and what could stop the report from updating tomorrow.
Use this handover checklist to establish a reliable baseline before making changes. The examples use fictional sales tables; adapt names, business rules and thresholds to the report you inherit.
1. Inventory every source and refresh path
In Power BI Desktop, open Transform data and record each query's source, authentication method, privacy level, parameters, and whether it loads to the model. Include files and SharePoint folders, databases, APIs, dataflows and other semantic models. A query that references a local path such as C:\Users\... is a dependency on one person's machine, not a stable production source.
Then inspect the published semantic model's refresh history and schedule. Record the gateway or cloud connection, credentials owner, expected frequency, last success, recent failures and incremental refresh policy. Confirm that the service can reach every source; a refresh that works only in the developer's Desktop session is not a handover.
For a quick Power Query inventory, add a temporary diagnostic step to a query while investigating, and remove it before delivery:
let
Source = Excel.Workbook(File.Contents(\"C:\\Data\\Orders.xlsx\"), null, true),
Sheet = Source{[Item=\"Orders\", Kind=\"Sheet\"]}[Data],
Headers = Table.PromoteHeaders(Sheet, [PromoteAllScalars=true]),
Profile = Table.Profile(Headers)
in
Profile
Table.Profile helps reveal nulls, distinct counts and value ranges. It does not replace checking the connector, credentials, gateway and service refresh history.
2. Map the model before editing it
In Model view, document the fact tables, dimensions, grain of each fact, key columns, active and inactive relationships, cardinality, and filter direction. Find the date table and identify which business date each relationship represents. Mark any measures or columns that are hidden, and note calculation groups, row-level security, parameters and composite-model boundaries.
The grain matters. If one sales order has several lines, counting rows is not the same as counting orders. If a customer dimension has duplicate keys, a relationship or merge can inflate totals. Ask the report owner what a KPI means in business terms before treating its current formula as the definition.
Create a measure register with the measure name, definition, format, owner, dependent measures, validation status and last checked date. In Power BI Desktop, use Model view or the Properties pane to inspect measures; where available, use a model metadata tool such as DAX Studio or Tabular Editor to export the definitions. Save the register next to the report so the next maintainer can find it.
3. Trace measures and find broken or orphaned logic
Start with the measures used by visible report pages, then follow their dependencies down to base measures and source columns. Search the model for references to renamed or removed fields, and inspect refresh errors, visual errors and warnings. A measure that is not used on a visible page may still be referenced by another measure, a tooltip, a hidden page or a calculation group; verify dependencies before deleting anything.
Keep reusable base measures small and explicit:
Net Sales =
SUM ( Sales[NetAmount] )
Order Count =
DISTINCTCOUNT ( Sales[OrderID] )
Average Order Value =
DIVIDE ( [Net Sales], [Order Count] )
Avoid rebuilding the same business rule in several visuals. If an existing measure depends on an inactive date relationship, make that intent visible and verify it against the intended date:
Sales by Ship Date =
CALCULATE (
[Net Sales],
USERELATIONSHIP ( Sales[ShipDate], 'Date'[Date] )
)
For an orphan-key check, compare fact keys with the dimension keys in the same model. This simple measure is useful when the dimension key is unique and the relationship is understood:
Unmatched Customer Keys =
COUNTROWS (
EXCEPT (
VALUES ( Sales[CustomerKey] ),
VALUES ( Customer[CustomerKey] )
)
)
Also look for unused measures, duplicate definitions, stale comments, hard-coded dates, unsafe division, and measures whose result changes unexpectedly when sliced by a dimension. Treat “unused” as a review flag, not automatic permission to delete.
4. Reconcile important numbers with the source
Choose representative measures: a total, a distinct count and a ratio. Pick a closed period and a small set of filters, then calculate the same figures directly from the source system. For example:
SELECT
SUM(NetAmount) AS NetSales,
COUNT(DISTINCT OrderID) AS OrderCount
FROM dbo.Sales
WHERE OrderDate >= '2026-09-01'
AND OrderDate < '2026-10-01'
AND Status <> 'Cancelled';
Use the same date field, exclusions, currency, time zone and rounding in both places. Compare the source result with Power BI at the grand total and at a useful slice, such as region or product. A matching grand total can hide duplicated rows or a relationship that fails only for certain categories.
Record the test query, filter conditions, expected result, actual result, tolerance and reviewer. If the figures differ, trace the difference through source filtering, Power Query steps, relationships, DAX context and visual filters. Do not hide an unexplained variance by rounding it away.
5. Document how to operate the report
Write down the business definition for each important KPI, the source and grain behind it, refresh frequency, credential and gateway owner, expected completion time, known limitations, and escalation contact. Include where the .pbix and source files are stored, how changes are versioned, how the report is deployed, and how to roll back.
Keep credentials out of the document. Record the approved owner or vault location instead. Add a short change log with the date, change, reason and validation performed. A new maintainer should be able to answer “what changed?” and “how do I know it is right?” without relying on a former colleague's memory.
6. Use the first 30 days to reduce risk
Days 1–5: Observe. Make a copy of the report, capture the current pages and filters, inventory sources and refresh, map the model, and meet the report owner. Avoid cosmetic or structural changes while you establish a baseline.
Days 6–10: Validate. Reconcile the highest-impact KPIs to source queries. Review recent refresh failures, credentials, gateways, data types, relationships and the most-used measures. Log discrepancies with an owner and business impact.
Days 11–20: Stabilize. Fix confirmed defects in a controlled copy. Add missing checks, clarify measure names and descriptions, remove obsolete dependencies only after checking references, and test key slices and security roles. Keep a rollback copy and record each change.
Days 21–30: Set the operating rhythm. Agree on ownership, refresh alerts, a monthly reconciliation, change review and a maintenance backlog. Share the measure register and runbook with the people who will support the report. Prioritize work by risk and user impact, not by how easy a visual is to restyle.
Handover checklist
- [ ] Every source, query, credential owner, gateway and refresh schedule is recorded.
- [ ] The service refresh history is checked, and the last successful refresh is recent enough for the business.
- [ ] Fact-table grain, keys, relationships, date paths, RLS and model boundaries are mapped.
- [ ] Important measures have definitions, owners, formats and dependency notes.
- [ ] Broken references, refresh errors and suspicious orphan keys have been investigated.
- [ ] A total, a distinct count and a ratio reconcile to the source for documented filters.
- [ ] Reconciliation results and acceptable tolerances are recorded with a reviewer.
- [ ] The report location, deployment path, rollback method and change log are documented.
- [ ] A 30-day stabilization plan has owners and a follow-up review date.
A good handover leaves the report understandable and supportable, even when the original author is unavailable. Once the sources, model, measures and checks are visible, improvements become safer—and the next maintainer inherits a process instead of a mystery.
Need help taking over a report or building a maintenance plan? Learn about our Power BI consulting services.