Planning a Power BI Migration - The Decisions That Actually Matter

Most Power BI migrations I've worked on go wrong for the same reason. The team treats it as a technology project when it's really a structural design exercise. By the time you're actually deploying content, the important decisions have already been made (or skipped). If they were skipped, you'll find out in production.

This post is about the planning stage. Specifically, the decisions you need to make for a single solution after you've already done the broader organisation-level planning. Microsoft calls this Stage 2 of their migration framework. I just call it "the part where you decide how the thing is actually going to work".

I'm writing this because the official guidance covers the topics but doesn't tell you what to actually choose. After running these conversations with dozens of Australian clients across mining, finance, healthcare, and government, the patterns are pretty consistent. Here's what's worth thinking about and what I'd recommend in each case.

The Power BI service vs Report Server question

This sounds like an old question but it still comes up, especially in regulated industries. Power BI Report Server is the on-premises option. The Power BI service is the cloud version (now part of Fabric).

For 95% of new deployments, the service is the right answer. You get more features, better tooling, faster updates, and access to the broader Fabric ecosystem. Report Server is significantly behind on feature parity and Microsoft's investment is clearly weighted toward the service.

The remaining 5% are organisations with hard data residency or air-gap requirements where cloud is genuinely not an option. Some defence, some classified government, some hospital networks. If that's you, Report Server is fine. If it's not, don't talk yourself into it because of vague "security concerns" that don't survive a proper risk assessment.

One thing I always push back on. If anyone suggests storing PBIX files in a SharePoint folder and calling that the deployment model, stop them. We've inherited environments like this and the audit trail, security model, and refresh story are all unworkable. Power BI service is the answer.

Workspace design - get this right or pay forever

Workspaces are the unit of organisation in Power BI. They're also the unit of permission, of deployment, and of refresh scheduling. How you carve them up determines a lot of downstream pain.

The temptation is to mirror your org chart. Finance workspace, sales workspace, ops workspace. Don't do this. It feels logical until you have twenty reports in the Finance workspace at different stages of maturity, owned by different teams, with different deployment cadences. Then everyone hates it.

Better approach: one workspace per logical solution or project. A solution being a coherent set of reports and the semantic models they depend on, owned by one team, deployed together. The mortgage broker dashboard set is one solution. The board reporting pack is another. The supply chain analytics is a third. Don't mix them.

For each solution, plan separate dev, test, and prod workspaces from day one. Yes, even for "small" solutions. Small solutions become big solutions and retrofitting environments after the fact is a nightmare. The deployment pipeline feature lets you promote content between them cleanly.

Separate workspaces for semantic models and reports is also worth considering, especially when different teams own them. Data team builds and owns the model. Business teams build reports against it. They publish on different schedules. This is the pattern I'd recommend for anything beyond the smallest deployments. We cover this in more detail when we run Power BI consulting engagements.

Security - groups not individuals, always

This one's simple. Use Microsoft Entra ID groups (or Microsoft 365 groups) for permissions, never individual user assignments. When Sharon leaves and James starts, you want to add James to the existing group, not figure out which fifteen workspaces had Sharon's name on them.

Audit your existing groups before starting. Most organisations already have functional groups (Finance Team, Sales APAC, etc.) that map well to workspace roles. Use those where you can. Only create new Power BI specific groups when there's no good match.

For external users (guests), get your Microsoft Entra and Power BI administrators talking before you commit. The guest access path works but has prerequisites that need to be enabled at the tenant level. Discovering this two days before a partner go-live is unpleasant.

How will people actually consume the content

This is the question that should drive most of your downstream decisions but often gets overlooked. The options are:

Direct workspace access. Users go to the workspace and view reports. Simple, works fine for small audiences who are already comfortable navigating Power BI.

Power BI app. A curated package built from a workspace's content, with controlled audience permissions. This is what I'd recommend for any wider audience. Apps let you control what people see, in what order, with proper branding. Direct workspace access shows everything in the workspace which is rarely what you want.

Embedded in Teams. Good for embedding specific reports into channels people already use. Adoption is genuinely better when reports live where people work.

Embedded in SharePoint or a custom portal. Useful for portal-driven experiences but more setup. Don't go down this path unless you have a real reason.

Mobile. If executives or field staff need access on phones, you need to design for it. The mobile experience needs reports built specifically for small screens, not desktop reports squeezed into a phone. Plan this upfront because retrofitting a mobile experience after the fact usually means redesigning the report from scratch.

