The Power BI Migration Overview - The Decisions That Happen Before Anyone Builds a Report

Most clients walk into a Power BI migration thinking it is a tooling project. Pick the new tool, rebuild the reports, retire the old platform, done. Then six weeks in, someone realises the gateway architecture has to be redesigned, someone else discovers that the row-level security model in the legacy tool does not map cleanly onto Power BI, and the project manager starts adding columns to the risk register.

This is the post I write up after every Power BI migration we get involved in, because the pattern is so consistent it is almost comical.

If you are thinking about migrating to Power BI from Tableau, Qlik, Cognos, MicroStrategy, SAP BusinessObjects, SSRS, or any in-house reporting tool that has accumulated a decade of organisational logic, the Microsoft migration overview is a fine starting point. What follows is the version with the bruises, written from the consulting side.

A migration is five projects pretending to be one

The thing people miss is that a Power BI migration is really five projects stitched together. They are:

1. A platform project. New tenant, capacity, gateways, workspaces, security model.
2. A data project. Source connectivity, refresh schedules, gateways again, data model design.
3. A content project. Rebuilding reports and dashboards. The visible bit.
4. A user adoption project. Training, change management, getting people to actually open the new thing.
5. A decommissioning project. Turning off the old system without anyone losing critical work.

Most plans treat this as one project and budget for project three. That is why migrations blow out. The other four projects do not vanish because you did not plan for them. They just turn up later, looking surprised.

Stage by stage, what actually happens

Microsoft frames Power BI migration in five stages, broadly: requirements, planning, POC, build, deploy. The structure is fine. The labels are fine. The work hidden inside each stage is what people underestimate.

Stage 1: Gather requirements and prioritise

This is the stage where you find out what your legacy reports actually do, as opposed to what people think they do. There is always a gap.

A typical example. A client tells us they have 240 Tableau workbooks they need to migrate. We start the audit. After two weeks we find that 80 of those workbooks have not been opened in the last 12 months, 40 are exact duplicates of other workbooks with one filter changed, and another 30 are draft versions from a project that ended in 2023. The actual number of reports that need migrating is closer to 90.

This is not unusual. It is the default. If you do not audit before you migrate, you migrate the noise as well as the signal. Which then doubles the work and triples the testing.

Audit usage data, not the workbook list. Find out what people actually run. Group the survivors by who uses them, how often, and what business decisions they support. Then prioritise based on business value, not the order they were originally built.

The other big requirements decision is consumer vs creator. In legacy tools, the line between people who build reports and people who consume them is often blurry. In Power BI it matters a lot, because licensing, capacity, and access patterns differ. Get clear on who fits each role before you size your environment.

We help clients with this triage work as part of our Power BI consulting engagements, because the cost of getting it wrong is enormous. You can migrate 90 reports for a third of the cost of migrating 240, and the business will not notice the difference.

Stage 2: Plan the deployment

Now you decide what Power BI is going to look like in your environment. This is the stage where architectural decisions get made. Workspace structure. Capacity model. Tenant settings. Gateway placement. Identity integration. Sensitivity labels. The list is long.

Some of these decisions are easy to change later. Workspace naming conventions, for example. You can rename and reorganise.

Some are very hard to change later. Capacity sizing across multiple business units. Sensitivity label taxonomy. Gateway architecture if you have on-premises sources spread across data centres. If you get these wrong, you will spend the rest of the project explaining to people why their report is slow or why they cannot share content with another department.

The Microsoft guidance suggests a tenant-level deployment plan. In practice, what you want is a deployment plan that the IT team, the data team, and the business owners can all agree on. The biggest risk in this stage is not a technical one. It is two parts of the organisation deciding different things in parallel and not finding out until later.

Stage 3: Conduct a POC

I have written about Power BI POCs in detail elsewhere. The short version is that the POC is where you find out what you do not know. You build a small, end-to-end working example with real data and real security, deployed to a real workspace. You test the things you are uncertain about.

