Deploying Power BI - The Boring Part That Decides If It Sticks

The most expensive Power BI failures I've seen weren't technical. The reports worked. The data refreshed. The semantic models were tidy. The project just never got used because nobody told anyone it existed, nobody trained them on it, and nobody was watching to see what was actually happening after go-live.

This is the stage of a Power BI migration that gets the least attention and causes the most regret. Microsoft's official guidance covers it under the heading of deploy, support, and monitor. I think of it as the part where you find out whether anything you did earlier was worth it.

I'm writing this because the planning posts get all the love but the post-deployment work is where the value actually lands. Over the last few years working with Australian organisations across finance, healthcare, government, and mining, the pattern has been consistent: teams that take this stage seriously get adoption, and teams that treat it as an afterthought get a graveyard of beautifully built reports that nobody opens.

Cutover - it almost never happens cleanly

Most Power BI migrations involve moving off something else. SSRS, Cognos, MicroStrategy, Excel-on-a-shared-drive, Tableau in a few cases. The cutover plan needs to acknowledge that the old system can't just disappear on Monday morning.

What I usually recommend is a parallel run for at least two reporting cycles. If you're cutting over a monthly board pack, run both systems in parallel for two months. If it's a weekly ops report, four weeks. People need to see the numbers match before they'll trust the new system. This isn't paranoia, it's reasonable scepticism, and trying to skip it is how you get a CFO ringing the project sponsor at 11pm asking why the revenue number changed.

Use the parallel period to find the discrepancies. There will be discrepancies. Sometimes the old system was wrong and nobody noticed. Sometimes the new model uses a slightly different business rule. Sometimes there's a rounding difference that doesn't matter but looks alarming. Find these, explain them, document them. Don't paper over them.

Once you've cut over, archive the old system but don't delete it for at least six months. Someone will need to pull a number for an audit, a board paper, or a comparison and you'll be glad it's still there. We've inherited environments where the old reporting system was decommissioned the day after cutover and three months later nobody could explain why a metric had moved. That's a bad day.

Communicating the change - more than an email

This is where IT projects often die. The reports go live, an email goes out, and the team moves on to the next thing. Three weeks later, usage is at 12% and nobody knows why.

Real change communication for a Power BI rollout looks like this:

A pre-launch announcement two weeks out. What's changing, why, when, and what people need to do. From a business leader, not the project team. People listen to their boss, not the BI team.

A launch day announcement with very clear access instructions. Don't assume people know how to find a Power BI app. Half of them don't. Include screenshots, a direct link, and a one-page quick reference.

A follow-up at two weeks asking for feedback. Not a survey nobody fills out, an actual conversation with the people who said they'd use the reports. Find out who's stuck, who hasn't tried, and who's using it for things you didn't expect.

A formal review at three months looking at adoption metrics, support tickets, and user feedback. This is when you find out whether the migration actually worked.

We help organisations think through this kind of structured rollout as part of our Power BI consulting work. The reports are the easy part. The change management is what determines if anyone uses them.

Training - tier it, don't blanket it

The mistake here is treating all users the same. The receptionist who needs to pull a weekly customer count doesn't need the same training as the analyst building self-service reports. If you put them in the same session, both of them will be miserable.

Tier the training like this:

Consumers who only need to view reports. A 30 minute walkthrough on logging in, finding the app, using filters, and exporting data. Anything longer is wasted on this group.

Power users who will build their own reports against shared semantic models. Half a day on the report canvas, basic visual selection, simple measures, and the guardrails for self-service. Make sure they understand the difference between the semantic model and the report so they don't try to "fix" data in a visual.

Developers who own the models. Multi-day deep training on DAX, performance tuning, model design, and the deployment pipeline. This is the group where the real engineering happens and skimping on their training shows up as bad models that everyone else has to use.

The biggest mistake I see is doing one generic training session for everyone. The consumers are bored, the developers are frustrated, and nobody comes away knowing what they actually need. Spend the extra effort to split the groups.

Also, record the consumer training. People will join the organisation later and they need to be able to get up to speed without scheduling another session. The video doesn't need to be polished. A 30 minute Loom recording is fine.

