When a Power BI project ends, you should receive the source files, documentation of the data model and every measure in it, an inventory of the data sources and how they connect, admin access to the workspace, the refresh schedule with its credentials mapped to accounts you control, evidence that the numbers reconcile to source, and a written runbook that lets somebody else pick the work up.
If you received a link to a published report and a goodbye email, you did not get a handover. You got a dependency.
This post is the checklist: what each artefact is, why you need it, and what it costs to be missing when you find out six months later.
What should a Power BI handover include?
Here is the full list. None of these items is exotic, and a consultant who builds properly produces most of them as a by-product of doing the job well. The cost column is the practical consequence, not a scare figure: it is what the gap turns into when the person who built the thing is no longer answering.
| Artefact | Why you need it | What missing it costs later |
|---|---|---|
| Source files (.pbix or the PBIP project) | Without them, nobody can change anything | A rebuild of work you already paid for |
| Semantic model documentation | The definitions behind every number | Arguments about what "revenue" means, again |
| Measure list with logic explained | DAX nobody understands is DAX nobody dares touch | Every change becomes an archaeology job |
| Data source inventory | Which systems feed which reports, and how | Hours of detective work before any fix |
| Gateway and credential map | Refreshes run on somebody's login | Refreshes die the day that person leaves |
| Workspace admin access | You control publishing, sharing and deletion | Locked out of your own reporting |
| Row-level security matrix | Who sees what, written down and testable | Nobody can safely change who sees what |
| Reconciliation evidence | Proof the report matches the source system | Trust collapses the first time a number is challenged |
| Written runbook | How to refresh, republish and recover | Every incident needs external help |
| A change log | What was altered, when and why | The estate becomes a mystery |
The list comes from what I hand over myself, and from what I find missing when I'm asked to take over estates other people built.
Why do the source files matter more than the reports?
The published report is the output. The source file is the asset.
A Power BI report you can view but cannot edit is like being handed a printed spreadsheet: real information, no way to change it. If the consultant keeps the .pbix or the PBIP project, every future change, however small, routes through them at whatever their rate is by then. That is not always malice. Sometimes it is habit, sometimes it is a muddled belief about intellectual property. Either way, the fix is the same: the contract should say the files are yours, and the handover should end with those files in a repository or folder you control.
Ask for the project format (PBIP) if your consultant works that way, because it stores the model and report as readable text files that work with version control. A .pbix is fine too. What is not fine is nothing.
What does good model documentation look like?
Not a hundred-page document nobody reads. The useful version is short and specific:
- Every measure, named, with a one-line plain-English definition. "Gross Margin % = gross profit over invoiced revenue, excluding carriage" is enough. The point is that a finance person can read the list and object to a definition before it causes a board-level argument.
- A diagram or list of the tables and how they relate. Which table is the calendar, which are facts, which are lookups.
- The awkward decisions, written down. Every model contains judgement calls: how returns are treated, which date a sale is counted on, what happens to unallocated costs. These are exactly the things that cause the "why doesn't this match the ERP?" conversation, and I've written before about what happens when reports disagree because those calls were never recorded.
If your consultant says the model is "self-documenting", it means they haven't documented it.
Who should the refresh run as?
This is the item that fails most often, and it fails silently.
Scheduled refresh in the Power BI Service runs on stored credentials, and a gateway connection to on-premises data runs under an account too. If those credentials belong to the consultant, or to an employee who later leaves, the refreshes stop working when that account is disabled. Nobody gets an alert they recognise. The numbers just quietly stop moving, and the first person to notice is usually whoever presents them.
The handover should name every credential the estate depends on, and each one should be moved to a service account or an account your organisation owns before the project closes. Ten minutes of admin now, or a stale board pack later. If nobody in your business is watching for refresh failures at all, that is a monitoring problem rather than a handover problem, and it is the exact gap the Watch tier of my care plan exists to cover.
What does a missing handover actually cost?
Real money, at market rates. ITJobsWatch puts the median UK Power BI contractor day rate at £490, from 1,237 quoted rates in the six months to 26 August 2026. Reverse-engineering an undocumented model, rebuilding a lost source file, or untangling a credential mess is exactly the kind of work that gets billed at that rate, and it is work that produces nothing new. You are paying full price to get back to where you already were.
There's a wider cost breakdown in the cost guide, but the short version is that the cheapest handover is the one specified before the project starts. Put the artefact list in the statement of work. A good consultant will not blink, because they were going to produce it anyway.
How do I hand projects over?
Since I'm asking you to demand this from other people, here is what my own version looks like. The fixed-price Reporting Sprint ends with a reconciliation pack proving the numbers match source, a documented semantic layer, row-level security configured and tested against real roles, a written runbook, and two handover sessions with your team. The rule I build to is that if it doesn't reconcile back to source, it doesn't ship, and the handover exists so that rule stays true after I've gone.
The point of a handover is that you should be able to fire your consultant. Not that you'd want to, but that you could, and nothing would break. That freedom is the difference between hiring an expert and acquiring a landlord.
Common questions
What should a Power BI project handover include?
The source files (.pbix or PBIP), documentation of the data model and measures, an inventory of data sources and gateways, the refresh schedule with credentials moved to accounts you control, workspace admin access, a row-level security matrix if RLS is used, evidence the numbers reconcile to source, a written runbook, and a log of changes made. A walkthrough session with your team should cover how it all fits together.
Who owns the Power BI files a consultant builds?
Whatever the contract says, which is why the contract should say you do. In the UK, without an explicit assignment, the default position on work created by an independent contractor can favour the contractor, so put file ownership and delivery in the statement of work before the project starts. A reputable consultant will agree without argument.
Do I need the .pbix file or is the published report enough?
You need the source file. The published report in the Power BI Service is the output; the .pbix or PBIP project is the editable asset, and without it every future change has to go back through whoever holds it. Treat a project as unfinished until the source files are in storage you control.
What happens if the consultant's account owned the refresh?
The scheduled refresh keeps working until that account is disabled or its password changes, then it fails. Reports keep displaying the last successful refresh, so the numbers look alive while quietly going stale. Move every stored credential and gateway connection to a service account your organisation owns before the project closes, and put monitoring on refresh failures so a silent one gets caught.
How much documentation is reasonable to expect?
Enough that a competent Power BI person who has never seen the estate could take over: a measure list with plain-English definitions, a description of the tables and relationships, the data source inventory, and a runbook covering refresh and republishing. A short accurate document beats a long stale one. What you should not accept is nothing, or "it's all in the DAX".
What does it cost to recover from a bad handover?
It is billed like any other specialist work: the UK median Power BI contractor rate was £490 a day on ITJobsWatch as of 26 August 2026. Reverse-engineering an undocumented model can take days before any improvement starts, so the recovery often costs a meaningful fraction of the original build. Specifying the handover up front costs nothing.
Can I ask for a handover checklist before the project starts?
Yes, and you should. Put the artefact list in the statement of work so the handover is a deliverable rather than a favour. It also works as a filter: a consultant who resists writing documentation and delivering source files is telling you how the engagement ends before it has begun.