You should own all of it. The Microsoft tenant, the licences, the workspaces, the gateway, the source files and the documentation should all sit in your business's name from day one, with the consultant working as a guest in your environment rather than you renting space in theirs. When the engagement ends, ending it should be an access change, not a negotiation. That's the whole answer, and any arrangement that falls short of it deserves a hard question before you sign.
The reason this post exists is that plenty of arrangements do fall short, and rarely because anyone set out to take hostages. Convenience decisions made in week one ("I'll just set it up in my tenant to get us moving") harden into dependency by month twelve. So here's every asset that should change hands, the patterns that quietly stop it, and what to check while checking is still cheap.
What should you actually own?
Every asset in the estate, listed. There's no published statistic for how often each pattern occurs, so this is a structured checklist drawn from what the assets are and how each one goes wrong, not a survey. For each row: who should hold it, and the dependency pattern to look for.
| Asset | Who should own it | The pattern to watch for |
|---|---|---|
| Microsoft 365 tenant | You, always | Reports live in the consultant's tenant and your team views them as guests |
| Power BI licences | Bought on your billing | Licences bought and resold through the consultant, so leaving means relicensing everyone |
| Workspaces | Created in your tenant, you hold admin | Consultant is the only workspace admin; you can view but not administer |
| Published reports and semantic models | Deployed in your workspaces | The live versions exist only where the consultant published them |
| Source files (.pbix or .pbip projects) | Handed over at every release | "The report is published, you don't need the files." You do. |
| Data gateway | Installed on your infrastructure, you hold admin | Gateway runs on the consultant's machine or account; refreshes die when they go |
| Source credentials and connections | Service accounts your business controls | Refreshes run under the consultant's personal login |
| Documentation and change notes | Delivered continuously, not promised at the end | "Documentation" is a line in the final invoice, permanently pending |
Two rows do most of the damage: the tenant and the source files. Get those two right and the rest tends to follow, because a consultant working in your tenant with your files handed over at each release has nothing structural to hold.
Why do the source files matter so much?
Because in Power BI, the published report is not the asset. The .pbix or .pbip file is where the model, the queries, the measures and the report design actually live. The published version is what those files produce.
If the engagement ends and you hold the published reports but not the files, you own the output and not the machine that makes it. The reports keep working, for a while. Then a source system changes, or a measure needs updating, and the person you bring in next has to reverse-engineer or rebuild what you already paid to have built. You've paid for the work twice, with a gap in the middle where nothing could be changed.
The fix costs nothing: source files handed over at every release, not at the end of the project. An end-of-project handover is a single point of failure; a relationship that sours in month five takes the files with it. Continuous handover means the worst case is losing a fortnight of work, not a year of it. The full list of what a proper handover contains, files included, is its own post: what you should receive when a Power BI project ends.
Where do the quiet hostage patterns hide?
The obvious pattern, "we keep your files unless you renew", is rare, because it looks as bad as it is. The patterns that actually catch businesses look like helpfulness.
The convenience tenant. The consultant gets you moving fast by building in their own tenant, with a promise to migrate later. Later never has a date. A year on, your entire reporting estate lives in an environment you have no rights over, and migrating out is a project you'd have to pay for. The moment to refuse this is week one, when refusing costs nothing.
The personal-credential refresh. Data connections authenticated with the consultant's own account. Everything works until they roll off and their access is cleaned up, at which point every scheduled refresh fails at once. You discover the dependency at the worst possible moment: after they've gone. This one is worth a specific check today, not just at contract end.
The undocumented estate. Nothing is withheld, and everything is opaque. The model works, the measures are unnamed and unexplained, and nothing is written down. The consultant hasn't taken a hostage; they've become one, permanently, because only they can safely change anything. Whether this was strategy or just untidiness, the dependency is identical. It's why every change on my own care plan comes with a short written note of what changed and why: an estate should never become a mystery only one person understands.
The licence middleman. Licences and capacity bought through the consultant's agreement and recharged. Sometimes there's a genuine discount; there's also a switching cost that didn't need to exist, because leaving now includes a relicensing exercise.
None of these require bad faith. All of them produce the same result: the cost of leaving grows quietly, and the relationship continues because ending it is painful rather than because it's earning its keep.
What should you check before signing with a consultant?
Five questions, all answerable in writing before any work starts, and none of them awkward to ask a good supplier.
"Whose tenant does the work happen in?" The only good answer is yours. If you don't have one yet, setting yours up is the first task, not a task for later.
"When do we receive source files?" At every release. Listen for hedging.
"What accounts do refreshes and gateways run under?" Service accounts your business controls, on your infrastructure.
"What does documentation consist of, and when does it arrive?" A concrete artefact list with dates through the project, not a promise attached to the final invoice.
"What exactly happens if we stop working together?" The answer you want is short: you remove my access, and everything keeps working. On my own engagements the support arrangement is rolling monthly, and cancelling is an email: you keep the reports, the documentation and the change notes, because they were always yours. Any answer involving transition fees, licence surrender or "we'd need to discuss that" is telling you where the hooks are.
A supplier who answers all five crisply has designed for your independence. A supplier who bristles at the questions has answered them anyway. And the same logic applies further down the stack: your historical data shouldn't be held hostage by an old system's licence fees either, which is the argument in switching off a legacy ERP without losing the history.
What if you're already locked in?
Untangle in order of blast radius, and do it while the relationship is healthy rather than during a dispute.
First, credentials: move refreshes and gateway connections onto service accounts you control, because this one can take your reporting down by accident, no malice required. Second, files: request the current source files now and make per-release handover the standing arrangement from today. Third, admin rights: get someone from your business made admin on every workspace, and licences moved onto your own billing at the next renewal. Fourth, the tenant, if the estate lives in theirs: agree a migration with a date on it. It's real work, but it's the difference between owning your reporting and renting it.
A consultant who cooperates readily with this list was never holding you hostage, and the exercise costs you a few conversations. One who resists has told you what the arrangement really was, and better to learn that on your schedule than on theirs. If you'd rather have an independent pair of eyes establish what state the estate is actually in first, ownership, access and documentation included, that's ground a £950 Health Check covers as part of scoring the whole estate.
Common questions
Who owns the Power BI reports a consultant builds for us?
Contractually, that's set by your agreement, and it should say the work product is yours on payment. Practically, ownership means possession: the reports deployed in your tenant, the source files in your hands, and the documentation delivered. A contract saying you own reports that live in someone else's tenant, with files you've never received, is ownership in theory only.
Should Power BI development happen in our tenant or the consultant's?
Yours, from day one, with the consultant added as a guest. If your business doesn't have a Microsoft tenant yet, creating one is the first job of the engagement. A consultant's tenant is sometimes offered as a fast start, but it means your entire estate lives somewhere you have no rights over, and migrating out later is a paid project.
What files should we receive from a Power BI consultant?
The source files, .pbix or .pbip, for every report and semantic model, handed over at each release rather than at project end. These files are where the model, queries, measures and design actually live; the published report is just their output. Alongside them: documentation of the model, credentials arrangements, and a note of every change made.
Can a consultant hold our Power BI reports hostage?
Deliberate hostage-taking is rare. Accidental dependency is common: estates built in the consultant's tenant, refreshes on their personal credentials, source files never transferred, or an undocumented model only they can change. Each pattern makes leaving expensive without anyone ever refusing you anything, which is why the checks belong at the start of the engagement, not the end.
What happens to our reports if we cancel a support contract?
With a well-structured arrangement, nothing: the reports, files and documentation were in your possession all along, and cancelling removes the support, not the estate. Mine are rolling monthly, cancelled with an email, and you keep everything including the change notes. If cancelling a contract would leave you without files, admin rights or documentation, you've found the dependency while there's still time to fix it.
Do we need our own Power BI licences or can the consultant provide them?
Buy them on your own Microsoft billing. Licences purchased through a consultant and recharged create a switching cost: leaving them means relicensing your users. The occasional discount on offer is rarely worth the dependency, and licences in your own name mean the question never arises.
How do we take back ownership of an estate a consultant controls?
In blast-radius order: move refreshes and gateways onto service accounts you control, get the current source files and make per-release handover standard, take workspace admin rights and move licences to your billing, then migrate the estate into your tenant if it lives in theirs. Do it while relations are good. A cooperative consultant makes this a few conversations; a resistant one has told you something important.
Support terms referenced are from my published care plan page, September 2026. All figures exclude VAT where applicable.