Someone left, or changed roles, and you now own a Power BI estate you did not build. There is no documentation. Nobody can tell you which reports matter. And you will be asked to change something in it within a fortnight.
This is a structured first week that gets you from unknown to governable. It assumes nothing and it produces something you can show a manager.
Start With the Right Question
The instinct is to open the biggest model and start reading DAX. Resist it. The first question is not how anything works, it is what exists and who depends on it — because that determines what you can safely change and what would cause an incident.
Day 1: Inventory
List every workspace, every dataset, every report, and every dataflow. The admin portal or the Power BI REST API will give you this; the API is worth the setup time if the estate is large.
For each item record: owner, workspace, last refresh, last modified, and whether refresh is currently succeeding. That last column alone usually produces a surprise, because an estate nobody owns always contains datasets that have been failing quietly for months.
Day 2: Dependencies
Map which reports use which datasets, and which datasets read which sources. The lineage view in the service gives you most of this.
What you are looking for is concentration: the one dataset twelve reports depend on is the thing you must not break, and it is usually not the one anybody warned you about. You are also looking for personal accounts in the connection credentials — every one of those is a future outage the day that person's password rotates.
Day 3: The Models
Now open the models, largest first, and spend an hour each rather than a day. You are surveying, not fixing.
- Run VertiPaq Analyzer. Note model size, the five largest columns, and whether any are calculated columns.
- Look at the relationship diagram. Count bidirectional relationships. Note whether it is a star or a flat table.
- Check for a date table, and whether it is marked as one.
- Skim the measure list. Count how many have descriptions. Usually the answer is none.
- Note any measure that appears to duplicate another under a different name — these are where disagreeing numbers come from.
Day 4: Security and Refresh
For each production dataset: what account does it connect with, is row-level security configured, and where do failure notifications go?
The three findings that matter most here are a dataset connecting under a departed employee's account, RLS that has never been tested with a real user, and failure alerts routed to an individual inbox rather than a shared channel. Each is a single point of failure you have just inherited.
Day 5: Usage
Pull usage metrics for every report. Distinct users in the last thirty days, not total views.
This is the most useful day of the week, because it tells you what you can stop caring about. In most inherited estates a minority of reports carry nearly all the usage, and a substantial number have not been opened in ninety days. You do not need to understand, document or maintain those — you need a decision about retiring them.
Making Your First Change Safely
At some point in week two you will have to change something. Three habits make that survivable in an environment you do not yet understand.
Take a copy before you touch anything. Download the .pbix, save it with the date, and keep it. Version history in the service is not a substitute, and you will want the ability to compare rather than just revert.
Change the measure, not the model. A measure change is contained and reversible. A relationship or storage mode change ripples through everything and is far harder to unwind if it turns out the previous author had a reason you have not discovered yet.
Validate against the current output before you publish. Screenshot the numbers as they are now, make the change, compare. In an undocumented environment this is the only way to know you have not quietly altered a figure somebody reports upward.
What to Write Down as You Go
You will not remember any of this in three weeks, and the person asking you to change something will not wait. Keep one document, updated as you go, with five sections.
The inventory, with the failing-refresh column. The dependency map, even as a rough sketch — which reports die if a given dataset breaks. The continuity risks: personal accounts, missing alerts, untested security. Open questions, because there will be measures nobody can explain and those need an owner rather than a guess. And the retirement candidates, with their usage figures attached.
That document is also the thing that protects you. When something breaks in month three, the difference between it being your fault and it being an inherited risk you flagged in week one is whether you wrote it down.
Keep it somewhere the rest of the business can see, not in your own notes. An inherited estate usually has no shared understanding of what exists, and being the person who produced the first one is worth more politically than any individual fix you make in the first month.
Triaging What You Found
| Finding | Urgency | Why |
|---|---|---|
| Dataset on a departed account | Immediate | Breaks the moment credentials are revoked |
| Refresh failing, report in use | Immediate | Someone is acting on stale data now |
| No failure alerting | This week | Determines whether you find out before users do |
| Untested RLS | This week | Over-permissioning generates no support ticket |
| Model over 1GB, flat | This month | Costly but not urgent unless users are complaining |
| No measure descriptions | This quarter | Slows every future change; not an outage risk |
| Reports unused for 90 days | This quarter | A retirement decision, not a technical fix |
The pattern: continuity risks first, correctness second, performance third, documentation last. That is the opposite of the order most people work in, because performance is the visible complaint and continuity is the invisible one.
The Part That Is Not Technical
Two things will happen in your first month that are not engineering problems, and being ready for them is worth more than any of the technical findings.
Somebody will ask you to change a report you do not understand yet. The right answer is not to refuse and not to guess. It is to say what you can verify, what you cannot, and what you would need to check first — and to put a rough timeframe on the checking. People accept that readily when it is stated plainly; they lose confidence when a change is made confidently and turns out wrong.
Somebody will tell you a report is critical when the usage data says nobody opens it. Both can be true: it may be critical monthly rather than daily, or critical to one person who matters. Ask when they last used it and what decision it informed. That question resolves the disagreement without anyone having to defend a position.
Neither of these is in a handover document, because there was no handover document. That is rather the point.
What We Would Do
This is essentially our audit engagement, done in a week and written up. The deliverable is the inventory, the dependency map, the ranked findings and a documented model — so the next person to inherit it does not start from zero.
Run the free 32-point checklist first — it covers the same ground and takes eight minutes. If the score comes back low, the audit engagement is the structured version.