Support - know who answers what

A Power BI rollout creates support questions that don't fit neatly into existing IT categories. Is "I can't see the report" an access question, a Power BI question, or a network question? Is "this number looks wrong" a data quality question, a model question, or a business definition question? Most service desks don't know.

Set up a clear escalation path before go-live:

Tier 1 is the helpdesk for access, login, and basic navigation issues. They need a runbook with screenshots. Most of the tickets they'll get are "I can't find the report" and "I'm not in the right group".

Tier 2 is the Power BI team for performance issues, refresh failures, and report bugs. They need monitoring access and the ability to look at the workspace from an admin perspective.

Tier 3 is the data team for upstream issues - source system problems, semantic model questions, data definition disputes. These take the longest to resolve so triage them quickly so they don't sit in a queue with Tier 1 stuff.

A shared inbox or Teams channel for "Power BI questions" works for a while but doesn't scale. Get a proper ticket system involved by month two, even if it feels heavy. The tickets become your evidence base for what's working and what's not.

Monitoring - watch what actually happens

This is the part that gets skipped the most. The reports are live, people are using them, presumably it's fine. Six months later you discover that the executive dashboard hasn't been opened since week three because the executive prefers a screenshot in an email and nobody told you.

What to monitor:

Usage by report and by user. Power BI's usage metrics give you this out of the box. Look at it weekly for the first three months, monthly after that. Sudden drops mean something is wrong. Reports with zero usage need a conversation about whether to retire them or fix them.

Performance. Track refresh durations and report load times. Refresh durations creeping up usually means the source data is growing or the model is being asked to do too much. Report load times getting worse means visuals are accumulating in ways that hurt performance. Both are fixable but you need to know they're happening.

Capacity. If you're on Premium or Fabric capacity, monitor utilisation. Hitting 100% means throttling, throttling means slow reports, slow reports mean angry users. Set alerts at 80%.

Errors. Refresh failures, gateway failures, expired credentials. These should generate alerts to whoever owns the workspace, not just sit in a log. We've seen environments where the daily refresh had been failing for three weeks and the team only found out because a business user noticed the data was stale.

Microsoft's monitoring story has improved a lot over the last two years. The admin monitoring workspaces and the new Fabric capacity metrics app give you visibility that used to require building yourself. Use them. They're free and they're better than what you'd build.

The retrospective nobody wants to do

Three months after go-live, do an honest retrospective. Not a "lessons learned" slide deck for the steering committee. An actual conversation about what worked, what didn't, and what would you do differently next time.

The questions worth asking:

Did the workspace structure hold up? Are we creating workspaces we didn't plan for? Why?

Are the right people building content? Or has it all defaulted back to the central team because the business users gave up?

Did training stick? Do people still know how to use the features we trained them on?

Is the data being used to make decisions? Or is it being looked at and then ignored?

These questions are uncomfortable because the honest answers are often "kind of" and "not really" and "we don't know". That's fine. The point isn't to grade the project, it's to figure out what to invest in for the next quarter.

We do a lot of this kind of post-deployment review as part of our broader AI and data strategy work. Power BI rollouts often surface bigger questions about data ownership, governance, and how the organisation actually uses information. Worth treating those questions seriously while you have the momentum.

A note on Fabric

If your deployment is recent, you're probably on Fabric capacity, which changes some of the monitoring and licensing story. The principles in this post still apply but the specific tools are different. The Fabric capacity metrics app is the one to know. We've written about Fabric specifically if you want more on the broader platform.

Final thoughts

Deployment isn't a one-day event. It's a phase that runs for at least three months after go-live and the organisations that treat it that way get adoption. The ones that treat it as a launch event get a half-used environment that someone has to clean up two years later.

Spend more on this stage than you think you need to. The reports are cheap to build. The behaviour change is expensive. If you want the investment to pay off, the deployment phase is where it actually happens.

Microsoft's full guidance is at their deploy, support, and monitor docs. It's solid reference material. This post is what I'd add to it after running these conversations with Australian clients across a lot of different industries.