Power BI Migration - The Pre-Migration Work That Actually Decides Success

Most Power BI migrations don't fail at the technical step. They fail before anyone has opened Power BI Desktop. The decisions made (or avoided) in the weeks before migration determine whether you end up with a clean, governed reporting environment or a slightly newer version of the mess you already had.

I've seen this happen across enterprises in Sydney, Melbourne and Brisbane. The pattern is almost always the same. Someone gets a budget, a vendor gets engaged, a timeline gets set, and the pre-migration work gets compressed into "we'll figure it out as we go". Six months later there's a Confluence page full of unresolved questions and a list of reports nobody is willing to sign off on.

So when I read the Microsoft guidance on preparing to migrate to Power BI, I think it understates how much of the success comes from this phase. The doc lists the steps. It doesn't really capture how hard the people work is.

Why this matters more for Australian businesses

There are a few specifics that make the migration question hit harder here than it might elsewhere.

Most Australian mid-market organisations have been running some flavour of legacy BI for over a decade. Cognos, BusinessObjects, MicroStrategy, QlikView, the older SSRS shops, Tableau deployments from the 2017 era. The reports built on those tools are baked into board packs, regulatory submissions, operational dashboards, and customer-facing data products. You can't just turn the old system off on a Friday and turn Power BI on the Monday.

We also have a data sovereignty angle that's harder to work through than it is for businesses in the US. The choice of tenant region, the storage location for datasets, the location of Power BI Premium capacity, and the residency of any AI features all have to be reasoned about properly. The Microsoft regions in Australia are mature now, but the decisions around them still need someone senior at the table.

Then there's the skills question. Power BI talent in Australia is reasonable in Sydney and Melbourne, sparse in Brisbane, and basically non-existent in regional areas. If you're a mining business in WA or a manufacturer in regional Victoria, the pre-migration plan needs to include who is going to actually own this environment after the consultants leave. We talk about this a lot when we help clients with Power BI strategy.

The four bits of pre-migration work that matter most

The Microsoft guidance covers a lot of ground but in my experience there are four areas where the pre-migration effort pays back most of the project value. Get these right and the migration itself is mechanical. Skip them and the migration is the start of your problems, not the end.

1. Inventory the reports you have, not the reports you think you have

The inventory step is the one everyone underestimates. The IT team will tell you there are 300 reports. The business will tell you they only use 40 of them. Both are wrong.

What we typically find when we run a proper audit is something like: 600 reports exist in the legacy environment, 180 have been run in the last 12 months, 70 are run weekly or daily, 30 are considered business-critical by someone, and maybe 12 actually drive a decision. Those numbers are not a coincidence. They roughly match what we see across most Australian enterprises.

The implication is that you should not migrate everything. You should migrate the reports that have demonstrable usage, then have a structured conversation about the rest. This is where political problems start because someone always argues that "this report is critical, we just don't run it often". Sometimes they're right. Often they're not. You need a way to resolve this without it becoming a stalemate.

The way we do it is: pull six months of usage logs from the source system, layer that against the report owners table, then sit down with each business unit and ask three questions. When did you last open this? When did you last act on something in it? If we turned it off tomorrow, would you notice this week? The third question is the one that matters.

2. Map the data sources, including the ones nobody wants to admit exist

Every BI environment has a documented data architecture and a real data architecture, and they're never the same thing. The documented one shows the warehouse, the data marts, and the reporting layer. The real one includes a SharePoint folder of Excel files maintained by finance, a Power Query script someone wrote in 2019 that connects to a SQL database in a regional office, an Access database that holds the customer reference data, and a CSV that gets emailed every Monday from an external supplier.

If you don't surface these before migration, they'll surface themselves halfway through. Usually as a P1 incident the week after go-live.