The mistake people make is using the POC as a demo to convince stakeholders that Power BI is good. Stakeholders do not need convincing. They have already signed the budget. Use the POC for what it is actually for, which is finding the surprises before they become expensive.

Stage 4: Create content

This is the visible work. Building the reports. It is also the part that everyone wants to start with, and the part that goes badly when stages 1 to 3 were rushed.

The interesting thing about this stage is that it benefits enormously from sequencing. Pick a small, high-value group of reports first. Build them, deploy them, get feedback, iterate. Then expand. Do not try to rebuild everything in parallel. You learn things during the first batch that change how you would build the second batch. If you build them all at once you cannot apply those lessons.

The other common trap is trying to replicate every visual exactly as it appears in the legacy tool. Power BI has its own visual idioms. Some things are different. Some things are better. Some things are arguably worse. Fighting Power BI to make it look like Tableau is expensive and produces ugly reports. Focus on the business question, not the pixel layout.

Stage 5: Deploy, support, and monitor

Deployment is not the end. It is the start of operations. Reports break. Sources change. People ask for new features. Capacity needs tuning. Refresh failures need triaging. You need a support model, an operating rhythm, and someone whose job includes Power BI.

A common pattern in Australian organisations is that the project team builds everything, then disbands, and the BAU team inherits the environment with no documentation and no relationships with the source system owners. Six months later, things start to drift. Reports go stale. Trust erodes. People start running their own queries in Excel again because the Power BI report disagrees with the spreadsheet.

Plan for the hand-off from project to operations during the project, not after.

Where Australian organisations get stuck

A few patterns we see often:

Gateway sprawl. Multiple gateways set up by different teams for different sources, none documented, all critical. When one of them breaks, nobody knows whose laptop it was running on. Fix this early. Centralise where possible. Document who owns what.

Capacity confusion. Premium capacity, Premium Per User, Fabric capacity, Pro licensing. The pricing model has changed a few times. Get clear advice on which mix of capacities fits your usage patterns. Overprovisioning is expensive. Underprovisioning is worse, because reports get slow and users abandon them.

Identity and security mismatches. The legacy tool had its own user model. Power BI uses Entra ID (formerly Azure AD). If your organisation uses guest accounts, B2B sharing, or complex group memberships, the security mapping is not trivial. Get this right before you start sharing content broadly.

The legacy reports become the spec. Stakeholders insist the new Power BI version must do everything the old version did, exactly the same way. This is rarely useful. The legacy reports include years of workarounds for limitations that Power BI does not have. Treat the legacy reports as a source of requirements, not as the requirements themselves.

We help clients work through these decisions as part of data and AI strategy work, because the right answer depends heavily on the organisation's existing Azure and Microsoft 365 setup.

What "good" looks like

A Power BI migration that goes well has a few hallmarks:

The team running it has both BI experience and Power BI experience, which is not the same thing. People who have built BI platforms before know what the hard parts are. People who know Power BI know how to do them in this specific tool. You want both.

The audit is honest. Reports that nobody uses get retired, not migrated. Duplicates get consolidated. The total scope shrinks.

The architecture decisions get made early and stay made. Workspaces, capacities, gateways, identity. Documented, agreed, signed off before content build starts.

The POC actually tests the hard things. Not the pretty things.

Content is built in waves, not all at once. Each wave teaches you something about the next wave.

Operations exists from day one. Not bolted on after deployment.

If you are starting a Power BI migration in 2026, or you are in the middle of one and starting to feel the wheels wobble, that is the sort of conversation we have most weeks with Australian organisations. Worth a quick chat before you commit budget to the next stage. The cheapest hour of consulting is usually the one before you make the next big decision.

The Microsoft documentation is fine. It will not save you from the project hidden inside the project. That part is on you, and on whoever you have helping.

Reference: Power BI Migration Overview - Microsoft Learn.