A finance director called us last autumn. They had eight Power BI developers across two teams, a Premium capacity, and 247 published reports. Refresh failures were a weekly conversation. The company had officially deprecated two reports, but more than eighty users still opened them each month. The CFO had asked, reasonably, why the BI investment was producing more confusion than clarity. The answer was Power BI debt, and not the kind they assumed.
We started with the technical side. The semantic models were workmanlike. Properly modelled, sensible naming, reasonable size. Refreshes were failing not because of design issues but because nobody could agree which reports were still in use, so every developer was protecting every dataset.
That client had almost no model debt. They had a vast amount of adoption debt. They had also spent eighteen months hiring developers to fix it, which had not worked, which was why they had called us.
Most Power BI estates carry both kinds of debt. Almost none carry them in equal measure. Knowing which one you have more of is the difference between hiring a developer and hiring a programme manager, and the wrong choice will not work no matter how good the person is.
We have audited Power BI estates at more than 150 organisations over the last decade. This piece sets out what each kind of debt looks like, how to tell which one you have, and what we recommend doing about each.
Type 1: Power BI model debt
What model debt is
Debt in the technical foundations of your semantic models. Bidirectional relationships used as quick fixes. Calculated columns doing the work of measures. Auto date/time left on. Business logic that should live in the data layer, hardcoded in DAX instead. Manual data preparation steps that exist only in one developer’s head. Models that different people built grain by grain, without any shared design.
A semantic model carrying significant model debt. Eleven tables, six bidirectional relationships, no obvious fact-and-dimension split.
What it costs you
Refresh times grow. New measures break old ones in non-obvious ways. Every change becomes a careful threading exercise through assumptions nobody has written down. Developers spend more time on operations than on building. The cost shows up as a slow drain on the team’s velocity, and as the unease that settles over any model that has lasted longer than its design intended.
A worked example
One engagement last year shows the shape of it. A logistics business came to us with a single semantic model that had grown over four years to forty-one tables. Refresh ran for fifty-three minutes and failed roughly one morning in five. Nobody on the team could say what most of the model did, because the two developers who had built it had both since moved on.
When we opened it in DAX Studio, the picture was familiar. Nine bidirectional relationships. A central fact table carrying thirty-one calculated columns, several of them recomputing values that already existed as measures elsewhere in the same model. Auto date/time had quietly generated hidden hierarchies behind nineteen separate date columns. None of this was visible from the reports, which looked fine, which was exactly why it had survived four years.
The fix was not glamorous. We marked a single date dimension and switched auto date/time off, which on its own took the model from 2.3 GB to 900 MB. We converted twenty-six of the calculated columns to measures and removed seven of the nine bidirectional relationships, replacing two of them with bridge tables. Refresh dropped to fourteen minutes and stopped failing.
The work took six weeks. Most of that was not the refactor itself but reconstructing what the undocumented logic was supposed to do, because you cannot safely change code when nobody can tell you what it was for. That recovery, not the rebuild, is where model debt charges most of its interest.
Five questions for your lead developer
Put them to whoever owns your largest model:
- Could you onboard a new developer to that model in a week?
- If your most experienced developer left tomorrow, would the model still be maintainable?
- When someone adds a new measure, do you know with confidence which existing measures it touches?
- If a stakeholder asks for a new calculation, is the answer “two days” or “two weeks”?
- When you open the model in DAX Studio and look at VertiPaq Analyzer, is the top of the column-size list mostly tables you expected to see there?
If you hesitated on two or more, the model is carrying more debt than its surface suggests.
How you pay it down
Model debt is fixable with technical skill. You pay it down through audit, refactoring, and discipline going forward. Some of the work also sits upstream of the model itself, in where data preparation lives. We have written separately about whether you need a silver layer in Power BI, which is often the right starting point when the model is the wrong place to fix the problem. We will also publish a companion piece on the three issues that fail nearly every Power BI Health Check we run (link to be added once that post is live), covering the model patterns that account for most of the Power BI debt we see in practice.
Type 2: Power BI adoption debt
What adoption debt looks like
Debt in the people, processes, and governance around your Power BI estate. No clear ownership for each model or workspace. Reports that someone built once and then quietly abandoned. No retirement process. Training delivered as a one-off event and never refreshed. Workspaces with names nobody can explain and contents nobody has audited. Different departments answering the same question with different numbers, all defended.
Report usage from a recent client audit, anonymised. The top ten reports account for 71% of views. Of the remaining 240, more than half had not been opened in the last quarter.
Why it costs more than it looks
High tool spend with low business outcome. Time spent reconciling versions of the same number instead of acting on what the number says. Decisions that rested on whichever data was easiest to find, rather than whichever data was most accurate. Senior stakeholders who lose confidence in BI and revert to Excel. Most expensively, the slow erosion of the assumption that anyone can trust the BI estate at all.
How to tell
Three questions for whoever runs the Power BI tenant:
- Do you know which reports are actively used this quarter, and which are not?
- If a senior stakeholder asks “what is our [headline KPI]?”, does everyone come back with the same number?
- Is there a named owner for each production dataset?
A single uncomfortable answer here is enough. This is not a problem a better dashboard solves.
Why a developer can’t fix it
Adoption debt is harder than model debt because it is not technical. You pay it down through governance, ownership, and culture, none of which a developer can fix on their own. The fix requires sponsorship at a level above the BI team. Without it, the debt grows back faster than any individual can pay it down.
Why the two kinds of Power BI debt matter separately
Hiring a Power BI developer to fix adoption debt does not work. They will produce excellent dashboards that nobody owns, and the problem will simply move.
Hiring a programme manager to fix model debt does not work either. They will run useful governance forums about a model that fundamentally cannot bear the weight of the questions being asked of it.
The two kinds of Power BI debt also feed each other. Model debt produces adoption debt because users stop trusting numbers that arrive late or behave inconsistently. The reverse runs more quietly: where ownership is unclear, developers build defensively, and defensive modelling is how a clean model slowly takes on the complexity nobody chose.
The diagnostic question we put to clients on the first day of an audit is deliberately blunt: when you sit with your most expensive current Power BI problem, is the painful work mostly technical or mostly organisational? The honest answer tells you where to start.
What to do before you bring anyone in
Three checks you can run in an afternoon, one for each debt and one to compare them.
- Pull a report usage list for the last 90 days from the Power BI admin centre. Sort by views. If your top ten reports account for less than 30% of total views, you almost certainly have adoption debt. If they account for more than 80%, the long tail is probably already self-correcting and your problem sits elsewhere.
- Run VertiPaq Analyzer (in DAX Studio) on your largest model. Look at total model size, refresh time, and the number of calculated columns in the top ten by storage. If any of those raise a flag, you almost certainly have model debt.
- Ask your three most senior Power BI users which report they trust the most. If they give different answers, you have a clue about both debts, and a useful place to begin the conversation that follows.
If you run all three and your answers are healthy on every count, congratulations. You are an outlier.
One reflection on Power BI debt after 150 audits
Clients who arrive convinced they have a model problem almost always have an adoption problem sitting behind it, and the reverse holds just as often. The harder question is which one to fix first.
In the consulting engagements where we lead this work, we start with whichever debt is currently blocking value. Sometimes that means a structural intervention to the semantic model and a six-week refactor. In other engagements, it is a governance conversation the organisation has postponed for three years. Occasionally it is a frank discussion with the sponsor about whether the BI team has the mandate it needs to do either.
The mistake we see most often is the same one in either direction: an organisation pours money into the kind of debt they are comfortable thinking about, because the other kind is harder to face. Model debt has the comfort of being technical and therefore fixable. Adoption debt has the comfort of being someone else’s job. Neither comfort survives the audit.