Who else can create content

A decision people defer that they shouldn't. The questions are:

Can consumers build their own reports from the published semantic model? This needs Build permission on the semantic model. The advantage is self-service and reduced load on the central team. The disadvantage is proliferation of reports of varying quality that all claim to be authoritative.

My take: enable Build permission for trusted power users in business units, not for everyone. Make it part of a small upskilling programme so the people who get the permission know how to use it well. We help organisations think through this kind of governance model in our AI strategy work which often intersects with the BI strategy.

Can consumers save personalised copies? The Save a Copy feature lets users make their own version of a report. It's useful but it's also where branding and compliance go sideways. If your report has logos and disclaimer text, the personalised copy keeps them but now the user can change everything else around them. People get confused about whether they're looking at the official version.

I'd disable Save a Copy on reports where branding or compliance text matters. Enable it on operational reports where personalisation genuinely helps and the branding doesn't matter much.

Premium capacity - do you need it

Covered this in detail in our Fabric licensing post, but the short version is: premium capacity unlocks features that are genuinely useful for any deployment beyond a small team. Large semantic models, more frequent refreshes, deployment pipelines, the XMLA endpoint, and (critically) the ability for viewers to consume content without per-user Pro licences.

The cost only makes sense above a certain scale. For mid-sized Australian organisations, the break-even for capacity vs. per-user licensing usually lands around 350 to 400 viewers. Below that, Pro and PPU make more sense. Above it, F64 or higher is the right answer.

Don't buy premium capacity for features you won't use. We've seen clients pay for capacity because someone read about deployment pipelines and decided they needed them, then never set them up. If you're going to pay for it, plan to use it.

Data acquisition - the decision that has the longest shadow

The data side of the decision matters more than the report side, because data design constraints what reports can do.

Use an existing shared semantic model if one exists and it has the data you need. Don't recreate models just because you don't know about the existing ones. Audit what's in the tenant before building.

If you do need a new model, choose storage mode carefully.

• Import is the default. Data lives in Power BI, refreshes on schedule. Fast, well understood, but data isn't real-time and large models hit memory limits.
• DirectQuery hits the source database directly. Always up to date, no refresh needed, but performance depends on the source and concurrent users can hammer it.
• Composite mixes import and DirectQuery in the same model. Useful for hybrid cases where some data is large/real-time and other parts are reference data.
• Live Connection means the report connects directly to a published semantic model or Analysis Services instance. Use this when you want strict separation between modelling and reporting.

For most cases, Import is the right choice. DirectQuery should be a deliberate decision based on real-time requirements, not a default. We've cleaned up plenty of DirectQuery deployments that were chosen for "real-time" needs that turned out to be once-an-hour refresh requirements where Import would have been fine.

Dataflows or no dataflows. If you have multiple semantic models that need the same transformed data, dataflows are worth it. Build the transformation once, reference it from multiple models. If you only have one model using the data, skip dataflows and just do the transformation in the model itself.

Gateway requirements. Anything connecting to on-premises data needs an on-premises data gateway. Plan this early because the gateway needs a server (or VM), Microsoft Entra registration, and someone to maintain it. Don't discover the gateway requirement two days before go-live.

The decisions worth documenting

Plenty of teams skip the documentation step because the decisions are "obvious". They're obvious now. They won't be obvious in six months when someone new joins the team and asks why workspaces are structured the way they are.

For each migration, document at minimum: the workspace structure, the security model, the consumption approach (app vs direct workspace), the storage mode for each semantic model, and the refresh schedule. That's the minimum. Anyone joining the team should be able to read it and understand the design without needing to interview the team.

We do a lot of Power BI engagements where the first month is spent reverse-engineering decisions that were never documented. It's frustrating and expensive. Spend the hour writing it down upfront.

Final thoughts

Power BI migration isn't really about Power BI. It's about making clear decisions on workspace structure, security, consumption model, premium use, and data acquisition. The technology is easy once those decisions are made. The technology is impossible if they aren't.

If you're early in a migration, spend the time on planning. If you're mid-flight and feeling pain, it's almost certainly one of these decisions that was made by default rather than deliberately. The fix is usually structural, not technical.

Microsoft's full guidance is at their migration planning docs. It's a thorough reference but it doesn't tell you what to choose. Hopefully this gives you a starting point.