The pre-migration phase is where you do the unglamorous work of tracing every report back to its actual data source. Not the source the data architect thinks it has. The source it actually has. This is also a good opportunity to consolidate. If you've got 12 reports that all hit the same SAP table in slightly different ways, that's 11 opportunities to standardise. Power BI's semantic models reward this kind of cleanup heavily, and the right semantic model design at this stage can save you from major refactoring later. We've written about how this connects to Microsoft Fabric and the broader data platform.

3. Decide your licensing model before you build anything

Power BI licensing is not complicated, but it's confusing if you've never thought about it before. Pro per user, Premium Per User, Premium capacity, Embedded, Fabric capacity. Each one has different sharing rules, different feature sets, and different pricing models.

The wrong decision here is expensive. I've seen organisations buy Premium capacity when they had 50 users and didn't need it. I've seen organisations stay on Pro per user when they had 800 users and were paying twice what Premium would have cost. The right answer depends on the size of the audience, the size of the datasets, whether you need paginated reports, whether you need AI features, and whether you're consolidating onto Fabric.

Make this decision before you start migrating, not after. The data model design changes depending on the licensing. Large dataset support, incremental refresh limits, dataflow availability, and a bunch of other technical decisions cascade from the licensing choice. Decide once, build accordingly.

4. Choose the workspace and tenant structure

This sounds boring. It's not. The workspace structure you set up at the start of the migration is the workspace structure you'll be living with for the next five years, because reorganising it later means breaking every link to every report and every embedded dashboard.

There are basically three models I see working in Australian organisations.

The first is a small number of workspaces by major business unit, with strict permission boundaries between them. Works well in larger organisations with strong central governance.

The second is a workspace per project or product team, with a centralised workspace for the shared semantic models. Works well in agile organisations and in tech-forward businesses.

The third is a hybrid where there's a central data team that owns the semantic models in dedicated workspaces, and the business units have their own workspaces for reports that consume those models. This is the model I'd recommend for most mid-market Australian businesses. It separates the data engineering work from the report development work, which matches how the responsibilities usually split internally.

What the Microsoft documentation doesn't emphasise enough

The documentation walks through the technical preparation steps in a structured way, which is helpful. But there's a gap between the official guidance and what actually causes migrations to slip.

The biggest gap is the people side. Power BI is not Excel. It's not SSRS either. It assumes a different way of thinking about data, with semantic models as first-class objects and DAX as a core skill. If your organisation has been doing reporting through Excel pivot tables for fifteen years, the cultural shift is bigger than the technical one.

I'd add a fifth pre-migration step to the official list: an honest assessment of who in the organisation is going to learn DAX, who is going to own the semantic models, and what training they need before the migration starts. Not after. Before. Otherwise you finish the migration with no internal capability and you become permanently dependent on the consultants who built it. That's good for the consultants. It's not good for you.

We've been helping clients build internal Power BI capability for years through our AI and data services, and the projects that go well are always the ones where the client invests in their people during the pre-migration phase, not the ones where they treat skills as a post-go-live problem.

The migration plan you actually want

Pulling this together, here's what a sensible pre-migration plan looks like for an Australian organisation moving to Power BI.

Six weeks of inventory and triage. Identify what exists, what's used, what's critical, what's redundant. Get business sign-off on what migrates and what doesn't.

Four weeks of data source mapping. Trace every retained report back to its actual source. Identify consolidation opportunities. Decide on the semantic model boundaries.

Two weeks of licensing and architecture decisions. Pick the licensing model. Design the workspace structure. Decide on the Premium or Fabric capacity if relevant.

Ongoing capability uplift. Identify the people who will own this environment. Get them trained, ideally including hands-on time with realistic data, before the migration starts.

After that, the migration itself is mostly mechanical. You're moving reports onto a platform you've already designed for, populated by data you've already mapped, owned by people you've already trained. The risk is much lower and the timeline is much shorter than the all-in-one approach.

The temptation in every migration is to skip the pre-work and "get on with it". Resist the temptation. The pre-migration phase is where the project either succeeds or fails. The technical migration is just the visible part.

Reference

The original Microsoft guidance is at Power BI migration - prepare to migrate.